Problem/Motivation

Drupal core ships with cache tags support - awesome.
To ensire that tags for an item were not invalidated on cache read a CacheTagsChecksumInterface service is used (eventuially) and D8 core provides such a service as a DB variant.

My issue is with the cache tags sub-system internals. As it is implemented, the list of cache tags on the platform will grow endlessly due to the DatabaseCacheTagsChecksum implementation.

In the following scenario with a highly-volatile custom entities - add 100k instances, delete them, add new 100k back.

The system will end up with a 200k cache tags in the table, 100k of them will not be used again ever. They will just stay there and clutter the database and cause overall slow-downs. Imagine when this process continues for a while...

Even after a full cache clear (that happens only rarely) all tags are still kept there.

In my case the cache tags is the highest throughput and biggest time consumer as a DB query in the whole of system, even though it's fast on average. I have around 40-50k valid entities in the system and around 120-130k cache tags in the table.

I think this problem affects only the DB implementation, as Memcache and Redis (if they have implementations on the interface) will scale in O(1) compared to Log(N) based on the amount of data in the system. On top of that they have a robust garbage collection mechanisms in case of memory pressure. SQL databases have none of that.

Proposed resolution

Can we have the list of cache tags on the portal truncated when the whole cache get's cleared.
As I suspect this should not be a problem, as the whole set of cache was just invalidated either way.
I think cache tags should be deleted whenever content is deleted on the system.

We should also consider deleting cache tag entries whenever the related entity is deleted as well (if possible). For example: delete of node with ID 1 will delete the node:1 tag from cachetags as well. Cache check-sums that depend on it will be invalidated based on the checksum, as the counter will not be valid (0) instead of anything that was present before.

Any other ideas are welcome.

Remaining tasks

Discussion, decision, patch...

User interface changes

None.

API changes

TBD. None expected.

Data model changes

TBD. None expected.

Release notes snippet

TBD.

Problem/Motivation

In #3038901: Speed up the tests on DrupalCI by not running slow tests last we formalized adding @group #slow to tests which take a long time to run. This way we can prioritize them to run early.

This MR adds @group #slow to several more tests, based on a 30 second time limit via #3040694: Add an automated way for slow tests to fail drupalci builds.

It also adapts run-tests.sh to distribute the slow tests between test runners when gitlab parallelism is used - this means if there's 6 test runners and 72 slow tests, each runner gets 12 slow tests each and they'll all be started first.

This doesn't attempt to balance test run speed in general, just that we don't want a 30s+ test to run at the end of a job run because it could artificially add 30 seconds to the entire run.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Running the d7_block migration without block_content installed results in an exception: Drupal\Component\Plugin\Exception\PluginNotFoundException: The "block_content" entity type does not exist.

Steps to reproduce

1. Create a new file at core/modules/block/tests/src/Kernel/IssueTest.php with the following code:
   

   
   namespace Drupal\Tests\block\Kernel;
   
   use Drupal\Tests\migrate_drupal\Kernel\d7\MigrateDrupal7TestBase;
   
   /**
    * @group block
    */
   class IssueTest extends MigrateDrupal7TestBase {
   
     /**
      * {@inheritdoc}
      */
     protected static $modules = ['block'];
   
     /**
      * {@inheritdoc}
      */
     protected function setUp(): void {
       parent::setUp();
       $this->executeMigration('d7_block');
     }
   
     /**
      * Test.
      */
     public function testIssue() {
     }
   
   }
   

2. Run this test class.
3. Observe the aforementioned exception is present.

Proposed resolution

Correct the ternary in Drupal\block\Plugin\migrate\process\BlockPluginId that checks for the presence of the block_content entity type.
The original commit was #2250429: d6_block migration not migrating all blocks

Remaining tasks

Commit

User interface changes

None.

API changes

Argument 4 of Drupal\block\Plugin\migrate\process\BlockPluginId::_construct can be null

Data model changes

None.

Release notes snippet

None.

I noticed the "user ID from URL " option gone in views contextual filter, I need to display a view with useraccount fields on user account page which can be seen by all other users, please advise how can I make this without the option "user ID from URL " thnks

Problem/Motivation

This issue was detected when testing partial split feature. It looks like the layout builder sections on the config_split are not being serialized at this point, so they are placed in the diff as an object. if that diff is used by the config storage, it throws an exception because the validation fails:

web/core/lib/Drupal/Core/Config/StorableConfigBase.php:207

// Throw exception on any non-scalar or non-array value.
if (!is_array($value)) {
  throw new UnsupportedDataTypeConfigException("Invalid data type for config element {$this->getName()}:$key");
}

Steps to reproduce

Proposed resolution

a) Serialize the section object before placing it into the diff
b) Implement an interface into the Section object and then try to serialize any object with that interface

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

• run-tests.sh is hard to maintain code
• Its a wrapper around phpunit, which caused many bugs in the past

Proposed resolution

