Problem/Motivation

After remove german language i get this error.
I deleted all german term and german content but error persist.

The website encountered an unexpected error. Please try again later.
Error: Call to a member function getId() on null in Drupal\Core\Entity\EntityViewBuilder->getBuildDefaults() (line 212 of core/lib/Drupal/Core/Entity/EntityViewBuilder.php).

Drupal\Core\Entity\EntityViewBuilder->getBuildDefaults(Object, 'teaser') (Line: 157)
Drupal\Core\Entity\EntityViewBuilder->viewMultiple(Array, 'teaser', 'de') (Line: 123)
Drupal\Core\Entity\EntityViewBuilder->view(Object, 'teaser', 'de') (Line: 89)
Drupal\views\Entity\Render\TranslationLanguageRenderer->preRender(Array) (Line: 221)
Drupal\views\Plugin\views\row\EntityRow->preRender(Array) (Line: 441)
Drupal\views\Plugin\views\style\StylePluginBase->preRender(Array) (Line: 1508)
Drupal\views\ViewExecutable->render() (Line: 131)
Drupal\views\Plugin\views\display\Block->execute() (Line: 1630)
Drupal\views\ViewExecutable->executeDisplay('block_1', Array) (Line: 81)
Drupal\views\Element\View::preRenderViewElement(Array) (Line: 59)
Drupal\views\Plugin\Block\ViewsBlock->build() (Line: 171)
Drupal\block\BlockViewBuilder::preRender(Array)
call_user_func_array(Array, Array) (Line: 101)
Drupal\Core\Render\Renderer->doTrustedCallback(Array, Array, 'Render #pre_render callbacks must be methods of a class that implements \Drupal\Core\Security\TrustedCallbackInterface or be an anonymous function. The callback was %s. See https://www.drupal.org/node/2966725', 'exception', 'Drupal\Core\Render\Element\RenderCallbackInterface') (Line: 772)
Drupal\Core\Render\Renderer->doCallback('#pre_render', Array, Array) (Line: 363)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 435)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 201)
Drupal\Core\Render\Renderer->render(Array) (Line: 479)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 134)
__TwigTemplate_fd2d1d267a30195197ffb681dc27b97718ad79fc4f795dba55b6dfa6c57a9d9a->doDisplay(Array, Array) (Line: 405)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 378)
Twig\Template->display(Array, Array) (Line: 45)
__TwigTemplate_38dcf7bd64040a1d76d94890afe021edb563871c3dca59e6b1d00a67e4672ab5->doDisplay(Array, Array) (Line: 405)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 378)
Twig\Template->display(Array) (Line: 390)
Twig\Template->render(Array) (Line: 55)
twig_render_template('themes/custom/oto_frontend/templates/layout/page--taxonomy--product-term.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('page', Array) (Line: 422)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 201)
Drupal\Core\Render\Renderer->render(Array) (Line: 479)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 113)
__TwigTemplate_184af407217c790cf11d0eb4944ff42ffc946b44f25c292c2ba1218346ab1814->doDisplay(Array, Array) (Line: 405)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 378)
Twig\Template->display(Array) (Line: 390)
Twig\Template->render(Array) (Line: 55)
twig_render_template('themes/custom/customer_frontend/templates/layout/html.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('html', Array) (Line: 422)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 201)
Drupal\Core\Render\Renderer->render(Array) (Line: 162)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 564)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 163)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 142)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.view') (Line: 163)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 80)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 130)
Drupal\cdn\StackMiddleware\DuplicateContentPreventionMiddleware->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 709)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Steps to reproduce

Delete a language and got to taxonomy term views

Problem/Motivation

Currently, the Drupal ajax framework uses mousedown to capture the click even for triggering ajax. This causes some usability problems because it means all mouse interactions trigger the ajax event. This is also a accessibility problem because it
violates WCAG 2.1 https://www.w3.org/TR/WCAG21/#pointer-cancellation

Steps to reproduce

1. Install Drupal 10
2. Add a file field to articles. Set Allowed number of values to Unlimited
3. Create an article. Add several files to it.
4. Right click on the remove button and see the file be removed.

Proposed resolution

Replace mousdown with click event handlers.

Remaining tasks

Review and commit.

User interface changes

API changes

Data model changes

Release notes snippet

Original report by @mibfire

I have noticed that when #ajax is attached to a submit button the right click(and all other buttons of mouse, like middle) is working as well and i dont think it should. It is because the ajax.js uses the mousedown event in default. I would like to know if there is some reason for using mousedown because i think this should work only with (left)click. THX

