Problem/Motivation

We had to work around the fact closures cannot be serialised in #3408120: \Drupal\Core\Form\ConfigTarget is not fully serializable. We could remove this restriction by using https://github.com/laravel/serializable-closure

Proposed resolution

Add https://github.com/laravel/serializable-closure and use it in ConfigTarget.

Update https://www.drupal.org/node/3373502

Dependency evaluation

Per https://www.drupal.org/about/core/policies/core-dependency-policies/depe... :

Repository

https://github.com/laravel/serializable-closure

Licence

MIT https://github.com/laravel/serializable-closure/blob/master/LICENSE.md

Code quality

The project has extensive unit and functional test coverage, strict static analysis, and automated coding standards.

Maintainership of the package

Taylor Otwell, maintainer of Laravel

Security policies of the package

https://github.com/laravel/serializable-closure/security/policy

Expected release and support cycles

There is a regular release cadence - https://github.com/laravel/serializable-closure/blob/master/CHANGELOG.md

Other dependencies it'd add, if any

None

Remaining tasks

User interface changes

None

API changes

New API

Data model changes

None

Release notes snippet

@todo

Problem/Motivation

Came across a site recently which output duplicate HTTP headers for example:

Link: </node/123>; rel="shortlink"
Link: </node/123>; rel="revision"
Link: </node/123>; rel="shortlink"
Link: </node/123>; rel="revision"

Eventually the duplicate headers were sufficient for Varnish (4) to throw an error, along the lines of:

--  BogoHeader     Too many headers: Link: </node/123/trans
--  HttpGarbage    "HTTP/1.1%00"
--  BerespStatus   503
--  BerespReason   Service Unavailable
--  FetchError     http format error

This happened when these sets of headers were each being emitted 4 times:

$ curl -SLIXGET example.com | grep '^Link' | sort | uniq -c

      4 Link: </devel/node/123/definition>; rel="devel-definition"
      4 Link: </devel/node/123>; rel="devel-load"
      4 Link: </devel/node/123/render>; rel="devel-render"
      4 Link: </node/123/delete>; rel="delete-form"
      4 Link: </node/123/devel/token>; rel="token-devel"
      4 Link: </node/123/edit>; rel="edit-form"
      4 Link: </node/123/manage_display>; rel="display"
      4 Link: </node/123>; rel="revision"
      4 Link: </node/123>; rel="shortlink"
      4 Link: </node/123/revisions>; rel="version-history"
      4 Link: </node/123/translations/add>; rel="drupal:content-translation-add"
      4 Link: </node/123/translations/delete>; rel="drupal:content-translation-delete"
      4 Link: </node/123/translations/edit>; rel="drupal:content-translation-edit"
      4 Link: </node/123/translations>; rel="drupal:content-translation-overview"

It's almost certain that the site is doing something wrong in order to be generating these duplicate headers.

However, should core prevent the duplicate headers from being output? It's relatively simple to do so.

Patch on the way which implements this - would welcome any opinions on whether this is core's responsibility though.

The related RFC is RFC 9110 HTTP Semantics.

Steps to reproduce

See https://www.drupal.org/project/drupal/issues/2861552#comment-12120985 and https://www.drupal.org/project/drupal/issues/2861552#comment-15144040
Basically duplicate headers set through code in Event Listener or in render array is the issue.
To verify the issue see response headers in network tab.

Proposed resolution

Remove duplicate headers from response.

Remaining tasks

• Review

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Problem

Drupal does auto-commit transactions on shutdown, as discussed at #1608374: Database autocommit disabling at shutdown. At the moment, quite some code relies on that behavior.

For that to work, Drupal\Core\Database\Transaction::__destruct must run before Drupal\mysql\Driver\Database\mysql\Connection::__destruct. If the order is reversed, this results in nasty fatal errors like the following:

Fatal error: Uncaught Error: Call to a member function inTransaction() on null in /var/www/web/core/modules/mysql/src/Driver/Database/mysql/Connection.php on line 483

Error: Call to a member function inTransaction() on null in /var/www/web/core/modules/mysql/src/Driver/Database/mysql/Connection.php on line 483

Call Stack:
15.7059 86985504 1. Drupal\Core\Database\Transaction->__destruct() /var/www/web/core/lib/Drupal/Core/Database/Transaction.php:0
15.7059 86985504 2. Drupal\Core\Database\Connection->popTransaction($name = 'drupal_transaction') /var/www/web/core/lib/Drupal/Core/Database/Transaction.php:71
15.7059 86985504 3. Drupal\mysql\Driver\Database\mysql\Connection->popCommittableTransactions() /var/www/web/core/lib/Drupal/Core/Database/Connection.php:1447
15.7059 86985880 4. Drupal\mysql\Driver\Database\mysql\Connection->doCommit() /var/www/web/core/modules/mysql/src/Driver/Database/mysql/Connection.php:415

