Problem/Motivation

Comments in Drupal\Core\Database\Connection state:

Database::RETURN_AFFECTED: Return the number of rows affected by an UPDATE or DELETE query. Be aware that means the number of rows actually changed, not the number of rows matched by the WHERE clause.

Meanwhile Drupal\Core\Database\Driver\mysql\Connection states:

Make sure MySQL returns all matched rows on update queries including rows that actually didn't have to be updated because the values didn't change. This matches common behavior among other database systems.

and enables PDO::MYSQL_ATTR_FOUND_ROWS, which causes the number of matched rows to be returned rather than the number of affected rows.

Steps to reproduce

Something like ./vendor/bin/drush php:eval 'echo Drupal::database()->update("users")->fields(["uid" => 0])->condition("uid", 0)->execute()' returns 1 row matched/found, even though 0 rows were affected/changed (on MySQL, sqlite and postgres).

Proposed resolution

Update documentation to explain that number of rows matched is returned, not number of rows affected?

Problem/Motivation

Simpletest and its UI is no longer used. However we still have a class at \Drupal\Tests\Listeners\SimpletestUiPrinter that turns URLs into clickable links.

PHPUnit 10 removes the —printer command line option: https://github.com/sebastianbergmann/phpunit/blob/master/ChangeLog-10.0.md

Steps to reproduce

Proposed resolution

Remove the class, it’s essentially dead code.

Remaining tasks

Figure out if we still need this.

User interface changes

API changes

Data model changes

Release notes snippet

A maximum size can be set in pixels for an image field in every content type, so that the original image can be resized to a maximum size, saving space in case the true original file won't be needed.

In that case, it would be useful to be able to apply an Original image-style so that additional image_effects can be set, such as auto-rotate or even ImageMagick arguments to allow a better optimization of the original file-size, which can reduce file-system usage.

Problem/Motivation

Drupal 9 began to add return types including object return types.

I can not find a "fixed" issue where this decision was made nor can I find a change record announcing this.

The only place this new policy is mentioned is in https://www.drupal.org/docs/develop/standards/coding-standards#s-paramet... -- but for example https://www.drupal.org/docs/develop/standards/object-oriented-code#hinting doesn't mention return types.

While PHP 7.2 added (limited) contravariance support by removing type restrictions on parameters, return types are restricted to the original before PHP 7.4.

This makes the life of core/contrib developers rather hard.

Steps to reproduce

https://3v4l.org/UPuUq

Proposed resolution

Remove object typehints from D9 and add a change notice outlining that a) scalar return typehints should be used in D9 b) all return typehints should be used in D10. My meagre grep skills found 84 outside of test code.

Remaining tasks

Decide, code, commit.

User interface changes

N/A

API changes

None. https://3v4l.org/YDrXB existing code is unaffected.

Data model changes

N/A

Release notes snippet

N/A

Problem/Motivation

i want to make more secure drupal 8 session. so even if user gets user cookie by MITM attack they won't be able to get user account access.

Steps to reproduce

i used two browser and logged in to drupal application 8 with different account.
using cookie editor and took user cookie and saved that cookie into different user account using cookie editor.
i was able to get access of other user account.

Proposed resolution

i want to bind user session cookie to user agent (user agent hash) to make cookie more secure,
so that even attacker gets user cookie they won't be able to access other users account

Remaining tasks

User interface changes

API changes

Data model changes

I am trying to add a relationship "file usage" to a view. I click the submit button, but the relationship never gets added and UI never closed. I can add other relationships as expected.

To replicate (with "standard" profile):

1. Create a new view listing node content (no displays need to be added).
2. Don't touch the base view config in any way (the default "title" field will be the only field, etc.)
3. Add a File Usage "File" relationship via the UI

After these steps the relationship config dialog reports "The handler for this item is broken or missing" and no config form is displayed. The relationship can then be saved on the view (without configuration) but cannot be used.

Immediately upon adding the relationship an error similar to the following is printed in the views UI:

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'fid' in 'field list': SELECT node_field_data.created AS node_field_data_created, node_field_data.nid AS nid, fid AS fid FROM {node_field_data} node_field_data WHERE (( (node_field_data.status = :db_condition_placeholder_0) )) ORDER BY node_field_data_created DESC LIMIT 10 OFFSET 0; Array ( [:db_condition_placeholder_0] => 1 )

