Problem/Motivation

• PHP 7.3 is now end-of-life, and PHP 7.4 will be end-of-life in Nov. 2022.
• Drupal 9 will be supported until November 2023.
• Drupal 9.4 is probably the final minor release of Drupal 9.

Background information

• When a PHP version becomes end-of-life under PHP's own policy, some Composer packages begin dropping support for those old versions (even though the PHP version might still receive security coverage from distros).
   
• If a Drupal dependency drops support for an old PHP version, and later releases a security update, Drupal core must either increase its own minimum PHP requirement or mitigate the security vulerability another way. This notably happened with SA-CORE-2018-005, when two Drupal dependencies dropped PHP 5.5 support within a year of PHP 5.5's end-of-life by PHP, before Drupal's scheduled end of PHP 5.5 support.
   
• Creating custom mitigations can also delay the release of security fixes (which again was almost a serious issue for SA-CORE-2018-005, since the reporter was going to disclose the issue regardless of whether Drupal was fixed).
   
• The drupal/core-recommended metapackage locks dependencies to the specific lockfile version of dependencies, as does the compiled vendor/ code in Drupal tarball installations. Furthermore, the site will not be able to resolve to secure dependencies if it is on an old PHP version. This means that even if core does implement a custom mitigation, the site may still be locked into running insecure code from an insecure dependency.
   
• On the other hand, increasing Drupal's MINIMUM_PHP prevents Drupal sites from installing any Drupal updates at all unless they also increase their platform PHP version accordingly. This is extremely disruptive and dangerous, especially if it happens on a security window. Many site owners found it too disruptive even in a minor release of Drupal core.
   
• As a middle ground, the constant \Drupal::MINIMUM_SUPPORTED_PHP was introduced in #3039287: Implement changes required to remove support for PHP 5.5 and 5.6, to allow sites to be updated on old PHP versions, but still warn them that the PHP version was too old.
   

History of PHP requirements for Drupal 9

1. Here is the current text in the system requirements docs:
   https://www.drupal.org/docs/system-requirements/php-requirements#php_req...

 

2. Here's the only thing the 9.0.0 release notes said about the PHP version requirement:

   Drupal 9 requires PHP 7.3 or higher, and the version requirement for Apache has been increased to Apache 2.4.7 or higher.

3. The only CR for any D9 branch about it: https://www.drupal.org/node/3089166
    
4. Drupal 8.9 and 9.0 were not compatible with PHP 8; in fact we explicitly had to indicate they were incompatible:
   https://www.drupal.org/node/3180764
    