As a result the transaction is not committed. In our project, this suddenly (=zero change) popped up and reliable killed every "drush cr" or simple drush commands like "drush user:unblock".

According to https://www.php.net/manual/en/language.oop5.decon.php the object destruction order during shutdown is random:

PHP possesses a destructor concept similar to that of other object-oriented languages, such as C++. The destructor method will be called as soon as there are no other references to a particular object, or in any order during the shutdown sequence.

Steps to reproduce

Unclear.

We ran into this at drunomics on a rather large project, on CI builds, suddenly without changes to code or the docker-controlled environment. The error only happened during CLI invocations, but was reproducable also without drush.

It turns out that most of the time the object destruction order is correct and no problems arise. But somehow for CLI invocations the order can become reliable different, thus causing the problem.

Proposed resolution

Do not rely on a object destruction order that is a random. Make code work in both situations, regardless which one runs first.

Note: This appear on 10.1.x-dev so first we need to verify whether the problem can happen on 10.2.x-dev as well, since there is a new transaction manager.

API changes

-

Data model changes

-

I think having this formatter in core would be helpful.

Problem/Motivation

Since #3277784: copyRawVariables should support default route parameters menu active trail information is missing from menu items under certain circumstances. In my case I've got a view with a path and menu entry and the rendered menu item no longer sets in_active_trail to TRUE when accessing the view on a page with the menu.

This issue is broken out from a different regression: #3358402: [regression] route defaults are now automatically route parameters. There a few relevant comments there:

Comment from @znerol:

I think that $this->routeMatech->getRawParameters()->all() returns a different set of key-value pairs which in turn leads to an empty result from $this->menuLinkManager->loadLinksByroute() in MenuActiveTrail::getActiveLink():

  public function getActiveLink($menu_name = NULL) {
    [...]
      $route_parameters = $this->routeMatch->getRawParameters()->all();

      // Load links matching this route.
      $links = $this->menuLinkManager->loadLinksByRoute($route_name, $route_parameters, $menu_name);
      // Select the first matching link.
      if ($links) {
        $found = reset($links);
      }
    [...]
  }

Comment from @lisotton:

I have some routes that share the same Controller and Action, but in the route declaration it declares default parameters. For example I have the route mymodule.news_list (/news) which have the controller ListPageController::entryPoint with a default parameter called type with value news-list. Then I have another route called mymodule.articles_list (/articles) which shares the same controller, but the default parameter type with value articles-list.

Before when I was calling \Drupal::service('plugin.manager.menu.link')->loadLinksByRoute('news_list'), without any second second parameter (route params), it was returning me the menu links, but with the change in 9.5.9, I'm enforced to call \Drupal::service('plugin.manager.menu.link')->loadLinksByRoute('news_list', ['type' => 'news-list').

For me this broke many small things, like breadcrumbs, custom menu blocks, etc.

Steps to reproduce

1. Log in as admin.
2. Navigate to /admin/structure/views/add.
3. Add a view with options:
   • View name: Site content
   • Create a page: checked
   • Create a menu link: checked
   • Menu: Main navigation
4. Navigate to /site-content.
5. Inspect "Site content" main navigation item with browser tools and confirm class primary-nav__menu-link--active-trailis not present on a element.
6. Revert changes from #3277784: copyRawVariables should support default route parameters (or just comment out core/lib/Drupal/Core/Routing/Enhancer/ParamConversionEnhancer.php#L71-75).
7. Rebuild caches.
8. Navigate to /site-content.
9. Inspect "Site content" main navigation item with browser tools and confirm class primary-nav__menu-link--active-trailis present on a element.

Proposed resolution

None yet.

Remaining tasks

Come with a proposed resolution and MR.

Problem/Motivation

Error Output:
================
> [notice] Update started: system_update_10100
> [error] Cannot change the definition of field 'cache_graphql.definitions.expire': field doesn't exist.
> [error] Update failed: system_update_10100
[error] Update aborted by: system_update_10100
[error] Finished performing updates.

Steps to reproduce

1. Install Drupal 9
2. Create a database table with a name that begins with cache_. Do not have a column named expire. This table could be created in a custom module with hook_schema() or created with a SQL tool or whatever.
3. Upgrade to Drupal 10
4. drush updatedb
5. system_update_10100 will crash with "field doesn't exist".

Proposed resolution