And a barrage of notices are logged, containing and/or repeating:

Notice: Undefined index: id in Drupal\views\Plugin\ViewsHandlerManager->getHandler() (line 109 of /var/www/drupal-8/core/modules/views/src/Plugin/ViewsHandlerManager.php).
Notice: Undefined variable: items in Drupal\views\Plugin\views\relationship\Broken->buildOptionsForm() (line 79 of /var/www/drupal-8/core/modules/views/src/Plugin/views/BrokenHandlerTrait.php).
Notice: Undefined index: original_configuration in Drupal\views\Plugin\views\relationship\Broken->buildOptionsForm() (line 61 of /var/www/drupal-8/core/modules/views/src/Plugin/views/BrokenHandlerTrait.php).

Problem/Motivation

PhpStorm with PHP Inspections reports an error on Core profiles standard and demo_umami

Steps to reproduce

Open PhpStorm with PHP Inspections and let it index core.

Proposed resolution

Fix it. Please see attached patch.

Remaining tasks

Review

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

...

Problem/Motivation

When you try to save a node or another form, the data is not stored and you end up again on the form, with sometimes broken elements. There are no errors captured.

Steps to reproduce

The issue occurs because of the code inside the function buttonWasClicked in FormBuilder.php.
There's a check between the input and the element value in this function, to determine which button was clicked on the form.
But if you have a translation that contains a "\r\n" at the end of the translation, perhaps because the translations was copied from a word doc, the comparison does not work, as the first value only contains a newline, and the second also contains the carriage return.

Because the submit buttons fails to be discovered, the code keeps searching in sub-elements and eventually another button is used, as f.e. a file upload button.
But as this logic contains a form rebuild, the form thinks it is a multi-step form and it just loads the form instead of saving and returning to the correct destination.

Proposed resolution

The fix could be achieved by providing a trim around the values to ensure newlines and carriage returns are not part of the comparison.
If you have this issue, you could also just remove the newline from interface translation on the "Save" value, but that won't stop us from encountering this into the future again.

Remaining tasks

Please review the proposed solution.

Problem/Motivation

#3055180: [META] Symfony 5 compatibility resolved Symfony 4 deprecations in Drupal 9 for Symfony 5. We want to keep resolving deprecations in Symfony 5 towards Symfony 6 compatibility. If it is feasible to move directly from Symfony 4 in Drupal 9 to Symfony 6 in Drupal 10, it would be useful to have that option.

Proposed resolution

Keep surfacing new deprecated APIs affecting Drupal as new Symfony deprecations are added in Symfony 5 versions. This issue is used to update Symfony 4 to Symfony 5 for testing purposes only. This is also a META tracking issue for individual fixes that should go into child issues. Repeat until Symfony 5.4 is available.

Remaining tasks

We have a problem with dev requirement Prophecy. It has to do with "static" return type hinting. See: https://github.com/phpspec/prophecy/issues/527

Must haves

None at this time.

Should have for Drupal 9/10, must have for Drupal 10/11

• #3162981: [Symfony 6] Use Symfony\Component\HttpFoundation\InputBag where appropriate instead of ParameterBag
• #3209723: [Symfony 6] Symfony\Component\HttpKernel\HttpKernelInterface::MASTER_REQUEST is deprecated, use ::MAIN_REQUEST instead
• #3258380: [Symfony 6][Second try] A number of methods of the class Drupal\Core\TypedData\Validation\ExecutionContext are considered internal and Drupal should not override them.

If we are to update to Symfony 6 in Drupal 10, we also need to bridge the gap somehow for deprecation checking and updates. See #3196027: Contrib support solution needed for potential Symfony 4 to 6 upgrade, Symfony 5 only deprecations are not available in Symfony 4.

API changes

Ideally none. See child issues.

Data model changes

None.

Release notes snippet

Drupal has been updated for compatibility with Symfony 5.4. This includes adding return type hints to some methods where we were unable to find any examples or use-cases for subclassing. However, should custom code subclass one of these methods, a return type hint can be added. A list is available in the change record

The "Simpletest functionality" test now fails of PostgreSQL. This was triggered by #986992: Insane etid / {field_config_entity_type} abstraction changing the structure of the field tables, but is actually a different problem.