Try to run https://github.com/brianium/paratest with kernel tests and browser tests. It could be also worth trying to find out whether running unit tests in parallel would be worth for itself.

Note: This is an exploration issue.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

From a users perspective who has installed Drupal with the standard profile: At the moment user will still see the admin content and comment tab under admin/content even if the regarding Views view has been intentionally removed. This is caused by the fact that the Views views overrides core's own entity listings. That feels inconsistent and confusing to the user regarding the expected behavior of Views admin tabs underadmin/content when the user do not know about the default entity listings provided by core.

And since the user obviously wants to remove it from the admin/content path it will become obvious that there is no chance to do so. Which is confusing because of the Views admin views indicating a certain flexibility on this. In the moment the only work around would be to disable it instead of removing, so that the path keeps being overridden by Views. I consider this a confusing behavior and a possible task or core idea to change that behavior in the manner of a user experience like:If the content or comment Views view has been removed intentionally it shouldn't be there.

I see the points of having a default content/comments and other entitiy listings at hand in core in case of the View has been removed accidentally or Views has been uninstalled completely. But it should have the option to be disabled (idea).

Steps to reproduce

Install Drupal with standard profile and remove admin/content and admin/comment Views from structure/views. The user expects the Views view to be gone under content/admin but sees new lists now instead. Which he doesn't know are provide by core.

Proposed resolution

Provide an admin setting to disable default entity listings in core with an obvious button/link on top of the listing page linking to a new configuration setting under admin/config content authoring tab. This way we keep the fallback intact and it makes it more obvious to the user that this list is provided by core in case the Views view isn't there. And it extends the flexibility to completely disable these pages if wanted. Which needs an active action of the user to disable that.

Remaining tasks

Add a description to the existing content and comment admin Views that these Views override the core entity listings.

User interface changes

In case of core's entity listings present a link on top right needs to be added linking to admin/config and to a new content authoring tab named "Entity listing settings".

API changes

If required please add them here. Not that I am aware of yet.

Data model changes

If required please add them here. Not that I am aware of yet.

API page: https://api.drupal.org/api/drupal/core!modules!views!src!Plugin!views!st...

What are the steps required to reproduce the bug?

1. Visit https://api.drupal.org/api/drupal/core!modules!views!src!Plugin!views!st....
2. Click on View source under core/modules/views/src/Plugin/views/style/StylePluginBase.php.

What behavior were you expecting?

I was expecting to see the source code for core/modules/views/src/Plugin/views/style/StylePluginBase.php.

What happened instead?

Nothing happened.

If I expand Same filename and directory in other branches and choose either 8.9.x or 9, I can click on View source under core/modules/views/src/Plugin/views/style/StylePluginBase.php to see the source code.

Apologies if this has been mentioned before, but a search for api.drupal.org in the issue queue returned no results.

If you aren't xjm, please leave this issue alone. Thanks!

Problem/Motivation

The administer nodes permission is pretty much useless and the "real" administration permission is bypass node access. This is pretty confusing.

