Problem/Motivation

When rendering a view with an AJAX pager through layout builder, either directly or through other means (e.g. Views Reference Field on a content block), the pager does not receive the AJAX behavior, and instead reloads the page with the non-AJAX page query parameter appended.

At first glance it doesn't appear to be an issue with what's being #attached to the view. I've inspected both renderings through a post-render hook in a custom module, see below, and the only differences are the ones you'd expect such as their respective view_dom_ids.

function hook_views_post_render(ViewExecutable $view, &$output, CachePluginBase $cache) {
  dpm($view->element['#attached'], $view->id());
}

The rendering within Layout Builder has no trace of data-once="ajax-pager". Inspecting drupalSettings.views shows the view is found, though it doesn't receive the behavior.

If I render the view on the same page through a region, it receives the intended ajax-pager behavior.

At this point I have exhausted my knowledge on both the Layout Builder and Views APIs. Further debugging from those with more intimate knowledge of the aforementioned APIs would be much appreciated.

I have been able to reliably reproduce this issue using a standard DDEV install on Drupal 10.3.1 and PHP 8.3.

Steps to reproduce

1. Enable the Layout Builder module
2. Add multiple Articles nodes to test the pager with
3. Create a content view with an AJAX pager, either full or mini, and set a per-page count smaller than the amount of nodes you created so paging can be tested
4. Create a new vocabulary that uses Layout Builder for the default display mode
5. Manage the layout for the new vocabulary and add a new section with the AJAX view inside
6. Add a term to the new vocabulary and view it on the front end
7. Interact with the AJAX view's pager and observe a page reload with the non-AJAX page query parameter appended

Proposed resolution

TBD

Remaining tasks

• Find the cause of the issue
• Implement a fix

Problem/Motivation

We're on a beta of jQuery 4, we need to update to a stable release before 11.0.0 - opening this issue to track.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

We recently upgrade to PHP 8.1 over our drupal site Drupal core 9.4.8, we saw this error at display catalog page

Warning: Undefined array key "id" in Drupal\views\Plugin\views\display\DisplayPluginBase->getHandlers() (line 864 of /var/www/web/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php)
#0 /var/www/web/core/includes/bootstrap.inc(347): _drupal_error_handler_real(2, 'Undefined array...', '/var/www/web/co...', 864)
#1 /var/www/web/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php(864): _drupal_error_handler(2, 'Undefined array...', '/var/www/web/co...', 864)
#2 /var/www/web/core/modules/views/src/ViewExecutable.php(1043): Drupal\views\Plugin\views\display\DisplayPluginBase->getHandlers('filter')
#3 /var/www/web/core/modules/views/src/ViewExecutable.php(901): Drupal\views\ViewExecutable->_initHandler('filter', Array)
#4 /var/www/web/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php(2319): Drupal\views\ViewExecutable->initHandlers()
#5 /var/www/web/core/modules/views/src/ViewExecutable.php(1695): Drupal\views\Plugin\views\display\DisplayPluginBase->preExecute()
#6 /var/www/web/core/modules/views/src/ViewExecutable.php(1630): Drupal\views\ViewExecutable->preExecute(Array)
#7 /var/www/web/core/modules/views/src/Element/View.php(81): Drupal\views\ViewExecutable->executeDisplay('page_1', Array)
#8 [internal function]: Drupal\views\Element\View::preRenderViewElement(Array)
#9 /var/www/web/core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php(101): call_user_func_array(Array, Array)
#10 /var/www/web/core/lib/Drupal/Core/Render/Renderer.php(772): Drupal\Core\Render\Renderer->doTrustedCallback(Array, Array, 'Render #pre_ren...', 'exception', 'Drupal\\Core\\Ren...')
#11 /var/www/web/core/lib/Drupal/Core/Render/Renderer.php(363): Drupal\Core\Render\Renderer->doCallback('#pre_render', Array, Array)
#12 /var/www/web/core/lib/Drupal/Core/Render/Renderer.php(201): Drupal\Core\Render\Renderer->doRender(Array, false)
#13 /var/www/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(241): Drupal\Core\Render\Renderer->render(Array, false)
#14 /var/www/web/core/lib/Drupal/Core/Render/Renderer.php(564): Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}()
#15 /var/www/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(242): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#16 /var/www/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(132): Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\CurrentRouteMatch))
#17 /var/www/web/core/lib/Drupal/Core/EventSubscriber/MainContentViewSubscriber.php(90): Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\CurrentRouteMatch))
#18 [internal function]: Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object(Symfony\Component\HttpKernel\Event\ViewEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#19 /var/www/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(142): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\ViewEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#20 /var/www/vendor/symfony/http-kernel/HttpKernel.php(164): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object(Symfony\Component\HttpKernel\Event\ViewEvent), 'kernel.view')
#21 /var/www/vendor/symfony/http-kernel/HttpKernel.php(81): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#22 /var/www/web/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#23 /var/www/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#24 /var/www/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#25 /var/www/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#26 /var/www/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#27 /var/www/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#28 /var/www/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#29 /var/www/web/core/lib/Drupal/Core/DrupalKernel.php(709): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#30 /var/www/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#31 {main}

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