Problem/Motivation

Follow-up from #3344789: Return early in EntityPermissionsForm::access if the user does not have "administer permissions".

We could drop the check for whether there are permissions or not entirely from the access check, and just show a short message on the page when no permissions for a bundle are defined.

The UX regression of showing a somewhat useless tab, is better than the regression of multi-second page loads with admin_toolbar module and etc.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

When browsing an Ajax view, many Drupal.Ajax are created for the refresh feature. Those objects are not cleaned up.

Need to either add some code to clean them up or prevent several objects from being created.

Core migration issues

• RTBC
• NR
• all open
• Needs subsystem maintainer review
• Statistics, Google spreadsheet

Next video meeting 2024-07-18

Hello all, it’s time for the biweekly migration subsystem meeting. The meeting will take place in slack in various threads. This meeting:
➤ Is for core migrate maintainers and developers and anybody else in the community with an interest in migrations
➤ Usually happens every second Thursday and alternates between 1400 and 2100 UTC.
➤ Is done on the #migration channel in Drupal Slack (see www.drupal.org/slack for information).
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to. #3453256: [meeting] Migrate Meeting 2024-06-20 2100Z) See the parent issue for an idea of the typical agenda.
➤Transcript will be exported and posted to the agenda issue. For anonymous comments, start with a 👤 emoji. To take a comment or thread off the record, start with a 🚫 emoji.

0️⃣ Who is here today?

1️⃣ What should we talk about today? Suggest topics here and I will add threads. I will also check for comments on the issue for today's meeting.

2️⃣ Action items. To be added later.

3️⃣ Statistics

4️⃣ Comment in this thread if you are looking for ways to contribute. Give us some idea of what you would like to do: documentation, code review, testing, project management, ...

5️⃣ Previous minutes.

6️⃣ Announcements

7️⃣ Removing migrate_drupal

$ find core/modules/node/src/Plugin/migrate/source -type f 
core/modules/node/src/Plugin/migrate/source/d7/NodeRevision.php
core/modules/node/src/Plugin/migrate/source/d7/NodeEntityTranslation.php
core/modules/node/src/Plugin/migrate/source/d7/NodeType.php
core/modules/node/src/Plugin/migrate/source/d7/Node.php
core/modules/node/src/Plugin/migrate/source/d7/NodeComplete.php
core/modules/node/src/Plugin/migrate/source/d6/NodeRevision.php
core/modules/node/src/Plugin/migrate/source/d6/ViewModeBase.php
core/modules/node/src/Plugin/migrate/source/d6/ViewMode.php
core/modules/node/src/Plugin/migrate/source/d6/NodeType.php
core/modules/node/src/Plugin/migrate/source/d6/Node.php
core/modules/node/src/Plugin/migrate/source/d6/NodeComplete.php

8️⃣ Process plugin: build an array from source, destination, pipeline

9️⃣ Wrap-Up

Problem/Motivation

core/modules/jsonapi/tests/src/Functional/MediaTest</h4>.php:79 reference issue #2824851: EntityResource::patch() makes an incorrect assumption about entity keys, hence results in incorrect behavior. It was foretold there to remove the line below in this issue, but that didn't happen.

Another instance: core/modules/jsonapi/tests/src/Functional/MediaTest.php:399

Steps to reproduce

Proposed resolution

Remove the comment and extra line in the test, see if all is good. :)

Search for other references to that issue

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Starting from #2351919: Replace uses of drupal_get_path() with __DIR__ where possible, when the PHP code needs to include or parse files inside the module or theme directory space, will simply use _DIR_ instead of drupal_get_path(). This is sufficient, intuitive and more performant than calling drupal_get_path().

However, drupal_get_path() is widely used to refer files (.js, .css, images, assets) outside a module or theme. This isn't very intuitive for new developers. Stream wrappers make much more sense and simplify the API for developers trying to refer directories or files from outside the current extension in code.

Proposed resolution

Introduce extension stream wrappers:

Examples

Profile: profile://

Assuming the standard profile is installed:

• Referring a directory:
  • Actual: drupal_get_path('profile', 'standard') . '/config'
  • Proposed: profile://config
  • Path: core/profiles/standard/config
• Referring a file:
  • Actual: drupal_get_path('profile', 'standard') . '/config/install/automated_cron.settings.yml'
  • Proposed: profile://config/install/automated_cron.settings.yml
  • Path: core/profiles/standard/config/install/automated_cron.settings.yml