The problem we have is that Simpletest prefixes are long, and are added to an existing prefix. When the "Simpletest functionality" test creates a testing environment inside another testing environment, we end up with insane table names like this:

simpletest88284simpletest467931field_revision_comment_body

The problem is that index names are global in PostgreSQL and as a consequence we prefix them with the table name, ending up with a name like: simpletest88284simpletest467931field_revision_comment_body_entity_id_idx. Because all identifiers are limited to 63 characters in PostgreSQL, we end up with duplicate index names and errors like this one:

PDOException: SQLSTATE[42P07]: Duplicate table: 7 ERROR: relation "simpletest88284simpletest467931field_revision_comment_body_enti" already exists: CREATE INDEX "simpletest88284simpletest467931field_revision_comment_body_entity_id_idx" ON {field_revision_comment_body} ("entity_id"); Array ( ) in db_create_table() (line 2588 of /var/lib/drupaltestbot/pgsql/includes/database/database.inc).

There is no good solution for that, so I suggest we just reduce the length of the Simpletest prefix.

Problem/Motivation

If one enables Responsive Images module, and tries to upgrate a Drupal 7 instance without the picture module's tables being available, an exception is thrown:

Migration failed with source plugin exception: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal_blue.picture_mapping' doesn't exist: SELECT "p".*, "map"."sourceid1" AS "migrate_map_sourceid1", "map"."source_row_status" AS "migrate_map_source_row_status"\n
FROM\n
"picture_mapping" "p"\n
LEFT OUTER JOIN drupal_blue.migrate_map_d7_responsive_image_styles "map" ON machine_name = map.sourceid1\n
WHERE ("map"."sourceid1" IS NULL) OR ("map"."source_row_status" = :db_condition_placeholder_0); Array\n
(\n
    [:db_condition_placeholder_0] => 1\n
)\n
 in [docroot]/core/lib/Drupal/Core/Database/Driver/mysql/ExceptionHandler.php line 53'

This happens because the ResponsiveImageStyles migrate source plugin extends SqlBase instead of DrupalSqlBase, so the source module requirement aren't checked by Migrate Drupal's MigrationPluginManager.

Proposed resolution

ResponsiveImageStyles source plugin must extend DrupalSqlBase.

Remaining tasks

• Patch.
• Test.

User interface changes

Nothing.

API changes