No change, just the PHP upgrade from 7.4 to 8.1.8, and a couple of module upgrade.

API changes

No change, just the PHP upgrade from 7.4 to 8.1.8, and a couple of module upgrade.

Data model changes

no change

Release notes snippet

Please advice which patching can fix this problem, thank you

Problem/Motivation

The constructor for \Drupal\media_library\MediaLibraryState should not be public, since it is not a valid way to create the object, since the create method is a static factory.

It looks like this is just an omission from the initial implementation.

Steps to reproduce

Proposed resolution

Swap out public for private, in \Drupal\media_library\MediaLibraryState::__construct

Remaining tasks

Do it.

User interface changes

None

API changes

Close off an unused and invalid API.

Data model changes

None

Release notes snippet

Not required.

Problem/Motivation

Steps to reproduce

1. Fresh Install Drupal 11.
2. After user login search anything from header Search bar.
3. Open Advanced search tab and you will find the issue under the Type and Languages box.

Proposed resolution

Add padding on right side.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

https://blog.jquery.com/2024/07/17/second-beta-of-jquery-4-0-0/

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

TypeError: array_merge(): Argument #1 must be of type array, string given in array_merge() (line 137 of core/lib/Drupal/Core/Render/Element/RenderElement.php

This issue manifests in PHP 8.1 but does not in PHP7.4.

Upgrade to Drupal 9.4.8 and PHP 8.1

try/catch around line 137 of core/lib/Drupal/Core/Render/Element/RenderElement.php i.e:

try {
        $element['#attributes']['class'] = array_merge($element['#attributes']['class'], $class);
} catch (\TypeError $t) {}

The website encountered an unexpected error. Please try again later.
TypeError: array_merge(): Argument #1 must be of type array, string given in array_merge() (line 137 of core/lib/Drupal/Core/Render/Element/RenderElement.php).

array_merge('add_systems', Array) (Line: 137)
Drupal\Core\Render\Element\RenderElement::setAttributes(Array, Array) (Line: 102)
Drupal\Core\Render\Element\Checkbox::preRenderCheckbox(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: 39)
__TwigTemplate_d6ea8ee46b5e1dadfd78d9056abf346f->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('core/modules/system/templates/system-config-form.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('system_config_form', Array) (Line: 422)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 201)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 241)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 564)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 242)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 132)
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: 174)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 81)
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: 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)

Problem/Motivation

This task is a proof-of-concept for #3404409: [Plan] Gradually replace Drupal's AJAX system with HTMX as requested by @nod_.

Reference Links

• Ajax API
• HTMX reference documentation
• HTMX contrib module

