Problem/Motivation

Currently when adding services as properties in tests you need to declare the properties and initialize them in ::setUp. This is unnecessary boilerplate.

Steps to reproduce

Proposed resolution

Add a trait similar to AutowireTrait to initialize the services in setUp.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

One of the most difficult things about manipulating Drupal forms is the process of manipulating the arrays themselves. And one of the things that I commonly want to do is "stick this stuff in after that". But I have yet to find a PHP function to manipulate arrays in this way.

So I wrote this function called array_insert(). Perhaps there's a cleaner way to handle this, but it seems like a function that should be available in Drupal core. It would certainly help with a lot of common hook_form_alter() tasks.

For instance, this function (finally) offers a way to stick something into the node-type settings page (admin/settings/content-types/[node-type]) immediately before the "submit" buttons, you'd just create an array with your form items and then call

$form = array_insert($form, 'buttons', $my_stuff, TRUE);

/**
 * Inserts values from $arr2 after (or before) $key in $arr1
 * if $key is not found, $arr2 is appended to $arr1 using array_merge()
 *
 * @param $arr1
 *   array to insert into
 * @param $key
 *   key of $arr1 to insert after
 * @param $arr2
 *   array whose values should be inserted
 * @param $before
 *   insert before the given key. defaults to inserting after
 * @return
 *   merged array
 */
function array_insert($arr1, $key, $arr2, $before = FALSE){
  $done = FALSE;
  foreach($arr1 as $arr1_key => $arr1_val){
    if(!$before){
      $new_array[$arr1_key] = $arr1_val;
    }
    if($arr1_key == $key && !$done){
      foreach($arr2 as $arr2_key => $arr2_val){
        $new_array[$arr2_key] = $arr2_val;
      }
      $done = TRUE;
    }
    if($before){
      $new_array[$arr1_key] = $arr1_val;
    }
  }
  if(!$done){
    $new_array = array_merge($arr1, $arr2);
  }
  return $new_array;
}

Steps to reproduce

N/A

Proposed resolution

Introduce new utility class for addressing the problem.

Remaining tasks

Review
Commit

User interface changes

N/A

Introduced terminology

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Problem/Motivation

There are several places in core where the user searches in a text area to filter a list that is already rendered on the page. This filtering does not require any call back to the server.

1. Current uses
2. Place block on Block layout
3. Views listing
4. Extend(modules listing)
5. In progress #2998862: The Layout Builder block listing should be filterable
6. VIew add field popup https://gyazo.com/bd957018d522cf27725c505cfa0ffe7c
   This one seems can be ignored for now. It has extra selectbox for category.

All of the these instances use their own Javascript and don't use a shared solution.

Proposed resolution

Investigate and determine if these use cases could shared a javascript library to perform this filtering.

If they share a enough functionality and it could be generalised then let's make library for it.

Remaining tasks

Determine if it is a good idea, are they really the same use case
Create central solution
Determine if this library should be internal or available outside of core.

User interface changes

None

API changes

A new Javascript API for filtering rendered lists

Data model changes

None

Release notes snippet

TBD, If this a Javascript ApI that is not @internal then we will need release notes for how to use it.

Problem/Motivation

I am not able to access some second level pages through the navigation toolbar. For example, under "Structure", there is a page at /admin/structure/types that I cannot get to. Clicking the "Content types" link expands its child links but itself does not link to the page it's supposed to.

Steps to reproduce

• On a Drupal site with navigation installed, attempt to go to the Content types page at /admin/structure/types (Structure > Content types) through the navigation.

Proposed resolution

Add an "Overview" or "All" link under these second-level links that allow you to get to these currently inaccessible pages.

Problem/Motivation

Field UI allows you to select multiple target bundles for a field. However, the views term filter only allows you to filter on terms from a single vocabulary.

Proposed resolution

Allow to set multiple vocabularies

Before:

After:

Remaining tasks

Pleaes review MR !3681 see #242 and #247 for details.

User interface changes

Site builders are able to filter on terms across multiple taxonomy vocabularies (see the screenshots).

API changes

None.

Data model changes

The 'vid' key in 'views.filter.taxonomy_index_tid' config schema is deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. The new key 'vids' (sequence of strings) is added to 'views.filter.taxonomy_index_tid' config schema as the replacement.

Release notes snippet

When using the Has taxonomy term views filters, site builders are able to filter on terms across multiple vocabularies.

Problem/Motivation

The module linked_field supports adding a link around fields with the related field being selectable from link fields in the bundle that the display relates to.

There is some logic to find the bundle in hook_field_formatter_settings_summary_alter

 $bundle = $field_definition->getTargetBundle();
  if (!$bundle) {
    $bundle = $form['#bundle'] ?? NULL;
  }

This works with layout builder for image fields, but not for title fields (generic fields, fields shared across bundles?).