ResponsiveImageStyles source plugin extends DrupalSqlBase (following Drupal's Migrate API best practices).

Data model changes

Nothing.

Release notes snippet

Hi
Trying to setup my profile in drupal 9 with Composer.
It fails on two machines, claiming that my installation profile requires drupal 8.
Digging around, I found the composer cache file provides this requirement.

{
    "packages": {
        "drupal\/cforge": [
            {
                "keywords": "Seeking co-maintainer(s)",
                "homepage": "https:\/\/www.drupal.org\/project\/cforge",
                "version": "2.0.0-beta4",
                "version_normalized": "2.0.0.0-beta4",
                "license": "GPL-2.0-or-later",
                "authors": [
                    {
                        "name": "matslats",
                        "homepage": "https:\/\/www.drupal.org\/user\/140053"
                    }
                ],
                "support": {
                    "source": "https:\/\/git.drupalcode.org\/project\/cforge"
                },
                "source": {
                    "type": "git",
                    "url": "https:\/\/git.drupalcode.org\/project\/cforge.git",
                    "reference": "2.0.0-beta4"
                },
                "dist": {
                    "type": "zip",
                    "url": "https:\/\/ftp.drupal.org\/files\/projects\/cforge-2.0.0-beta4.zip",
                    "reference": "2.0.0-beta4",
                    "shasum": "925e1db0d8278d9584046c424fcb04cf4a34455d"
                },
                "type": "drupal-profile",
                "uid": "cforge-3260474",
                "name": "drupal\/cforge",
                "extra": {
                    "drupal": {
                        "version": "2.0.0-beta4",
                        "datestamp": "1643144817",
                        "security-coverage": {
                            "status": "not-covered",
                            "message": "Beta releases are not covered by Drupal security advisories."
                        }
                    }
                }
                "require": {
                  "drupal/core":"~8.0"
                } 
            },
            {
                "version": "2.0.0-beta3",
                etc...

The require "drupal/core":"~8.0" there only applies to version 2.0.0-beta4, and not to the older versions listed below.
When I remove the require property from the above file, composer works as expected.
But what info is this cache file caching?
I've checked the code https://git.drupalcode.org/project/cforge and I'm pretty sure there's nothing there that requires 8.
I've also checked the dependencies in https://git.drupalcode.org/project/cforge/-/blob/2.0.x/composer.json although I can't be sure I've checked the whole tree.
Where should I look for this ~8.0 requirement?
Or could it be a bug or glitch in the packaging system?
Thanks for thinking it through.

Problem/Motivation

See discussion from #3223443-24: [policy, no patch] Process for dealing with EOL PHP versions during the Drupal 10 and future release cycles on.

Proposed resolution

• Deprecate \Drupal::MINIMUM_SUPPORTED_PHP in favor of a methods that returns our best estimate for the given date, based on our release schedule and PHP's known (and predicted) release cycles.
• Hardcode safe estimates in 10.0.0, and patch the methods in each minor with updated estimates.

Note that this approach only makes sense if we issue a warning on installation (rather than an error) as discussed in #2917655: Deprecate or drop PHP 7.3 support in Drupal 9.4.

Remaining tasks

TBD

User interface changes

Users on old PHP versions automatically begin seeing new informational messages or warnings on a given date, even if they are not running the latest Drupal minor.

API changes

\Drupal::MINIMUM_SUPPORTED_PHP is deprecated in favor of \Drupal\Core\PhpRequirements::minimumSupportedPhp().

Data model changes

Probably none?

Release notes snippet

Needed.

Problem/Motivation

As per #1158720-69: [policy, no patch] Add parameter type hinting to function declaration coding standards this issue proposes that all new Drupal 9 code should use scalar typehints and return typehints since our minimum PHP version is 7.3.

This is only for new code to avoid BC implications. We will work out how to change existing code (probably in Drupal 10) in #3050720: [Meta] Implement strict typing in existing code.

Proposed resolution

New methods and functions added in Drupal 9 should use scalar typehints and return typehints.

Example (pseudo-code):

public function checkAccess(string $permission) : \Drupal\Core\Access\AccessResult {
  $access_result = AccessResult::allowedIfHasPermission($this->user, $permission);
  return $access_result;
}

Post something on groups.drupal.org/core

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

N/a

Problem/Motivation

When developing #2907810: Add $entity->toUrl() and $entity->toLink() methods to allowed methods list in Twig sandbox policy it was identified that the current sandbox method matching is very broad, allowing for methods to match _any_ object. This means it could possibly lead to unintended calls to possibly unsafe methods.

By hardening this is also makes rationalizing new additions to the allowed methods like ::toUrl and ::toLink if its possible to restrict the methods to a specific interface instead of trying to guess at any place the method might exist and how safe or unsafe its usage might be.

Steps to reproduce

Proposed resolution

Modify the format of the allowed_method settings to allow targeting methods on specific interfaces or classes. Something like:

    $allowed_methods = Settings::get('twig_sandbox_allowed_methods', [
      // Only allow idempotent methods.
      EntityInterface::class . '::id',
      EntityInterface::class . '::label',
      EntityInterface::class . '::bundle',
      // Globally allowed methods.
      '::get',
      '::__toString',
      '::toString',
    ]);

Remaining tasks

Finalize how much we harden this.

User interface changes

n/a

API changes

Data model changes

Release notes snippet

TODO and needed.

Problem/Motivation

PHP 8.0 no longer has phar vulnerability ref #3181240-5: Upgrade typo3/phar-stream-wrapper 3.1.6

The TYPO3/phar-stream-wrapper still used in 9.x core because it supports PHP 7.3

Proposed resolution

remove all usages and library dependency ASAP after core will require 8.0 as minimal version

Remaining tasks

- check all usage
- remove all usages of the library (code and composer dependencies)
- patch
- review/commit

User interface changes

no

API changes

tbd

Data model changes

no

Release notes snippet

Core no longer depends on TYPO3/phar-stream-wrapper

Problem/Motivation

getting error

Error: Call to a member function access() on null in
/var/www/drupal/web/core/modules/block/src/BlockAccessControlHandler.php on line 126 #0 /var/www/drupal/web/core/lib/Drupal/Core/Entity/EntityAccessControlHandler.php(105): Drupal\block\BlockAccessControlHandler->checkAccess()

right after enabling core module Layout Builder. If I disable Layout Builder with drush everything works back as normal.

The call stack is

<ROOT>/core/modules/block/src/BlockAccessControlHandler.php:119 [dpm()]
<ROOT>/core/lib/Drupal/Core/Entity/EntityAccessControlHandler.php:105 [Drupal\block\BlockAccessControlHandler->checkAccess()]
<ROOT>/core/lib/Drupal/Core/Entity/EntityBase.php:314 [Drupal\Core\Entity\EntityAccessControlHandler->access()]
<ROOT>/core/modules/block/src/BlockRepository.php:63 [Drupal\Core\Entity\EntityBase->access()]
<ROOT>/core/modules/block/src/Plugin/DisplayVariant/BlockPageVariant.php:137 [Drupal\block\BlockRepository->getVisibleBlocksPerRegion()]
<ROOT>/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php:274 [Drupal\block\Plugin\DisplayVariant\BlockPageVariant->build()]
<ROOT>/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php:132 [Drupal\Core\Render\MainContent\HtmlRenderer->prepare()]
<ROOT>/core/lib/Drupal/Core/EventSubscriber/MainContentViewSubscriber.php:90 [Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse()]
<ROOT>/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php:142 [call_user_func()]
.../symfony/http-kernel/HttpKernel.php:163 [Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch()]
.../symfony/http-kernel/HttpKernel.php:80 [Symfony\Component\HttpKernel\HttpKernel->handleRaw()]
<ROOT>/core/lib/Drupal/Core/StackMiddleware/Session.php:58 [Symfony\Component\HttpKernel\HttpKernel->handle()]
<ROOT>/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php:48 [Drupal\Core\StackMiddleware\Session->handle()]
<ROOT>/core/modules/page_cache/src/StackMiddleware/PageCache.php:106 [Drupal\Core\StackMiddleware\KernelPreHandle->handle()]
<ROOT>/core/modules/page_cache/src/StackMiddleware/PageCache.php:85 [Drupal\page_cache\StackMiddleware\PageCache->pass()]
<ROOT>/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php:48 [Drupal\page_cache\StackMiddleware\PageCache->handle()]
<ROOT>/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php:51 [Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle()]
.../stack/builder/src/Stack/StackedHttpKernel.php:23 [Drupal\Core\StackMiddleware\NegotiationMiddleware->handle()]
<ROOT>/core/lib/Drupal/Core/DrupalKernel.php:708 [Stack\StackedHttpKernel->handle()]
<ROOT>/index.php:19 [Drupal\Core\DrupalKernel->handle()]

the reason at line 118 @ web/core/modules/block/src/BlockAccessControlHandler.php code

$block_plugin = $entity->getPlugin();

return null. And as I see Drupal\Core\Block\BlockManager::definitions equal null at this moment (nesting $entity Drupal\block\Entity\Block :: $pluginCollection Drupal\block\BlockPluginCollection :: $manager Drupal\Core\Block\BlockManager :: $definitions NULL)
How cat it happen that $definitions are empty?
I do not see any difference between working $entity and broken with empty definitions, service is not overridden, theme Gin and block name is gin_secondary_local_tasks (but I think particular block does not matter as $definitions must be populated with all blocks definitions as I see from working case)

Steps to reproduce

Enable Layout Builder on Gin theme.

Proposed resolution

unknown

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

When maintenance mode is active, the site maintenance message is renderen in a particular theme. That theme can be set explicitly in setings.php otherwise the default theme is used. If something goes wrong, however, when determining the default theme, for example because the database goes away during an update, we need some fallback theme to display the maintenance message.

This (last-resort) fallback theme is currently Bartik. As part of the effort to make Olivero the default Drupal theme and eventually deprecate Batrik we should also change this fallback theme to Olivero instead.

Steps to reproduce

Change the default theme to something other than Bartik.
Activate maintenance mode and somehow trigger an exception during the fetching of the default theme.
You will see the maintenance message rendered in Bartik.

Proposed resolution

Change the fallback to Olivero.

Remaining tasks

User interface changes

The fallback site maintenance message is rendered in Olivero.

API changes

-

Data model changes

-

Release notes snippet

Split off from #3219958: [META] Make Olivero the default theme for Drupal 10.

Note that we hope to have this completed in Drupal 9.4. There will be work on this as discover which tests are dependent on Bartik.