Module: module://

Assuming the node module is enabled but color module is not:

• Referring a directory:
  • Actual: drupal_get_path('module', 'node') . '/config'
  • Proposed: module://node/config
  • Path: core/modules/node/config
• Referring a file:
  • Actual: drupal_get_path('module', 'node') . '/config/install/node.settings.yml'
  • Proposed: module://node/config/install/node.settings.yml
  • Path: core/modules/node/config/install/node.settings.yml
• Referring a resource in a uninstalled or inexistent module:
  • Actual: drupal_get_path('module', 'color') . '/config'
  • Proposed: module://color/config
  • Path: Throws \RuntimeException

Theme: theme://

Assuming the bartik theme is installed but seven theme is not:

• Referring a directory
  • Actual: drupal_get_path('theme', 'bartik') . '/config'
  • Proposed: theme://bartik/config
  • Path: core/themes/bartik/config
• Referring a file
  • Actual: drupal_get_path('theme', 'bartik') . '/color/color.inc'
  • Proposed: theme://bartik/color/color.inc
  • Path: core/themes/bartik/color/color.inc
• Referring a resource in a uninstalled or inexistent theme:
  • Actual: drupal_get_path('theme', 'seven') . '/config'
  • Proposed: theme://seven/config
  • Path: Throws \RuntimeException

Remaining tasks

1. Profiling to compare performance of the new code with the old.

API changes

New abstract class for extensions stream wrappers:

• \Drupal\Core\StreamWrapper\ExtensionStreamBase

New stream wrapper classes:

• \Drupal\Core\StreamWrapper\ModuleStream
• \Drupal\Core\StreamWrapper\ThemeStream
• \Drupal\Core\StreamWrapper\ProfileStream

Data model changes

None.

upgrading from d10.18 to 10.3.0.
Drupal\Component\Plugin\Exception\PluginNotFoundException: The "entity_bundle:node" plugin does not exist. Valid plugin IDs for Drupal\rules\Core\ConditionManager are:
rules_data_compariso

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

This is a spinoff / restatement of the problem identified in #93447: Deleting the first value in a required, multivalue field fails validation. That was marked as a duplicate of #1038316: Allow for deletion of a single value of a multiple value field, but that is really a UI issue about adding a "Remove" widget to multiple value fields. The original issue is a Form API issue: a field with unlimited cardinality that has at least one value should satisfy a "required" property for the field. As it is now, the "required" validation applies to the original delta 0 element of the field, regardless of e.g. the user moving the elements around (changing the weights) and of the values in any other elements of the field.

Steps to reproduce

Steps to reproduce :
(1 to 5 are just there to outline the 'expected' behaviour)
1 - Define a text field - mark it multiple / NOT required
2 - Create a node with 3 values 'foo', 'bar' and 'baz' for the field
3 - Submit
4 - Edit the node, empty the first value 'foo'
5 - Submit : everything OK, the field has the values 'bar' and 'baz', and if you edit the node, you get 'bar' and 'baz' in the first and second textfields (values have shifted)
6 - Now set your field to REQUIRED
7 - Edit the node, empty the first value 'bar'
8 - Submit : you get a 'field is required' error on the first (empty) textfield, yet the field itself should not be considered empty, since you have the 'baz' value in the second textfield