Steps to reproduce

Specific to linked_field, although this issue is related to the bundle information being passed to the hook generally

- install 'linked_field' composer require drupal/linked_field && drush en -y linked_field
- Create a link field on the content type.
- Edit a layout with layout builder. e.g. go to article.
- Place the title block in the layout
- Try to 'link this field'.
- result is 'no fields available'. The expected result is a select list with the link field listed.

The field settings form with an image

Title does not

Possibly similar issues - Create a link field on the content type.

Proposed resolution

it is impossible to check whether this issue happens when laying out fields without layout builder as you can't access title settings. The layout builder call stack seems to be called without 'Use Layout Builder' checked. Possibly the error is in 'Entity View'?

$plugin has the view_mode. Why not bundle?

- $field_definition has the bundle property set to null
- $form does not have a 'bundle' entry

$view_mode is also passed to the hook

Better still implement the event FIELD_FORMATTER_SETTINGS_SUMMARY_ALTER

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Node local tasks tabs do not appear on node revisions on entity.node.revision route. As a content author, I would expect to see the tabs when navigating to previous revisions, so I could navigate back to the revisions path, view or edit the node.

Steps To Reproduce

* Install Drupal Standard profile
* Create basic page content item and save
* Edit same page node, create new revision
* Go to node's revisions tab, node/1/revisions
* Click the initial node revision to view it, /node/1/revisions/1/view
* Observe no tabs present on revision path

Notes

* adding the following link to node.links.task.yml, displays all tabs, but duplicates Revisions tabs: 1 for entity.node.version_history route/task and one for entity.node.revision route/task

entity.node.revision:
  route_name: entity.node.revision
  base_route: entity.node.canonical
  title: 'Revisions'

Problem/Motivation

A child of #3312966: Enforce the use of CSS Logical Properties in core to do the simple conversions to using CSS Logical Properties. This will do so in CSS files that do not have a "[dir=]" or a ":dir()" rule.

Steps to reproduce

Proposed resolution

Enable logical properties and autofix.

$ cd core
$ grep --include=*.css -rL -e 'dir="rtl' -e ":dir(rtl" . | xargs yarn stylelint --fix
$ yarn build:css

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

I'm volunteering for the post of Documentation topic maintainer in core.

That is, the documentation that's in the Drupal core repository, rather than the documentation that's on d.org.

I'm particularly interested in adding more systematic, machine-readable documentation that can be parsed by API module and add to what there is at api.d.org.

Steps to reproduce

Look in MAINTAINERS.txt and see there is Documentation maintainer.

Proposed resolution

Add me as Documentation maintainer :)

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

use statements are supposed to be ordered alphabetically

Problem/Motivation

The message "To log in to this site, your browser must accept cookies from the domain" is displayed to the user when they use "Back" button and refresh the page.

Steps to reproduce

1. Login with any user
2. Log out
3. Click to go back (Back button of the browser)
4. Reload the page
5. See the message

The message is quite confusing for the user when they perform the steps above as it doesn't make sense.

Is this by design?

Problem/Motivation

PHPStan baseline is currently skipping multiple Call to an undefined method errors, #3291519: [Meta] Fix 'Call to an undefined method' PHPStan L0 errors.

Proposed resolution

Fix the error about getExpectedUnauthorizedEntityAccessCacheability.

There is one other

 ------ ------------------------------------------------------------------------------------------------------------------------------------------------ 
  Line   core/modules/rest/tests/src/Functional/CookieResourceTestTrait.php (in context of class Drupal\Tests\user\Functional\UserRegistrationRestTest)  
 ------ ------------------------------------------------------------------------------------------------------------------------------------------------ 
  106    Call to an undefined method Drupal\Tests\user\Functional\UserRegistrationRestTest::getExpectedUnauthorizedEntityAccessCacheability().        

Problem/Motivation

Split off from #3320569: Add an interface for operators() on views

Should this be an interface in the same way? Maybe warrants further discussion?

@longwave in MR of #3320569: Add an interface for operators() on views

If we are fixing the other issue by adding an interface, shouldn’t we do that here too?

@lendude on Slack

Steps to reproduce

Introduce an interface and deprecation notice similar to #3320569: Add an interface for operators() on views

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

This is blocker to upgrade composer for 10.4.x #3478331: Upgrade composer to 2.8.1 for PHP 8.4

Steps to reproduce

$ composer update composer/composer:2.8.0 -W
> Drupal\Composer\Composer::ensureComposerVersion
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires composer/composer ^2.7.7 -> satisfiable by composer/composer[2.8.0].
    - composer/composer 2.8.0 requires composer/pcre ^2.2 || ^3.2 -> satisfiable by composer/pcre[2.2.0, 2.3.0, 2.3.1, 2.x-dev, 3.2.0, 3.3.0, 3.3.1, 3.x-dev].
    - composer/pcre[2.3.0, ..., 2.x-dev, 3.3.0, ..., 3.x-dev] conflict with phpstan/phpstan <1.11.10.
    - composer/pcre[2.2.0, 3.2.0] conflict with phpstan/phpstan <1.11.8.
    - phpstan/phpstan is locked to version 1.11.0 and an update of this package was not requested.