5. The recommended PHP version was increased in 9.2.x to 7.4 (#3214920: Increase DRUPAL_RECOMMENDED_PHP to 7.4), and again in 9.3.x to 8.0 (#3214924: Increase DRUPAL_RECOMMENDED_PHP to 8.0 in Drupal 9.3 or 9.4). Neither issue even had a CR. (They probably should have.)
    
6. Here's what HEAD does currently on PHP 7.3.
   
    

Proposed resolution

• Change the behavior of \Drupal::MINIMUM_SUPPORTED_PHP to warn on installation (rather than erroring) the same as it does on update, since various site update/deployment workflows use installation from default config.
• Increase \Drupal::MINIMUM_SUPPORTED_PHP to at least 7.4 in Drupal 9.4.

Remaining tasks

See #96, #106, #107, and #108.

Followup issues

• #3261602: Display installation warnings in the quick-start command
• Similar issue needed for Drush.
• #3261606: Provide more specific messaging about the consequences of using an unsupported PHP version

User interface changes

Before

An informational status report message is displayed:

There are no warnings on installation or update

After

A warning is displayed on the status report, informing the user that their version of PHP is too old:

The same warning is displayed in the installer:

To advance to the next screen of the installer, they have to scroll to the end of the page and click a small "continue anyway" link.

No warning is displayed yet when using the quick-start command or drush si; those would be handled in followups.

The same warning is displayed when running update.php:

A similar message is displayed when running drush updb:

[ayrton:drupal_test_site | Sat 20:27:59] $ vendor/bin/drush updb
 [warning] Your PHP installation is too old. Drupal requires at least PHP /7.4.0/. It is 
recommended to upgrade to PHP version /8.0/ or higher for the best ongoing 
support. See PHP's version support documentation [1] and the Environment 
requirements of Drupal 9 [2] page for more information.

[1] http://php.net/supported-versions.php
[2] https://www.drupal.org/docs/9/how-drupal-9-is-made-and-what-is-included/environment-requirements-of-drupal-9#s-php-version-requirement
 (Currently using PHP 7.3.33
)

Problem/Motivation

When Search module is disable receive this message on all admin nodes.

Drupal Core: 9.3.3
PHP: 7.4
OS: LINUX
Theme: Seven

Steps to reproduce

When Search is enabled the issue goes away.
When Search is disabled and I change my admin theme from Seven to Claro, the issue goes away.
Site log shows the error "The "search_form_block" was not found".

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

The value object Drupal\Core\Cache\CacheableMetadata uses the Drupal\Core\Cache\Cache methods when merging with an other CacheableMetadata object. The mergeContexts in de Cache class has a hard dependency on the container. This seems to be something that should explicitly be called by an other service instead of the hacky \Drupal::service() way.

Proposed solution would be to just assert if the given contexts are strings and if we need more validation we could do this at an other level.

Problem/Motivation

Migration::set() was provided as a work-around for the inability to properly modify migration plugin configuration at run time (#2681869: Provide clean way to merge configuration into migration plugins) - once that is committed, set() should be deprecated. The only core usages remaining after that commit are in tests, which should be changed to use the plugin manager to merge configuration.

Note that set() is documented with {@inheritdoc}, yet is not in MigrationInterface and thus is not properly documented. This fix should properly document it in the Migration class.

Proposed resolution

Add individual setters to MigrationInterface and implement them in Migration. Setters added are

• setDependencies(array $value)
• setRequirements(array $value)

In MigrateTestBase, add an optional $configuration parameter to getMigration() and executeMigration(), where $configuration is an array of values to merge into the migration definition.

In MigrateTestBase and the traits for file migrations, remove prepareMigration(). Instead, the traits add fileConfiguration(). Tests that run file migrations pass that to executeMigration().

Change the use of Migration::set() in

• MigrationPluginManager
• d6/MigrateUploadTest
• d6/FileMigrationTestTrait
• d7/FileMigrationSetupTrait
• ReferenceBase.php

Move test in MigrationTest to MigrationPluginConfigurationTest.php
Add doc bloc for Migration::set() and deprecate it.

Theses changes may require changes to migration tests in contrib.

Remaining tasks

This issue is postponed on #3262395: $migration_dependencies has inconsistent structure.

If #2953111: Only migrate role permissions that exist on the destination is fixed before this issue, then update the test. See Comment #43.14 there.

Add follow-up issues for the following contrib modules (see #85 here):

• media_migration
• location_migration
• migrate_tools
• migrate_upgrade

User interface changes

API changes

Problem/Motivation

PHP 8.1 introduces many deprecation notices that would not appear previously. In my experience, it seems that hitting one of these notices (when thrown by a contrib module) generally causes a critical error coming from Core -- Error: Class "Drupal\Core\Utility\Error" not found in _drupal_error_handler_real() (line 63 of core/includes/errors.inc).. In such cases, the deprecation message is included in the stack trace:

The website encountered an unexpected error. Please try again later.
Error: Class "Drupal\Core\Utility\Error" not found in _drupal_error_handler_real() (line 63 of core/includes/errors.inc).

_drupal_error_handler_real(8192, 'Return type of Drupal\profile\Plugin\Field\ProfileEntityFieldItemList::offsetExists($offset) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice', '/var/www/html/drupal/web/core/lib/Drupal/Core/TypedData/ComputedItemListTrait.php', 121) (Line: 346)
_drupal_error_handler(8192, 'Return type of Drupal\profile\Plugin\Field\ProfileEntityFieldItemList::offsetExists($offset) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice', '/var/www/html/drupal/web/core/lib/Drupal/Core/TypedData/ComputedItemListTrait.php', 121) (Line: 571)
include('/var/www/html/drupal/web/core/includes/bootstrap.inc') (Line: 571)
Composer\Autoload\includeFile('/var/www/html/drupal/vendor/composer/../../web/core/lib/Drupal/Core/Utility/Error.php') (Line: 428)
Composer\Autoload\ClassLoader->loadClass('Drupal\Core\Utility\Error') (Line: 44)
Drupal\Core\EventSubscriber\ExceptionLoggingSubscriber->on403(Object) (Line: 97)
Drupal\Core\EventSubscriber\ExceptionLoggingSubscriber->onException(Object, 'kernel.exception', Object)
call_user_func(Array, Object, 'kernel.exception', Object) (Line: 142)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.exception') (Line: 219)
Symfony\Component\HttpKernel\HttpKernel->handleThrowable(Object, Object, 1) (Line: 91)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 67)
Drupal\simple_oauth\HttpMiddleware\BasicAuthSwap->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: 49)
Asm89\Stack\Cors->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: 708)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Fixing/patching the deprecation seems to get rid of the notice, as well as this error handler error itself. The error handler error is problematic because it turns what should be a simple notice into a critical failure. I think that what must be happening is that the deprecation is somehow short-circuiting the autoloader or something.

Steps to reproduce