The logic in \Drupal\node\NodeAccessControlHandler::checkAccess checks the administer nodes permission here:

    // Revision operations.
    if ($revision_permission_operation) {
....
      elseif ($account->hasPermission('administer nodes')) {
        return AccessResult::allowed()->cachePerPermissions();
      }

It also does not invoke the parent method, which has:

    if ($operation == 'delete'&& $entity->isNew()) {
      return AccessResult::forbidden()->addCacheableDependency($entity);
    }
    if ($admin_permission = $this->entityType->getAdminPermission()) {
      return AccessResult::allowedIfHasPermission($account, $admin_permission);
    }

That means all logic is delegated to hook_entity_access and node_node_access performs per-bundle access checks.

Steps to reproduce

Assign administer nodes to a role and try to actually manage content.

Proposed resolution

Add admin_permission annotation to Nodes with administer nodes. Have \Drupal\node\NodeAccessControlHandler::checkAccess call its parent so that the admin permission is respected.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

If a user has permission to administer an entity type that is under content moderation, they may not be able to edit an entity. This is because \Drupal\content_moderation\StateTransitionValidation::getValidTransitions checks for transition access. If a user has permission to administer an entity, they should automatically be able to use any transition.

Steps to reproduce

Grant administer nodes and bypass node access to a role. Add content moderation to a content type. Try to edit the role without any content moderation permissions. Get access denied.

Proposed resolution

\Drupal\content_moderation\StateTransitionValidation::getValidTransitions should check if the entity type has an admin permission. If it does and the user has the permission, return all transitions.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

When Uploading Multiple Images from Media and it is only creating one media but all the files are uploading under the files

Steps to reproduce

1. Install the latest version of drupal
2. Go to Image media type and change the field settings to Unlimited
"/admin/structure/media/manage/image/fields/media.image.field_media_image/storage" change the Allowed number of values to
Unlimited and Save it.
3. Now go to Media "/media/add/image" and now you can have option to upload multiple Images and Please upload more than 1 Image and save it
4. Now go to Media and see only one media is added but files are uploaded all the Image files under "/admin/content/files"

Proposed resolution

When Upload multiple images it should create multiple media

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

While working on https://github.com/jsdrupal/nightwatch we realized we could autostart chrome/chromdriver, with default settings, so people don't have to really setup stuff to run these tests.

Proposed resolution

Use a similar concept for the PHP based tests, too.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

The class web/core/lib/Drupal/Core/Database/Connection.php at method setPrefix($prefix) at first validate if the $prefix is a string. However at time to show the issue message, assumes that is a string

protected function setPrefix($prefix) {
    assert(is_string($prefix), 'The \'$prefix\' argument to ' . __METHOD__ . '() must be a string');
    $this->prefix = $prefix;
    $this->tablePlaceholderReplacements = [
      $this->identifierQuotes[0] . str_replace('.', $this->identifierQuotes[1] . '.' . $this->identifierQuotes[0], $prefix),
      $this->identifierQuotes[1],
    ];
  }

Steps to reproduce

I got this issue at time to deploy a project:

AssertionError: The '$prefix' argument to Drupal\Core\Database\Connection:: \n setPrefix() must be a string in assert() (line 375 of /space/www/pp.garanti \n edesdepots.fr/releases/20230915130755Z/web/core/lib/Drupal/Core/Database/Co \n nnection.php). \n \n

Proposed resolution

Show the issue message as string.

I have recently switched form using Seven admin theme to Claro as I prepare to update to Drupal 10.

One thing I have noticed, is that when logged in on the front end the icon sizes do not scale well with my custom theme.

I am using rem's and scaling my content using media queries, so that type looks bigger on a larger screen.

Having a quick look I am able to fix this issue by simply swapping out references to rem with ems for the icon sizes including width and height

This is evident when using viewing the front end base theme that uses media queries to change the rem base font setting and using the admin toolbar. See attached screenshots.

Problem/Motivation

In #3129043: Move core database drivers to modules of their own, we moved Drupal core's database drivers to modules, leaving though some BC shims to still support old ways to access drivers' code.

Proposed resolution

Deprecate such BC paths for removal in next major.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Let developers to run test suite in cloud CI services easier with their high performance CI services or public free resources.

Pros:
- No more `Lack of set-up CI env in local`
It's quite often I heard developer told they can't set up the CI in local properly. And the CORE's test bot instruction is targeting to Linux user mainly.

- Reduce testbot fails noise.
Sometimes, I received 10 or more testbot fails messages from a single thread. Oftenly, it's useless to most developers in the thread.

- Let the public services to test our NODEJS script (ES6), webdriver..etc
To ensure our scripts able to run on the different platforms. For example, we should test our ES6 build script in NODE 8 ~ 9 branches. And ensure it works well under cross-platform (Windows / MacOS / Linux)

** [Higher Priority] Make the CI easy to run single test rather than full test suite.

Problem/Motivation

In #3117698: Allow PostCSS Plugin “Px to Rem” in core for Olivero theme there was a good discussion about how and where to use REM units. See #3117698-24: Allow PostCSS Plugin “Px to Rem” in core for Olivero theme.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

instaclick/php-webdriver does not really support the W3C webdriver standard which makes it hard to use webdrivers other chromedriver. We should be able to run Drupal's Javascript tests against geckodriver but we can't. Also instaclick/php-webdriver and behat/mink-selenium2-driver are not receiving the same level of support as the alternatives.

For discussions of whether mink-selenium2-driver can support the W3C standard see / how https://github.com/minkphp/MinkSelenium2Driver/issues/293

We are still waiting on a release of behat/mink-selenium2-driver that supports PHP 8.1.

Proposed resolution

• Change our code to use php-webdriver/webdriver& oleg-andreyev/mink-phpwebdriver
• Deprecate \Drupal\FunctionalJavascriptTests\DrupalSelenium2Driver or fix it to extend from oleg-andreyev/mink-phpwebdriver

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

When a module has Views plugins, e.g. a display extender, its presence in the system is listed in the views.settings config objects in the "display_extenders" element. When

Steps to reproduce

Install Metatag Views, which is part of Metatag. Alternatively, install the views_test_data test module.
Enable the new display extender.
Export the configuration to an install profile.
Install a new site using the install profile.

What should happen:
The site installs properly and the display extender is enabled as expected.

What actually happens:
An error will be shown and the installation will fail with an error like the following:

Uncaught PHP Exception Drupal\Component\Plugin\Exception\PluginException: "Plugin (metatag_display_extender) instance class "Drupal\metatag_views\Plugin\views\display_extender\MetatagDisplayExtender" does not exist." at core/lib/Drupal/Component/Plugin/Factory/DefaultFactory.php line 97

Proposed resolution

Remove Views' ability to enable or disable display extender plugins, so that they're always available.

Remaining tasks

Work out the best approach to fix this.

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Release notes snippet

TBD