Proposed resolution

Upgrade phpstan/phpstan to 1.11.10 as 11.x branch is using

Remaining tasks

get rid of failures, review, commit

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

For a very long time we wanted to introduce hooks in some OOP manner. The following goals altogether however have proven elusive

1. No magic naming in the implementations.
2. A hook implementation should be simple and have minimal boilerplate.
3. Calling any hook without defining anything should be possible as it is now.
4. Reordering hooks should be doable.
5. Relative reordering should be easier. ckeditor5_module_implements_alter is ouch.
6. Minimal added code to core.

Proposed resolution

Big kudos to EclipseGc for realizing the Symfony EventDispatcherInterface has a getListeners method which allows us to call listeners any way we want. Unlike dispatch this allows us to call listeners with any arguments we want without defining an event object. dpi pioneered attributes for hooks on Hux. I also advocate for attributes but simpler. In short:

namespace Drupal\node\Hook;
class NodeHooks {
  #[Hook('user_cancel')]
  public function userCancel($edit, UserInterface $account, $method) {

In detail:

1. Hook implementations go into Drupal\modulename\Hook namespace (subdirectories work too). Familiar pattern from plugins. These are automatically registered as autowired services with the class name as the service id. This makes for minimal boilerplate. If autowire doesn't suffice -- should be very rare -- they can be registered manually as well, the service id is the class name.
2. Hook implementations needs to be marked with a Hook attribute. This is new. Either on a method #[Hook('user_cancel')] or on the class #[Hook('user_cancel', method: 'UserCancel')]. If the class Hook doesn't specify a method, __invoke is the default method.
3. The attribute supports a priority as well: #[Hook('user_cancel', priority: -20)]. The priority defaults to such values as to keep module order.
4. The edge case of "implementing a hook on behalf of another module" is also supported by simply specifying the module in the attribute. It defaults to the defining module.
5. This attribute is patterned on the Symfony AsEventListener attribute which is shipped with the event dispatcher but it is only used in the full Symfony framework.
6. Multiple implementations are totally allowed on multiple axis: one method can implement multiple hooks by adding a Hook attribute for each. One module can implement a hook as many times as it wants in as many classes as it wants. This allows, for example, adding form_alter implementations firing on other conditions than form id without touching any existing implementation. For now I exempted the hooks fired via ModuleHandler::invoke from this, documentation would be needed for those, luckily very few such are used runtime: library_build_info, mail and help. For example, help expects a string return, it's not even clear what multiple implementations could mean in this case. Also, ModuleHandler::invoke is used as a replacement for a failure-tolerant $function() call, once again it's not at all clear what multiple replacements could mean.
7. Reordering hook implementation is done by manipulating the kernel listeners in service alter providers. A helper providing setBefore/setAfter/setFirst/setLast/setPriority functionality is included.
8. Old style procedural calls are integrated into the new system. Separate hook caching is removed, everything is now stored in the container. For a contrib which works in Drupal 10 and 11, you will need to 1) manually register the autowired service 2) have something like \Drupal::service(NodeHook::class)->userCancel($user); as the procedural implementation 3) mark the procedural hook implementation with the [@LegacyHook] attribute. The new system will recognize LegacyHook and just not call it instead calls the new implementation directly. The rector rule for this is here it handles the service registration, moves the function body into a method and adds attributes as needed.
9. Not much code is needed and a lot of is BC: due to the vast simplification of ModuleHandler, core/lib/Drupal/Core only becomes 72 lines longer. This is enough for the new attribute, gathering all the implementation data, registering them as event subscribers and firing them as needed. Once the BC layers are removed, it'll be significantly negative. Luckily we didn't need to provide any new facility for hook_module_implements_alter() as service provider alter can do it nor any sorting because event dispatcher does that.
10. If loading all hook classes at build time becomes a problem we already have an issue for that: #3395260: Investigate possibilities to parse attributes without reflection .
11. For API documentation purposes, it is possible to create a separate attribute class for each and move the doxygen to the constructor. An example of such an attribute is provided in HookFormAlter (without moving the doxygen for now).
12. Install hooks remain procedural. The jury is still out on hook_requirements.
13. Theme hooks remain procedural.

Remaining tasks

1. A framework manager needs to review per 61.
2. Determine if more tests are needed. There are explicit tests for new functionality and a significant number of implicit tests across core.

User interface changes

API changes

Oh my.

Data model changes