Trying to figure out simple steps to reproduce on a clean install. Not sure of a good way yet.

Proposed resolution

Unsure.

Problem/Motivation

MenuTreeParameters::addCondition allows for "more complex operations". The documentation of the operator, however, is a copy-paste from Drupal\Core\Database\Query\ConditionInterface and as such it is SQL-only. For example, LIKE is a problem because % is a wildcard only in SQL -- but LIKE doesn't work because as the doxygen says and MenuTreeStorage::loadLinks does, the $operator is taken into consideration only when $value is an array. So out of the mentioned operators only IN and BETWEEN work.

Proposed resolution

Change the doxygen to only allow for IN and BETWEEN as "complex" operators. Patch attached (it also simplified the implementation at the cost of changing tests very slightly). LIKE is solved: it's not supported. It's no longer SQL bound, IN and BETWEEN are perfectly semantic and can be mapped as necessary; entity query also supports IN and BETWEEN.

Remaining tasks

Add a unit test to confirm the exception is thrown if the invalid operation is passed

User interface changes

API changes

LIKE is no longer supported on this interface but then again it was broken anyways so noone could've used it.

Problem/Motivation

Currently, two places in core about the PHP requirements link https://www.drupal.org/docs/9/how-drupal-9-is-made-and-what-is-included/... and refer to it as the "Environment requirements of Drupal 9". That was a temporary page for Drupal 9 development and has since been deprecated.

A third place links the old Drupal-8-specific URL alias, https://www.drupal.org/docs/8/system-requirements/php, and furthermore even refers to it as the "Drupal 8 PHP requirements handbook page", which is truly confusing on Drupal 9.

The correct link is https://www.drupal.org/docs/system-requirements/php-requirements.

Proposed resolution

Use the correct link, and refer to it as the "Drupal PHP requirements" (without any specific major version) since it now covers all (8+) major versions. That way the documentation doesn't constantly get stale and out of sync.

User interface changes

String changes to link text for three strings. Current link is used in all three places.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Blocked behind #3053887: Add test coverage and document why inline blocks require a new revision to be created when modified, regardless of whether a new revision of the parent has been created

Problem/Motivation

When reverting a parent entity revision, the parent/child relationship looks like:

 +------------+   +------------+   +------------+
 |Host Entity |   |Host Entity |   |Revert VID 1|
 |VID: 1      |   |VID: 2      |   |VID: 3      |
 |Timestamp: 1|   |Timestamp: 2|   |Timestamp: 3|
 +------------+   +------------+   +------------+
       |                |                |
       v                v                |
 +------------+   +------------+         |
 |Block Entity|   |Block Entity|         |
 |VID: 1      |   |VID: 2      |         |
 |Timestamp: 1|   |Timestamp: 2|         |
 +------------+   +------------+         |
       ^                                 |
       +---------------------------------+

 Custom block entity form
 +-----------------------------+
 |$saved_entity change time: 2 |
 |$new_entity change time: 1   |
 |Validator throws error       |
 +-----------------------------+

When block entity VID 1 is loaded into the custom block form, the validator compares it against VID 2 as the "saved entity". The validator sees that a new revision has been created since VID 1 and throws an error.

Node handles this by updating the changed timestamp in \Drupal\node\Form\NodeRevisionRevertForm::submitForm when a node is reverted, but there isn't currently a process to create new entity revisions of custom blocks when a host entity is reverted.

Steps to reproduce

1. Create a node and add a basic block to it via LB
2. Create a new revision, and edit the block
3. Revert to the first revision via the Revisions screen
4. Try to edit the block again, on save you will trigger the constraint and get the error message "The content has either been modified by another user, or you have already submitted modifications. As a result, your changes cannot be saved."

Proposed resolution

Preferred solution: Create a modified version of EntityChangedConstraint for BlockContent entities that skips the constraint validation for non-reusable (also known as "inline") block entities. This validation constraint is not necessary for inline block entities because Layout Builder is already creating new revisions of blocks when the layout is saved (see \Drupal\layout_builder\InlineBlockEntityOperations::handlePreSave). There's no danger of losing content.

Alternate solution: Prematurely update the 'changed' timestamp of the block content entity in the validate function of the inline block form so it tricks the existing entity validator to passing. This seems harmless (as the 'changed' timestamp will be updated anyway when the layout is saved), but it seems better to skip validation entirely as described above.

Remaining tasks

Sam's #6 comment may need to be addressed?

User interface changes

N/A

API changes

N/A

Data model changes

An update hook is required to update the installed entity definition for BlockContent as we will be modifying the entity constraints.

Release notes snippet

TBD

Problem/Motivation

Limit this to one line easy fixes, avoid any possible controversy, or any change that would better fit with other words, such as doing chien and chiens in the same patch.