Remaining tasks

1. One or two examples (at least) of replacements for existing core ajax
2. A list of the various ajax commands we have in core and their feasibility
   (with a very rough complexity estimate easy/hard) with htmx
   • #wrapper (content replacement) does this use InsertCommand or one of it's descendants for implementation?
   • AddCssCommand
   • AddJsCommand
   • AfterCommand
   • AlertCommand
   • AnnounceCommand
   • AppendCommand
   • BeforeCommand
   • ChangedCommand
   • CloseDialogCommand
   • CloseModalDialogCommand
   • CssCommand
   • DataCommand
   • FocusFirstCommand
   • HtmlCommand
   • InsertCommand
   • InvokeCommand
   • MessageCommand
   • OpenDialogCommand
   • OpenModalDialogCommand
   • OpenOffCanvasDialogCommand
   • PrependCommand
   • RedirectCommand
   • RemoveCommand
   • ReplaceCommand
   • RestripeCommand
   • SetDialogOptionCommand
   • SetDialogTitleCommand
   • SettingsCommand
   • TabledragWarningCommand
   • UpdateBuildIdCommand
   • UpdateSelectionCommand
3. Test runs don't need to be green, although it' be nice if a couple of them
   were passing.
4. can we use this to handle ajax form submit? if yes, how complex does it
   look? would be great to drop our jquery formsubmit fork
5. A big thing here is to improve DX, so a couple of examples of how it could
   make it easier to introduce some ajax stuff in contrib/projects would be
   good.
6. rough dependency evaluation
   (See Criteria for adding dependencies)
7. BC strategy (support existing calls, or a new codepath altogether, etc.)
   I'm not too keen on two separate mods. I feel it'll make adoption much, much
   slower than spending time on the BC layer even if it takes a long time. (we
   can always put restrictions on what the BC layer can do) if we have 2 code
   paths, we'd need a contrib module to bridge the two and let contrib
   maintainers test with htmx easily without changing their code

User interface changes

API changes

Data model changes

Release notes snippet

I moved my drupal10 site from www.abc.com to a subdomain http://abc.sss.com, then I get this error on the screen : please help if you know how to fix this , Thanks

The website encountered an unexpected error. Try again later.

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "entity_bundle:node" plugin does not exist. Valid plugin IDs for Drupal\rules\Core\ConditionManager are: rules_user_is_blocked, rules_path_has_alias, rules_user_has_role, rules_entity_has_field, rules_entity_is_of_bundle, rules_data_is_empty, rules_text_comparison, rules_node_is_published, rules_list_contains, rules_data_comparison, rules_entity_is_of_type, rules_list_count_is, rules_node_is_sticky, rules_path_alias_exists, rules_node_is_promoted, rules_entity_is_new, rules_node_is_of_type, rules_entity_field_access in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

Drupal\Core\Plugin\DefaultPluginManager->getDefinition('entity_bundle:node') (Line: 16)
Drupal\Core\Plugin\Factory\ContainerFactory->createInstance('entity_bundle:node', Array) (Line: 67)
Drupal\Core\Condition\ConditionManager->createInstance('entity_bundle:node', Array) (Line: 21)
Drupal\rules\Core\ConditionManager->createInstance('entity_bundle:node', Array) (Line: 81)
Drupal\Core\Plugin\DefaultLazyPluginCollection->initializePlugin('entity_bundle:node') (Line: 80)
Drupal\Component\Plugin\LazyPluginCollection->get('entity_bundle:node') (Line: 26)
Drupal\Core\Condition\ConditionPluginCollection->get('entity_bundle:node') (Line: 149)
Drupal\Component\Plugin\LazyPluginCollection->getIterator() (Line: 88)
Drupal\block\BlockAccessControlHandler->checkAccess(Object, 'view', Object) (Line: 109)
Drupal\Core\Entity\EntityAccessControlHandler->access(Object, 'view', Object, 1) (Line: 329)
Drupal\Core\Entity\EntityBase->access('view', NULL, 1) (Line: 63)
Drupal\block\BlockRepository->getVisibleBlocksPerRegion(Array) (Line: 138)
Drupal\block\Plugin\DisplayVariant\BlockPageVariant->build() (Line: 270)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 128)
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: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.view') (Line: 186)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 53)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 191)
Drupal\page_cache\StackMiddleware\PageCache->fetch(Object, 1, 1) (Line: 128)
Drupal\page_cache\StackMiddleware\PageCache->lookup(Object, 1, 1) (Line: 82)
Drupal\page_cache\StackMiddleware\PageCache->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: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 741)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Problem/Motivation