In systrem.install on line 1800 after the foreach statement check if the cache table exist.

Problem/Motivation

Now that Gitlab is running for core its time to clean up how codequality is reported. Currently all code quality steps like esling, phpcs, phpstan, stylelint all al reported as "tests". Which is technically true, but its also possible to output those reports and have them reported in a separate tab. This would also allow showing the problems inline in the merge requests.

See: https://docs.gitlab.com/ee/ci/testing/code_quality.html#implement-a-cust...

Known issues.
We have Gitlab ultimate, so we COULD get inline errors in the mergerequests.

Unfortunately, it is only displayed on the child pipelines, this means no inline help on the MR... :disappointed: I was secretly already dreading if the child pipeline setup was going to make us run into some issues.
There is an open issue (for years) around this. But that doesnt seem to be close. We could have inline error messages in the pipeline, but not if we use childs. (https://gitlab.com/gitlab-org/gitlab/-/issues/215725).

Possible tools per lint step
The tools we use and how they could integrate into gitlab:

eslint

Add the flag --format gitlab

PHP Code Sniffer

No real support, but seems easy enough:
https://github.com/micheh/phpcs-gitlab or https://daniel-r-ness.medium.com/converting-phpcs-output-to-gitlab-codec...

PHPStan

phpstan analyze --error-format=gitlab

stylelint

https://github.com/leon0399/stylelint-formatter-gitlab

Dependency evaluation; all these are dev dependencies that do a single small task of converting tool output to a format GitLab can read, none of this is needed at runtime and will in effect only be executed on GitLab.

micheh/phpcs-gitlab

Release cycle: two releases in 2020, none since; both the plugin and the GitLab output format are stable and seemingly require no maintenance.

Security policy: none

Maintainer: Michel Hunziker https://github.com/micheh

eslint-formatter-gitlab

Release cycle: major releases approximately once a year, follows strict semver and updates when NodeJS is updated.

Security policy: none

Maintainer: Remco Haszing https://gitlab.com/remcohaszing

stylelint-formatter-gitlab

Release cycle: three releases in four years

Security policy: none

Maintainer: Leonid Meleshin https://gitlab.com/leon0399

Steps to reproduce

Run a pipeline, in the childpipeline there is a new Codequality tab. See draft MR for an mr with these changes and some real errors.

Proposed resolution

Add a few packages for the reports and export everything as codequality artifacts.

Remaining tasks

1. Implement PHPStan report
2. Implement PHPCS report
3. Implement eslint report
4. Implement stylelint report
5. Decide if the dependencies are ok like this
6. Follow up to investigate issue where child pipelines do not report codequality to their parents. See: https://gitlab.com/gitlab-org/gitlab/-/issues/215725

User interface changes

Tests tab in gitlab now only shows tests, new tab codequality with codequality issues.

API changes

Data model changes

Release notes snippet

Three new development dependencies provide GitLab-compatible output for PHP CodeSniffer, ESLint and Stylelint.

Problem/Motivation

Follow-up from: https://www.drupal.org/node/2364189#comment-9286001

I think #4 is correct, but if you search for $attributes[0] in *Pass*.php files, you'll find that HEAD currently has 6 incorrect implementations. And the only correct (i.e., #2.2) implementation is RegisterAccessChecksPass. Given that, I think it's okay for this to go in with either the incorrect implementation (#1), or with the fix proposed in #2.2. Either way, we'll need a separate issue to fix all the other ones, so if this issue adds one more, no big deal.

Proposed resolution

Implement the foreach loop over all $tagAttributes and not just the first one ...

Remaining tasks

User interface changes

API changes

Problem/Motivation

EntityAccessControlHandler::checkFieldAccess always returns allowed

This means that all fields are editable if the user has 'update' access to the entity.

We should document this as it could catch people out.

This was originally posted on security.drupal.org but cleared for a public issue by the security team

Steps to reproduce

Proposed resolution

Add additional documentation to \Drupal\Core\Field\FieldItemList::access and EntityAccessControlHandler::checkFieldAccess

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In cases where a module is installed but has no releases, update status treats the absence of releases as a failure to retrieve information, and doesn't save it as a completed check, which re-queues it for the next check. It's possible that this problem is also the source of the bug described in #1352102: pm-update unusable, hangs, loops.

Proposed resolution

When checking for releases it has been proposed to replace

if (empty($available[$key]['releases']))

with

if (!isset($available[$key]['releases']))

However in comment #27 bfroehle notes that because of the way the XML is parsed the two checks may not produce a different result.

Remaining tasks

In comment #30 NROTC_Webmaster lists steps to reproduce the issue and states that the patch, based on the proposed solution does not work. Additional testing to verify the failure of the patch would be useful, but it seems that a new approach to solve the issue is required.

User interface changes

It might be easier to identify this issue if the Update page was more explicit in list pages where the most recent attempt to retrieve released failed.

API changes

It may be necessary to parse the XML in a different way, or possibly use a different method for handling actual failures to retrieve version data.

Related Issues

Possibly #1352102: pm-update unusable, hangs, loops

Original report by dww

I'm not yet sure how far reaching this bug is, and all the possible conditions that can trigger it. However, it seems likely that it's going to create pretty major trouble for certain sites if we don't fix it... Here's the way I found it:

If you have a module on your site that doesn't actually have any releases, Update status correctly tells you it failed to fetch info about releases of that project. However, due to something about how #597484: Use the Queue API to fetch available update data is working, it appears that the queue item is never drained (or it's always re-added as soon as it failed). So, every time you reload the available updates report, it tries to fetch release data for this project again. The "Last checked for updates" is always "0 seconds", b/c it happens again every time you visit the page. :(

Granted, projects you deploy from CVS without any releases at all are pretty rare, but I have a sinking suspicion the underlying bug could be triggered by other conditions, too.

And, if you turn on the feature that has update status check status on disabled modules and themes, all you need is a *copy* of a module like this anywhere in your sites directory to hit it. For example, check out a copy of drupalorg from CVS into a sites directory and turn on the "check for disabled stuff" checkbox and you'll see the bug. Doesn't even have to pretend to be compatible with D7. :(

So, we need tests for this bug, and we need to go through the code paths for all the queue + fetch logic to make this sane.

Problem/Motivation

Not sure how i could be the first to report this; but unable to to find a post regarding this bug.

The Link field type is not sortable in Views:

This is with 9.2.6. I am sure the same for D8 but have not tested. I tested in D7 and this does work as expected.

Oddly enough there is still the config on the field itself to select which column in the link table to use for sorting:

Also, am i the only one that finds it confusing/inconsistent to have this:

Used by Style: Table to determine the actual column to click sort the field on. The default is usually fine.

when the actual section that determines Table is called Format, not Style. This inconsistency is continued on the first screen shot (Table config) where the title of the modal is "Style options". I don't really have a preference between Format or Style; but i am a huge fan of consistency.

As half of this is already there and it did work in D7; guessing not too hard to fix this - so will spend some time looking at patch.

Steps to reproduce

Proposed resolution

Add a hook_field_views_data_alter to the missing core/modules/link/link.views.inc file to set "click sortable" to TRUE.

Remaining tasks

1. write patch for setting link fields to click sortable [done]
2. test that it works [done]
3. write tests [todo]

User interface changes

This will provide a checkbox in Views table style/format settings to make Link fields sortable.

API changes

None.

Data model changes

None.

Release notes snippet

Problem/Motivation

In #2537732: PluginFormInterface must have access to the complete $form_state (introduce SubFormState for embedded forms), the SubFormState class was introduced for BlockPlugin's build/validate/submit callbacks, and additionally $form['settings'] (the sub form array) started getting passed to the build/validate callbacks, but not to the submit callback!

That means that $form is different in these two callbacks for everyone writing a BlockPlugin:

($form is $form['settings'] here)
public function blockValidate($form, FormStateInterface $form_state) {

($form is the complete/parent form here)
public function blockSubmit($form, FormStateInterface $form_state) {

Proposed resolution

We should fix this so that the $form argument passed to these callbacks is consistent.

Remaining tasks

Review the patch.

User interface changes

None.

API changes

The sub form is now passed to BlockPlugin's submitForm method, instead of the complete/parent form.

Data model changes

None.

Problem/Motivation

The Tour module is mentioned in comments outside of tests and the Tour module.

Steps to reproduce

$ grep --exclude-dir={vendor,node_modules,tour,themes,toolbar} --exclude=*.neon  -riwe "^.*[*|/].*tour" core 
core/lib/Drupal/Core/Entity/entity.api.php: * - The Tour view builder does not invoke any hooks.
core/modules/locale/src/LocaleConfigManager.php:      // as views or tour module may bring in default configuration from prior

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The Tour module is used in tests.

Steps to reproduce

$ grep --exclude-dir={vendor,node_modules,tour,themes,toolbar} -riw tour core | grep -i test
core/profiles/testing_multilingual/testing_multilingual.info.yml:  - tour
core/modules/help/tests/fixtures/update/drupal-10.access-help-pages.yml:    - tour
core/modules/help/tests/fixtures/update/drupal-10.access-help-pages.yml:  - 'access tour'
core/modules/config/tests/config_test/config/optional/config_test.dynamic.override_unmet.yml:    - tour
core/modules/system/tests/src/Functional/UpdateSystem/UpdatePathTestBaseFilledTest.php:      'tour',

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

ConfigInstallProfileOverrideTest is using tour. Need to decouple that

Steps to reproduce

Proposed resolution

Create a custom test module with optional config and update/replace tour config in test_config_overrides profile with config similar to new test module. To mimic what tour was previously doing in ConfigInstallProfileOverrideTest.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

It would be great if we could have a hook_ENTITY_TYPE_view_mode_alter(&$view_mode, \Drupal\Core\Entity\EntityInterface $entity) in order to avoid a test on the entity type when we have to use hook_entity_view_mode_alter and better target the entity types on which we want to act.
That would make the code more SOLID and readable.

I've set the version to 10.0.x-dev but since it would be a new feature, feel free to change it to 11.x-dev (even if it woudn't break anything on D10)

Remaining tasks

1. Add documentation of new hook to entity.api.php
2. Add test coverage/implementation of the hook - see \Drupal\Tests\node\Functional\NodeEntityViewModeAlterTest::testNodeViewModeChange for an example
3. Update EntityViewBuilder and any sub-classes that override ::getBuildDefaults

Problem/Motivation

This is a child issue of #3376057: [META] Add declare(strict_types=1) to all tests. After adding enabling strict types to all tests there were around 3000 errors. Fixing them all in one issue will lead to an enormous merge request that's difficult to review, as per the issue scope guidelines.

Steps to reproduce

Create the rector.php file:

<?php

use Rector\Config\RectorConfig;
use Rector\TypeDeclaration\Rector\StmtsAwareInterface\DeclareStrictTypesRector;

return static function (RectorConfig $rectorConfig): void {
  $rectorConfig->rule(DeclareStrictTypesRector::class);
  $rectorConfig->skip([
    DeclareStrictTypesRector::class => [
      __DIR__ . '/core/modules/system/tests/modules/module_test/module_test.post_update.php',
      __DIR__ . '/core/modules/workspaces/tests/modules/workspace_update_test/workspace_update_test.post_update.php',
    ],
  ]);
};

Process all test modules:

composer require rector/rector --dev
find core -type d -path "*/tests/*_test" | xargs php ./vendor/bin/rector process

Proposed resolution

• Fix all strict type issues in test modules in this issue
• Follow up #3400334: Add declare(strict_types=1) to all test modules

Remaining tasks

Finish fixing tests, namely the following.

• Drupal\FunctionalJavascriptTests\Core\CsrfTokenRaceTest
• Drupal\Tests\announcements_feed\FunctionalJavascript\AlertsJsonFeedTest
• Drupal\Tests\page_cache\Functional\PageCacheTest
• Drupal\Tests\system\FunctionalJavascript\Form\TriggeringElementTest

Once all tests pass, create a new branch and rebase without the phpcs/declare changes, i.e.
- 7e02f7c188a Add phpcs rule for strict types on test modules
- f98517b9649 Require strict types across test modules

Create a new MR with that branch.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

After #3356894: Make field selection less overwhelming by introducing groups, the "Add field" form initially shows field groups (such as Number and Reference) and ungrouped fields (such as Boolean). When a field group is selected, the fields in that group are added to the bottom of the form.

If there are a lot of field groups (and ungrouped fields) or if the browser is not tall enough, the fields at the bottom of the form may be outside the viewport.

Steps to reproduce

1. Install Drupal with the Standard profile.
2. Visit /admin/structure/types/manage/page/fields/add-field.
3. Select Reference.

Proposed resolution

1. Convert FieldStorageAddForm into a two-step form.
2. The first step shows the field groups and the ungrouped fields.
3. The second step shows the field name. If a group was selected in the first step, then it also shows the fields in that group.

Remaining tasks

User interface changes

API changes

None

Data model changes

None

Release notes snippet

N/A

Problem/Motivation

When listing the contexts available the trait uses ContextHandler::getMatchingContexts which validates against the context definition by data type as well as any constraints.

This can prevent contexts which are not always available from being selected on forms. For example, a plugin with a context definition with a NotNull constraint will not match any contexts returned form getAvailableContexts without a value.

Proposed resolution

It seems to me that when listing available contexts only the data type should be considered and any constraint validation should be left until runtime. This does have an obvious side effect of allowing the selection of contexts that aren't always available and thus may not be available at runtime, resulting in exceptions.

Step to reproduce:

Kindly see the attachment for this.