Release notes snippet

Problem/Motivation

The block module removes the the node type(content type) condition's ability to be negated. In our company we usually have clients with a lot of content types that require to show some blocks only for 1 or 2 types.

Steps to reproduce

• Navigate to any block placed in the block layout
• Click the Content types visibility vertical tab and visually view that we no longer have a checkbox/radio button to negate the condition.

Proposed resolution

Allow the user to negate the Content types visibility condition.

Remaining tasks

Manual testing with theme other than Bartik

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

When we improved ordering for tests recently, we (I) introduced a refactoring regression - made some logic apply to all test jobs, but left one if statement in which was previously only relevant for parallel gitlab jobs but is now relevant for all gitlab test jobs.

The result of this is that @group #slow is broken for phpunit tests in HEAD, we just need to remove the if statement and it all works again.

While looking at this I realised two more things:

1. The 200ms polling time in run-tests.sh dates all the way back to simpletest, but unit tests can finish in 1ms so we are probably spending seconds during unit test runs sleeping, we can safely reduce that to 2ms which will still use minimal CPU but keep the test list more full.

2. After the ordering improvements, we don't need @group #slow on several unit tests any more, it's handled by the method count and data provider logic, so can just remove it. This also makes the tests which genuinely are still unusually slow run earlier and hence finish faster.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

"The website encountered an unexpected error. Try again later." page showing after composer update to the latest drupal 10. ( my previous version was 10.2.x )

I see this in the server error log : Sat Oct 05 04:13:04.777218 2024] [access_compat:error] [pid 18239:tid 24097] [remote 20.42.10.183:21434] AH01797: client denied by server configuration: /home/xxx/public_html/web/index.php
[Sat Oct 05 04:13:04.776883 2024] [access_compat:error] [pid 18239:tid 24097] [remote 20.42.10.183:21434] AH01797: client denied by server configuration: /home/xxx/public_html/web/robots.txt
[Fri Oct 04 20:32:28.061895 2024] [authz_core:error] [pid 3684:tid 3728] [client 194.163.184.179:41684] AH01630: client denied by server configuration: /home/xxx/public_html/web/.aws
[Fri Oct 04 20:32:25.267674 2024] [authz_core:error] [pid 3684:tid 3735] [client 194.163.184.179:41678] AH01630: client denied by server configuration: /home/xxx/public_html/web/.env.bak
[Fri Oct 04 20:32:23.925373 2024] [authz_core:error] [pid 3684:tid 3720] [client 194.163.184.179:41670] AH01630: client denied by server configuration: /home/xxx/public_html/web/aws.yml
[Fri Oct 04 19:02:10.732703 2024] [authz_core:error] [pid 21660:tid 21668] [remote 154.213.185.247:35630] AH01630: client denied by server configuration: /home/xxx/public_html/web/.git
[Fri Oct 04 18:05:00.328972 2024] [access_compat:error] [pid 14029:tid 14076] [client 31.13.224.102:55494] AH01797: client denied by server configuration: /home/xxx/public_html/web/xmlrpc.php

please advise what to do to fix this problem ? Thanks

Problem/Motivation

Drupal uses specific terminology that might not be an industry standard or might not use concepts that people can accommodate in their mental models, which confuses less experienced users.

Proposed resolution

After analyzing the Card Sorting survey results (#3366986: Card Sorting survey) we (@dead_arm, @lauriii, @worldlinemine, @benjifisher, @simohell, @Emma Horrell and @ckrina) have defined several hypothesis. One of them has been that drupalisms might be having a bad impact in things like understanding Drupal, navigating or performing tasks.

So a first step to define the problem is to gather an initial list of the main existing drupalisms we are already aware of, both as a result of our own experience, previous user tests finding or other research like the one thoughtful compassion @rkoller did of several CMS admin main navigations. Another spreadsheet compares the page title, h1, primary and secondary task labels across the pages in the admin UI.

The goal of this issue is to find the drupalisms and discuss and come up with suggested alternative wording per each if needed (the solution part could be addressed in a follow-up). The goal isn't to change anything, but to come up with recommendations.

API changes

None in here.

Data model changes

None in here.

Problem/Motivation

Trying out Starshot/Drupal CMS Demo we noticed long breadcrumbs create a scrollbar in the Site

Steps to reproduce

install Starshot demo
fill out the nerd quiz..

after wards go to https://drupal-cms-dev.ddev.site/webform/nerd_quiz/submissions/1

Proposed resolution

on wider screens override
width: max-content; (set on .breadcrumb__list)

with a width: auto

@media (min-width: 62.5rem) {
.breadcrumb__list {
width: auto;
}
}

Remaining tasks

Change width of breadcrumb.

User interface changes

Before patch:

After patch:

Introduced terminology

None

API changes

None

Data model changes

None

Release notes snippet