Drupal has a lot of areas where we have added a new feature/API etc. which is capable of replacing something else, but that replacement has never happened, leading to two or more, often confusing, ways to do things, or a general level of unevenness across core where legacy and new ways to do things conflict or don't combine well. This goes across site builder features, PHP, theming, JavaScript, docs.

Opening this issue to collect some of the issues trying to address this. While the individual issues don't necessarily have much in common, at lot of them have common themes at a higher level. Also because I'm in the middle of drafting a blog post about this and need an issue to link to.

This doesn't have to be strictly about when there are two ways of doing things in core, it can also cover when finishing a core feature properly would allow it to replace a contributed modules (entity API for example).

Steps to reproduce

Proposed resolution

Remaining tasks

#2353867: [META] Expose Title and other base fields in Manage Display [META] Expose Title and other base fields in Manage Display
#3365551: Add the notion of a 'configured layout builder block' to solve a number of content-editor and performance pain points Add the notion of a 'configured layout builder block' to solve a number of content-editor and performance pain points
#3238306: [META] Where possible, refactor existing jQuery uses to vanillaJS to reduce jQuery footprint Refactor jQuery to use vanilla js
#2880237: Refactor system/base library Refactor system/base library
#3203920: Replace Contextual Links BackboneJS usage with VanillaJS equivalent Replace backbone with vanilla js
#3063877: Add access control to /filter/tips Add access control to /filter/tips
#3347343: Continuation Add Views EntityReference filter to be available for all entity reference fields Add Views EntityReference filter to be available for all entity reference fields
#2158943: Add a native dialog element to deprecate the jQuery UI dialog Native dialog element
#3442009: OOP hooks using attributes and event dispatcher OOP hooks
#1823450: [Meta] Convert core listings to Views Convert core listings to views
#3404214: META: Reduce / eliminate “jank” (layout shifts) within Drupal’s admin UI Eliminate layout shifts / jank in the admin UI
#3396165: [meta] Convert all core plugin types to attribute discovery Convert all plugins to attributes from annotations
#3372932: [Meta] High-performance images (nearly) out of the box High performance images out of the box
#1804614: [meta] Consolidate similar twig templates and properly use theme suggestions in core Consolidate twig templates and use theme suggestions
#3362353: Deprecate the Number (float), and List (float) field types and move them to contrib Move float and list (float) fields to contrib
#3458587: Deprecate preprocess variable cruft in core Deprecate template variable cruft in core
#3252084: [meta] Remove support for IE11 Remove IE11 support
#2346347: Finalize API for creating, overriding, and altering code-defined bundle fields Finalize bundle field API
#3398525: Add an API for importmaps Add an importmaps API
#3398293: Consolidate local development environment documentation to recommend DDEV Consolidate local development environment documentation to recommend DDEV
#2875151: [META] Implement Batch API as a service Batch API as a service
#3426579: Update parts of Umami that are falling behind Update parts of Umami that are falling behind
#1803948: [META] Adopt the symfony mailer component Symfony mailer
#3439331: [policy] Decide on format of commit message [policy] Decide on format of commit message
#2954834: Add poster image to HTML5 media videos Add poster image to HTML5 media videos
#3028968: Create Javascript library for searching/filtering rendered lists on the client. Create Javascript library for searching/filtering rendered lists on the client.
#3100110: Convert update_calculate_project_update_status() into a class Convert update_calculate_project_update_status() into a class
#2544110: XSS attribute filtering is inconsistent and strips valid attributes XSS filter carnage

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