The list of words beginning with j -> m, inclusive, that are used once in one file.

Proposed resolution

Remove the following from dictionary.txt
1 -jcbfyr
2 -kthxbai
3 -layouted
4 -lazyload
5 -litererally
6 -longblob
7 -loremipsumloremipsum
8 -lowlevel
9 -mame
10 -metainformation
11 -miaus
12 -minky
13 -mjuc
14 -mlids
15 -mosie
16 -mple
17 -mtimes
18 -mysqldump
19 -myverylongurl
20 -myverylongurlexample

Remaining tasks

Review
Commit

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

if a block (either system or custom)'s visibility settings is used, it disappear from jsonapi/block/block endpoint

Steps to reproduce

1. Fresh install latest stable, and enable jsonapi module in core
2. create a custom block, e.g. "Test Block", and place it in a region, e.g. header
3. Visit /jsonapi/block/block, see if the "Test Block" shows up (it should)
4. Edit the "Test Block", under Visitbility -> page setting, add a path /test
5. Visit /jsonapi/block/block, see if the "Test Block" shows up, it won't

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Checkboxes and radios form elements can both have descriptions added to each item (or indeed other specific form properties). However, this is not documented and not widely known.

It is however covered by our tests, in FormTestCheckboxesRadiosForm:

    // Expand #type checkboxes, setting custom element properties for some but not
    // all options.
    $form['checkboxes'] = array(
      '#type' => 'checkboxes',
      '#title' => 'Checkboxes',
      '#options' => array(
        0 => 'Zero',
        'foo' => 'Foo',
        1 => 'One',
        'bar' => $this->t('<em>Bar - checkboxes</em>'),
        '>' => "<em>Special Char</em><script>alert('checkboxes');</script>",
      ),
    );
    if ($customize) {
      $form['checkboxes'] += array(
        'foo' => array(
          '#description' => 'Enable to foo.',
        ),
        1 => array(
          '#weight' => 10,
        ),
      );
    }

The slightly clearer way to do this is as follows:

    $form['checkboxes'] = array(
      '#type' => 'checkboxes',
      '#title' => 'Checkboxes',
      '#options' => array(
        'foo' => 'Foo',
        'bar' => 'Bar',
     );
   $form['checkboxes']['foo']['#description'] = 'description for the foo checkbox';

Documentation should be added to the Checkboxes and Radios element classes.

Problem/Motivation

Content of file is deprecated for 10.0 so its time to get rid of it

Proposed resolution

remove the file and usage, make sure no usage left

Remaining tasks

review/commit

User interface changes

no

API changes

no

Data model changes

no

Release notes snippet

Problem/Motivation

Using Drupal 8.9 in mobile. When going through view settings in mobile, find a little bug regarding Save and Cancel buttons in view editing page. Those buttons are too closed that should not be.

Steps to reproduce

Create a view using mobile.
Find buttons for Save/Cancel the view setting.

Proposed resolution

There should be some gap between these two buttons.

Remaining tasks

N/A

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Problem/Motivation

Here's the Plan issue #1261120: Deprecate Tracker module in D9 and move to contrib in D10 which confirmed its deprecation in Drupal core 9.4.x

Steps to reproduce

Proposed resolution

Deprecate the module

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Remove forum module from Drupal 10

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

When a deprecated module or theme is enabled, we could trigger a deprecation notice. This would help to notify contrib modules depending on a deprecated module, and also ensure that core test coverage is cleaned up when something is deprecated - we often have to remove modules from tests before removing the module.

Per #3124762: Add 'lifecycle' key to .info.yml files there's an exception when you try to install an obsolete module, so that's already covered.

Steps to reproduce

Proposed resolution

Deprecation message, "The module 'foo' is deprecated." or "The theme 'foo' is deprecated."

Remaining tasks

Review

User interface changes

API changes

Data model changes

Release notes snippet

A deprecation warning is issued when an deprecated module or deprecated theme is installed.

Problem/Motivation

Deprecated forum module in Drupal 9.4

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Steps to reproduce

Content of file is deprecated for 10.0 so its time to get rid of it

Proposed resolution

remove the file and usage, make sure no

Remaining tasks

review/commit

User interface changes

no

API changes

no

Data model changes

No

Release notes snippet

Problem/Motivation

Theme functions no longer exist in Drupal 9, but the documentation for these functions still appears in theme.api.php.

theme.api.php is used to generate the Theme system overview documentation on api.drupal.org.

Proposed resolution

Remove obsolete documentation.

API changes

None.

Data model changes

None.

The correct doxygen is "Returns the translatable object referring to the original language." this is very strange and doesn't mesh with the doxygen of say getTranslation() which doesn't mention any references. Suggested simple patch attached.