(Copied from #93447)

Proposed resolution

Change required field validation to consider the field as a whole, not only the initial delta 0 element.

Whether Drupal also adds a "Remove Me" widget is a fine but separate issue.

Problem/Motivation

If you have a media type that uses an image field as it source, and that field has a minimum/maximum resolution defined, the media library will completely ignore those constraints when uploading a new image into that media type.

Steps to reproduce

1. Install the Standard profile, and the Media Library module.
2. Add a media field to a content type, referencing the Image media type.
3. Edit the Image media type's source field ("Image") and set a maximum resolution of, say, 16x16.
4. Start creating some content, and open the media library.
5. Upload an image, bigger than the maximum allowed resolution, into the library.
6. You'll see that the upload proceeds without a hitch, even though the image is bigger than what's allowed.

Proposed resolution

The media library defers to the field's getUploadValidators() method to determine how to validated uploaded files. As per the discussion between @phenaproxima and @alexpott in #33-35, it makes sense for the ImageItem field type to override this method and provide validators that are specific to images, including resolution constraints, and have Media Library defer to that. This will provide a consistent API to determine image validation. While we're at it, we should also try to clean up other places that have had to manually set the validation, such as the Image module's integration with Quick Edit, REST's FileUploadResource, and JSON:API's TemporaryJsonApiFileFieldUploader.

Remaining tasks

Address feedback on merge request, and commit.

API changes

None, really; ImageItem::getUploadValidators() -- which it inherits from FileItem -- will provide more specific validators, but this does not change the public API.

Data model changes

None.

UI changes

None.

Release notes snippet

TBD

Problem/Motivation

Many efforts have been made to make Drupal 8 a great multilingual system. However, content types are never properly sorted when translations contain accentuated characters.

Content types are sorted using asort. Maybe we could set the locale beforehand.

Steps to reproduce

Install Drupal 8
Enable the following modules

• Configuration Translation
• Content Translation
• Interface Translation
• Language

Add a language (French in the example)
Add a two content types (Show and Zone)
Translate the Show content type to Émission
Switch languages (fr/admin/structure/types)

Expected behavior

To have a list in this order

• Article
• Basic page
• Émission
• Zone

What happened instead

List was in this order:

• Article
• Basic page
• Zone
• Émission

Proposed resolution

Use PHP Collator class to sort the items with a fallback when PHP intl extension is not installed

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Upgraded to 10.3 and status-message.html.twig is missing as a theme suggestion, breaking my custom theme. See screenshots.

It appears this is not related to the issue as was assumed in (#1 - #11):
PathMatcher::isFrontPage() does not work for the default homepage if it contains a query string.

I have tested this with a small block that displayed the value of PathMatcher::isFrontPage(), but it also appears to affect the menu system (where I first noticed this):

Issue since #12:

When appending a query string to a URL, the active trail is no longer added. This is undesirable because queries might be added for tracking a user's entrypoint eg example.com?referrer=email or pagination on a page (the second page of the menu item is still in the active trail of the menu item).
These situations will make that you see the home page, but it is not marked as active.

Reproduce:

1. Visit the regular front page of your Drupal site: example.com.
2. Append a query string to the url: example.com?foo=bar.
3. Notice that the home menu item no longer has the is-active class.
4. Then repeat the same test with JavaScript disabled in development console and not being logged in. Notice the same behavior.

I could only achieve above behavior with the home page (example.com?foo=bar and example.com/node?foo=bar) and all other paths work as expected, so there appears to be something wrong with this default front page path somehow.

This appears not to be only limited to the home page anymore. Appending a query string to other pages also makes they are no longer marked active.

Before:

After patch #42:

Problem/Motivation

#3410582: Optimize user logins by avoiding duplicate entity queries refactored the user login process to optimise queries. To do that, it introduced a new UserAuthenticationInterface (see https://www.drupal.org/node/3411040). This was done with a BC layer in place, but that had some bugs affecting e.g. mail_login.

#3444978: UserAuth BC layer is not working for modules that use it to provide email based logins attempted to fix that, but in doing so actually broke things for email_registration (see #3456461: [2.x] Login fails with Drupal 10.3). The issue is that it moves the BC else into an elseif one level up in the code, which means it is never executed in the case of email_registration, where an account is returned, but the old interface is implemented.

This is then rather difficult to solve in email_registration because whilst different classes can be swapped out, static analysis will fail without the correct versions etc.

Steps to reproduce

Install Drupal 10.3 and Email Registration 2.x - you cannot log in.

Proposed resolution

1. Fix UserLogin::validateAuthenticate; perhaps move all the authentication finalisation to the end of the method with a BC if/else rather than trying to do inline with flood etc.
2. Given this is supposed to be a BC compatible change, probably some tests that swap out for the old interface would be a worthwhile investment.

Remaining tasks

Fix & test.

User interface changes

M/A

API changes

N/A

Data model changes

N/A

Release notes snippet

Fixes BC breaks in UserLoginForm.

Problem/Motivation

When adding a datetime exposed filter I cannot simply select a date - I have to manually enter a date which is very bad UX.

Proposed resolution

Use a form element with '#type' => 'datetime' so it's easy for users to select the date.

Change Record

Remaining tasks

Blocked on:

• #2625136: Fix label visibility and add wrapper container for exposed numeric/date filters with multiple form elements
• #3078334: Datetime and Datelist elements should render as fieldsets
• #2419131: [PP-1] #states attribute does not work on #type datetime

• Investigate why the default value of the exposed filter is not picked up by the form (see #104). see #115
• Hide time element for date-only type fields
• Create a follow-up for the possibility for site builder to decide the widget type from the views management UI (see #48)
• I think the new logic approach in #216 should also be happening in core/modules/datetime/src/Plugin/views/filter/Date.php where we hide the time element for date-only fields. I didn't get that far, and wanted someone else to agree with the new logic approach before I got much further.
• We clearly could use even more test coverage of all the possible combinations.
• We should decide if we really want to remove the placeholders and regexp from the existing filter and potentially break existing views that are using them (#215), or just add a whole new filter plugin with a different name. Then a) site builders can decide which interface they prefer and b) we don't have to worry about upgrade paths.

User interface changes

Exposed date filters will have input[type=date], and will leverage HTML5 handling if supported by the browser, or fall back to the polyfill if it doesn't.
For datetime w/ type date-only we should still use the datetime form element, but in date-only mode ($element['#date_time_element'] = 'none'.

API changes

None.

Data model changes

None.

Related to #3312966: Enforce the use of CSS Logical Properties in core

Problems

1. Core's .stylelintrc.json does not include CSS logical properties within the order/properties-order section. This means that our linting does not enforce properties order for those properties.
2. There's a lot of unneeded properties that have browser prefixes in .stylelintrc.json (examples: -ms-overflow-x, -o-transition-duration).

Solutions

1. Add CSS logical properties to .stylelintrc.json.
2. Remove unneeded CSS properties from .stylelintrc.json.

Problem/Motivation

Whenever a new field is added to an entity+bundle with LB enabled, a instance of the field is added to the first region of the default LB layout automatically.

This can be quite annoying to say the least, when you have carefully crafted a layout and fields are placed in unexpected positions. Sometimes a field is not mean to be displayed, or perhaps another site builder added a field without remembering to remove the field.

Understandably this is how fields traditionally worked, however visibility of newly added fields is more difficult to detect than simply checking the table within Manage Display tab. For example a field may be invisible, or have no sample value, or the layout/styling may only display the field conditionally.

Steps to reproduce

1. Install a standard site
2. Enable LB & add it to the page content type
3. Add a new field to the page content type and see that it has been added to the layout automatically.

Proposed resolution

Added a new feature flag module to control if new fields are added to the Layout.

Remaining tasks

Create a follow up to enable this module by default.

User interface changes

New fields are no longer added to the entities LB layout.

API changes

A new feature flag module has been added (layout_builder_prevent_adding_new_fields_to_layout‎)

Data model changes

Release notes snippet

Problem/Motivation

Adding a media Image file from Media Browser inserts a wrong image when default caching is enabled.

Steps to reproduce

1. Enable Media and Media library modules.
2. Create a new Media field or use an existing Media field
3. Add a Content containing this new media field.
4. Add Media and then insert a new image.
5. Unselect the new image from image list and then use any filter to media.
6. Select a different image and then Click Insert Selected.
7. Wrong image is insert. This issue is not happening when caching is disabled.

Proposed resolution

We should not cache previously selected image id or clear the id.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Some argument handlers provide their own default argument handling, like the Date argument. The Date argument handler does so by extending the list of of options in the defaultArgumentForm. An exception is however thrown on saving the form.

Steps to reproduce

• Create a new view /admin/structure/views/add using (node) content
• Under advanced tab, add new Contextual filter, select Created date (node.created)
• On "When the filter value is not available", select "Provide default value", on the drop-down select "Current date".
• Try to submit this form.

Result: A fatal error occurred on dblog: Drupal\Component\Plugin\Exception\PluginNotFoundException: The "date" plugin does not exist.

Proposed resolution

Get the date handlers in line with the other default argument handlers.
Add a 'Current date', a "Current node's creation time" and "Current node's update time" default argument handler.

Remaining tasks

• Add a follow-up for improving caching - see #114
• Add a follow-up to make this work for all entity-types using a deriver - see #176
• Confirm if this works with date time range fields - see #157

User interface changes

API changes

Data model changes

Release notes snippet

Problem

Steps to reproduce:

Proposed resolution

Problem/Motivation

Eslint 9.0.0 was released a few days ago, and has a number of breaking changes.

https://eslint.org/blog/2024/04/eslint-v9.0.0-released/
https://eslint.org/docs/latest/use/migrate-to-9.0.0

Most notably:
Flat config is now the default configuration format for ESLint and eslintrc is officially deprecated. To continue using a eslintrc configuration file, you’ll need to set the ESLINT_USE_FLAT_CONFIG environment variable to false.

Proposed resolution

Update drupal core to support eslint 9.0.0

Remaining tasks

tbc

Release notes snippet

tbc