NULL results are being passed to array_filter function.
Issue 3348686 allows for modules to provide translations for specific links using an implementation of moduleHandler->alterhere. The problem is that this occurs after checking for empty results. Certain implementations of the moduleHandler->alter may empty this results array (see issue 3358576 for language_switcher_extended module). This can result in an empty result array being passed to the array_filter function causing error.

          if (!empty($result)) {
            // Allow modules to provide translations for specific links.
            $this->moduleHandler->alter('language_switch_links', $result, $type, $url);

            $result = array_filter($result, function (array $link): bool {}

Although this issue is caused by the calling of moduleHandler->alter and works assuming all defaults, it should safely handle cases where a NULL value is passed as result by other core or contrib alterations.

Steps to reproduce

1. Steps to reproduce
2. Install all of the core Multilingual modules
3. Add another language
4. Enable a content type for content translation (including its published field)
5. Use URL -> Path for the language detection
6. Place the Language switcher content block
7. configure a 3rd party module (for example, language switcher extended) to hide block when no translation is expected.
8. Select Alter the language switcher for untranslated content entities
9. Select Hide the language switcher link for the untranslated handler
10. Navigate to a page with no translations

Proposed resolution

Add an additional !empty() check after all modules have made alterations to the link list.

Problem/Motivation

After Updating to Drupal ~10.3.0 Contextual disappears intermittently, leading to console errors

settings_tray.js?v=10.3.0:171 
Uncaught  TypeError: Cannot read properties of null (reading 'id')
    at settings_tray.js?v=10.3.0:171:31
    at Array.forEach (<anonymous>)
    at prepareAjaxLinks (settings_tray.js?v=10.3.0:162:8)
    at HTMLDocument.<anonymous> (settings_tray.js?v=10.3.0:191:5)
    at HTMLDocument.dispatch (jquery.min.js?v=3.7.1:2:40035)
    at v.handle (jquery.min.js?v=3.7.1:2:38006)
    at Object.trigger (jquery.min.js?v=3.7.1:2:70124)
    at HTMLDocument.<anonymous> (jquery.min.js?v=3.7.1:2:70726)
    at Function.each (jquery.min.js?v=3.7.1:2:3129)
    at ce.fn.init.each (jquery.min.js?v=3.7.1:2:1594)

Steps to reproduce

• Drupal ~10.3.0
• Place inline block via layout builder or block via block layout
• Observe the issue.

Note that the issue doesn't always appear, so clearing the cache and then reloading sometimes causes the issue to occur. Additionally, the layout builder block's contextual feature sometimes breaks, resulting in the same error.

Proposed resolution

instance.options.data.dialogOptions.settingsTrayActiveEditableId = closestSettingsTray ? closestSettingsTray.id : undefined; instead of instance.options.data.dialogOptions.settingsTrayActiveEditableId = closestSettingsTray.id;

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Drupal Nightwatch tests are very limited in making changes for tests, compared to PHPUnit Browser tests, because we have no access to the Drupal Kernel at all.

Therefore, a popular workaround for this limitation is creating a special helper module to implement the PHP part for specific tests.
We already have such modules in Drupal Core even for PHPUnit tests, for example, modules/action/tests/action_form_ajax_test.

But the problem is that we can't install them in Nightwatch tests, because it requires a specific setting to be enabled in the settings.php:

$settings['extension_discovery_scan_tests'] = TRUE;

Steps to reproduce

1. Make a custom module, and mark it as hidden in the info.yaml file:

name: My module Test Helper
type: module
package: Testing
hidden: true

2. Try to install this module in a Nightwatch test.

You will see an error that this module is missing in the list of modules to install.

Proposed resolution

Set the setting to show all hidden modules to true in the Nightwatch command drupalInstall() by default.

Or add a separate parameter to control this setting.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

We have many meta packages to help projects run with the right set of dependencies:

• drupal/core-recommended
• drupal/core-dev
• ..and an even more strict package: drupal/core-dev-pinned

These packages are released together and share the same versions.

Although these are independent packages, they are semantically and practically tied together. You might be able to use different versions of these packages (different minor, patch, but likely not a different major version), but usually, you encounter unexpected issues when these packages are not in sync.

For example, when creating a new project from drupal/recommended-project and you want to run tests, you are supposed to composer require drupal/core-dev. However, that package doesn't depend on core, so if you're not careful, you might end up with a different version of core-dev than the core version you are using, causing things to fall apart.

Moreover, even if the Updating Drupal core with Composer guide suggests running composer update "drupal/core-*" --with-all-dependencies to keep Drupal core and metapackages up to date on existing projects, this command does not guarantee that the versions of the installed metapackages will match. This command instructs Composer to try to update all matching packages, but conflicts and version constraints in other packages can prevent one or more matching packages from being updated. This issue is discussed in this Drupal Slack thread about failing PHPUnit tests due to an incorrect behat/mink version installed on projects after the Drupal 10.2.x to 10.3.x update.

Steps to reproduce

1. composer create-project 'drupal/recommended-project:^8.9' d8_9_composer
2. cd d8_9_composer
3. composer require drupal/core-dev

You would expect to get drupal/core-dev for 8.9.x and have a working testable site. Instead, you see this:

Using version ^9.0 for drupal/core-dev
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Conclusion: don't install drupal/core-dev 9.0.2
    - Conclusion: don't install drupal/core-dev 9.0.1
    - Conclusion: don't install drupal/core-dev 9.0.0
    - Conclusion: don't install drupal/core-dev 9.0.0-rc1
    - Conclusion: don't install drupal/core-dev 9.0.0-beta3
    - Conclusion: don't install drupal/core-dev 9.0.0-beta2
    - Conclusion: don't install drupal/core-dev 9.0.0-beta1
    - Conclusion: don't install drupal/core-dev 9.0.0-alpha2
    - Conclusion: don't install drupal/core-dev 9.0.0-alpha1
    - Conclusion: don't install drupal/core-dev 9.1.x-dev
    - Conclusion: remove masterminds/html5 2.3.0
    - Installation request for drupal/core-dev ^9.0 -> satisfiable by drupal/core-dev[9.0.0, 9.0.0-alpha1, 9.0.0-alpha2, 9.0.0-beta1, 9.0.0-beta2, 9.0.0-beta3, 9.0.0-rc1, 9.0.1, 9.0.2, 9.0.x-dev, 9.1.x-dev].

For this to work, step #3 should be composer require 'drupal/core-dev:^8.9'.

Proposed resolution

As @stof suggested in this Composer discussion, we could use the self.version constraint to keep package versions in sync. Instead of using "drupal/core-recommended" : "self.version", we should use "drupal/core": "self.version" since both drupal/core-recommended and drupal/core-dev packages can and should depend on drupal/core.

Remaining tasks

• Create a change record

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Problem/Motivation

system.theme has 2 property path that are not yet validatable:

./vendor/bin/drush config:inspect --filter-keys=system.theme --detail --list-constraints
➜  🤖 Analyzing…

 Legend for Data: 
  ✅❓  → Correct primitive type, detailed validation impossible.
  ✅✅  → Correct primitive type, passed all validation constraints.
 ----------------------------------------- --------- ------------- ------ -------------------------------------------- 
  Key                                       Status    Validatable   Data   Validation constraints                      
 ----------------------------------------- --------- ------------- ------ -------------------------------------------- 
  system.theme                              Correct   60%           ✅❓   ValidKeys: '<infer>'                        
                                                                           LangcodeRequiredIfTranslatableValues: null  
   system.theme:                            Correct   Validatable   ✅✅   ValidKeys: '<infer>'                        
                                                                           LangcodeRequiredIfTranslatableValues: null  
   system.theme:_core                       Correct   Validatable   ✅✅   ValidKeys:                                  
                                                                             - default_config_hash                     
   system.theme:_core.default_config_hash   Correct   Validatable   ✅✅   NotNull: {  }                               
                                                                           Regex: '/^[a-zA-Z0-9\-_]+$/'                
                                                                           Length: 43                                  
                                                                           ↣ PrimitiveType: {  }                       
   system.theme:admin                       Correct   NOT           ✅❓   ⚠️  @todo Add validation constraints here   
   system.theme:default                     Correct   NOT           ✅❓   ⚠️  @todo Add validation constraints here   
 ----------------------------------------- --------- ------------- ------ -------------------------------------------- 

Steps to reproduce

1. Get a local git clone of Drupal core 11.x.
2. composer require drupal/config_inspector— or manually install https://www.drupal.org/project/config_inspector/releases/2.1.5 or newer (which supports Drupal 11!)
3. composer require drush/drush
4. vendor/bin/drush config:inspect --filter-keys=system.theme --detail --list-constraints

Proposed resolution

Add validation constraints to:

1. system.theme:admin
2. system.theme:default

For examples, search *.schema.yml files for the string constraints:😊

Reach out to @borisson_ or @wimleers in the #distributions-and-recipes.

Remaining tasks

User interface changes

None.

API changes

Data model changes

More validation 🚀

Release notes snippet

None.

Problem/Motivation

datetime-wrapper.html.twig element label uses an <h4> tag instead of the <label> tag.

This is problematic for assistive tech, since the "label" is not associated with anything.

For example, any node form in core has an "Authored on" datetime form element. The individual date and time inputs already have <label for>. For assistive tech, these are programmatically labelled as "date" and "time". However there's no programmatically-determinable association between these inputs and the phrase "authored on".

This <h4> also helps breaks #states support for datetime elements, but that's being addressed in #2419131: [PP-1] #states attribute does not work on #type datetime, not here.

Proposed resolution

Option A: Nested fieldsets:

Option A is now the agreed upon solution, with sign-off from @andrewmacpherson and @lauriii.

The "authored on" group would be improved by treating it as a fieldset with at legend, instead of a <h4>.

In the case of a single datetime field (Field API, datetime module) we already get a fieldset, using the the field name as a legend. The individual date and time inputs have <label for>, so screen reader users skipping through form elements will hear "preferred date, date" (for example). That's great for a single-value datetime field.

In the case of a datetime range field (datetime_range module), the field name is treated as a legend, but the start and end each have a h4 from the datetime-wrapper. This might be better with nested fieldsets (field_name (legend) > start date (legend) > date (label). Nested fieldsets are sometimes confusing for screen reader users though, so we'd want to tread carefully here.

Nested fieldsets would also be ugly and potentially confusing once #2625136: Fix label visibility and add wrapper container for exposed numeric/date filters with multiple form elements lands, too.

Option B: WAI-ARIA labeledby + group

Nice thought, but rejected. See #27 for reference.

Remaining tasks

1. Discuss and agree on an approach. Option A it is.
2. Fix implementation to not generate duplicate IDs and other problems with patch #35
3. Figure out how to properly deprecate the datetime-wrapper template + pipeline: #3157353: Provide a mechanism to mark entire twig templates as deprecated
4. Update / add tests as needed.
5. Fix any accessibility concerns with nested fieldsets.
6. Fix obvious visual stuff we can do to make this prettier by default.
7. Reviews:
   • General implementation / code review
   • Needs accessibility review
   • Needs usability review
8. Write change record about the render array changes, deprecation of the datetime-wrapper template, etc
9. RTBC.
10. Commit.
11. Unblock #2419131: [PP-1] #states attribute does not work on #type datetime (which is thankfully mostly solved by this approach, but will need some follow-up fixes)

User interface changes

Definitely something. Exact changes TBD.

API changes

None.

Data model changes

None.

Release notes snippet

TBD.

Original report by @tormi

datetime-wrapper.html.twig element label uses <h4> tag instead of default <label> tag.

Problem/Motivation

WebAssertTest is slow. It even declares itself as such. It has 25 individual tests and each of them enable the test_page_test module, then perform one or more drupalGet calls. On my localhost this takes almost 4 minutes! After converting to a Unit test this takes 89 ms!

Steps to reproduce

phpunit --configuration /path/to/core/phpunit.xml.dist /path/to/core/tests/Drupal/FunctionalTests/WebAssertTest.php

Proposed resolution

Create a lightweight mock client that extends \Symfony\Component\BrowserKit\AbstractBrowser and allows tests to set expected responses. Convert the test to a Unit test.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

CoreRecipesTest appears to be the single longest running functional test, this is because it uses a dataprovider to install 25 different recipes, meaning core has to be installed 25 times.

See https://git.drupalcode.org/project/drupal/-/jobs/2157400 test run duration 4m25s. All other functional test jobs tend to finish in 4m or less.

vs https://git.drupalcode.org/project/drupal/-/jobs/2157401 4m

or https://git.drupalcode.org/project/drupal/-/jobs/2157404 3m29s

Steps to reproduce

Proposed resolution

I tried to ditch the data provider and just apply every recipe twice in a foreach loop instead, but got:

1) Drupal\FunctionalTests\Core\Recipe\CoreRecipesTest::testApplyRecipe
In ConfigConfigurator.php line 47:
                                                                               
  The configuration 'block.block.claro_messages' exists already and does not   
  match the recipe's configuration                                             
    

Can we do something more like GenericTest where we add a test for every recipe, but where that test is a minimal subclass of a recipe test base class?

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Implementing strict typing in existing code is challenging. If we don't enforce it on new code we'll constantly be chasing our tail.

Steps to reproduce

Proposed resolution

• Enable MissingFunctionReturnTypehintRule and MissingMethodReturnTypehintRule phpstan rules
• Ignore missingType.iterableValue
• Update the phpstan baseline to include all violations of this rule
• ???
• Profit

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

It has been years since the last review of mentoring coordinators section of MAINTAINERS.txt. Since that review, some people have defacto stepped down and some have stepped up to lead the mentoring efforts.

Proposed resolution

1. Ask all people currently listed as core mentoring coordinators:

- Chris Darke 'chrisdarke'https://www.drupal.org/u/chrisdarke
- Mauricio Dinarte 'dinarcon'https://www.drupal.org/u/dinarcon
- Brian Gilbert 'realityloop'https://www.drupal.org/u/realityloop
- Lucas Hedding 'heddn'https://www.drupal.org/u/heddn
- AmyJune Hineline 'volkswagenchick'https://www.drupal.org/u/volkswagenchick
- Tara King 'sparklingrobots'https://www.drupal.org/u/sparklingrobots
- Rachel Lawson 'rachel_norfolk'https://www.drupal.org/u/rachel_norfolk
- Elli Ludwigson 'ekl1773'https://www.drupal.org/u/ekl1773
- Jess Myrbo 'xjm'https://www.drupal.org/u/xjm
- Matthew Radcliffe 'mradcliffe'https://www.drupal.org/u/mradcliffe

2. Move people who have stepped down, to the past maintainers page

3. Remove people who have stepped down from MAINTAINERS.txt

4. Add new de-facto coordinators: TBD

Remaining tasks

• Ask current maintainers what is their actual status with the core mentoring program
• Create patch
• Update past maintainers page