This issue is intended as a tracking issue only to list all of the known intermittent test failures affecting Drupal core. Some issues are due to bugs in Drupal core; others may be due to issues with DrupalCI infrastructure.

Only open issues should be listed in the summary.

Consistent failures

• #2921123: Adjust Rectangle class to calculate rotated image dimensions according to libgd 2.2.2+

Intermittent failures

1. #3361121: [random test failure] InstallerExistingConfig[SyncDirectory]MultilingualTest::testConfigSync
2. #2825845: DST-related test failures in FilterDateTimeTest
3. #2920590: (canard?) Big Bos of Random Fails is ChainedFastBackend::markAsOutdated()
4. #3041318: Various random fails due to mis-triggered Mink deprecation error
5. #3143812: Random test failure Table 'sequences' already exists.
6. #3191559: [random test failure] Random test fail in EntityReferenceWidgetTest
7. #3210432: [random test failure] LayoutBuilderQuickEditTest::testQuickEditIgnoresDuplicateFields()
8. #3203712: [random test failure] EntityDisplayTest::testExtraFields()
9. #3207125: [random test failure] SettingsTrayBlockFormTest:: testEditModeEnableDisable()

Low fail rate or may be resolved

• #3057767: [random test failure] DialogTest::testDialog() (one failure in Jan. 2022, no others recently)

Investigation and hardening for past random failures

• #2936432: Review use of pressButton() in functional javascript tests in the Media module
• #2946294: Fix race conditions in OffCanvasTestBase
• #2856047: Avoid random failures in JavascriptTestBase when testing functionality in a dialog
• #3055983: Discover why there are occasional locks on SQLite in InlineBlockPrivateFilesTest::testPrivateFiles
• #3055982: Remove resizing window in BlockFormMessagesTest::testValidationMessage
• #3056848: Investigate LayoutBuilderDisableInteractionsTest random fails further
• #2571183: Deprecate random() usage in tests to avoid random test failures
• #3165263: Allow known flaky tests to be automatically repeated

If your patch has an unexpected test failure

1. Always click on the test results link to see what tests actually failed.
2. Check the test results on https://www.drupal.org/node/3060/qa. If the same test appears to be failing on the "tested on commit" environments, HEAD may be broken.
3. Most test failures are actually caused by bugs in patches. Even if a failure appears to be random, consider that the patch may be introducing the bug.
4. If the test result says "CI error" or "CI aborted", that generally indicates an issue with the infrastructure and not with the patch. Wait a bit, then requeue the tests for the patch.
5. If the test says "Fatal error" with no other information, click "View results on dispatcher", then "Console Output", then "Full log", and search on the page for "segmentation fault". #2859704: Intermittent segfaults on DrupalCI (some "did not complete due to a fatal error" with no additional info) is a known issue that may cause the test runner to report a fatal in different tests.
6. If the test failure appears to be one of the above known failures, there is no need to add additional reports of it (unless the issue specifically requests so). Usually, once a fail is identified, Drupal.org maintainers can locate other, similar fails in server logs if needed. However, you should document on your issue which specific known issue caused the failure.
7. If there is an unexpected test failure that is not covered by one of the above issues, file a new critical issue and add it to this issue's summary.

Problem/Motivation

We currently allow entities to specify an "admin permission". Entity types such as Node and others provide a separate "overview" permission that is useful for granting people access the entity view, even if they do not have the admin permission. For example you may want to allow some people to edit entities, but not delete them or people may have access to edit and delete some entities but not others. In such cases it's necessary to access the entity overview but not have the admin permission.

Proposed resolution

- Allow entities to provide a "collection permission" in addition to the admin permission. ("collection" is chosen as a term instead of "overview" to comply with the collection link template and route.) Just like the admin permission the actual name of the permission (i.e. "access $foo overview") is determined by an annotation key.
- Update the generated collection route to allow access to either the admin permission or the collection permission.

Problem/Motivation

The people at the county fair,
Were shocked asethey heard a loud blare:

A bear, a bear!
it's right over there, it's right over there!
I swear, I swear!
It shouldn't be there, It _shouldn't_ be there!

And one said with some flair:
And why exactly, should we care?

Because it causes a random ExpectationFailedException, you fake Dr. Suess!

1) Drupal\Tests\media_library\FunctionalJavascript\EntityReferenceWidgetTest::testWidget
"Bear" was found but shouldn't be there.
Failed asserting that a boolean is not empty.

/var/www/html/vendor/phpunit/phpunit/src/Framework/Constraint/Constraint.php:122
/var/www/html/vendor/phpunit/phpunit/src/Framework/Constraint/Constraint.php:55
/var/www/html/core/modules/media_library/tests/src/FunctionalJavascript/MediaLibraryTestBase.php:86
/var/www/html/core/modules/media_library/tests/src/FunctionalJavascript/EntityReferenceWidgetTest.php:212
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:728

And add to that,
the appearance of a cat!
Which is bad,
because the place it's at,
has no need for a cat.
O no, we don't want that!

Oh, shut up!

It seems that a similar random failure occurs (less frequently than the above one) later on in the test:

1) Drupal\Tests\media_library\FunctionalJavascript\EntityReferenceWidgetTest::testWidget
Behat\Mink\Exception\ResponseTextException: The text "Cat" appears in the text of this page, but it should not.

/var/www/html/vendor/behat/mink/src/WebAssert.php:811
/var/www/html/vendor/behat/mink/src/WebAssert.php:279
/var/www/html/core/modules/media_library/tests/src/FunctionalJavascript/EntityReferenceWidgetTest.php:417
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:728

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Drupal.views.ajaxView is not initializing pagers in nested views. The part here:

// Add the ajax to pagers.
this.$view
  // Don't attach to nested views. Doing so would attach multiple behaviors
  // to a given element.
  .filter($.proxy(this.filterNestedViews, this))
  .once('ajax-pager').each($.proxy(this.attachPagerAjax, this));

checks if view is inside another view. As a result pager links in embedded views are initialized in the context of parent. This makes it impossible to perform ajax operations in context of the child view (see this Views Infinite Scroll issue).

Proposed resolution

Initialize ajax views in order determined by their nesting level. The innermost view should go first and mark its elements with .once so they aren't processed again when parent view is initialized.

Remaining tasks

1. Write patch
2. Review
3. Write tests

User interface changes

None

API changes

None

Data model changes

None

Problem/Motivation

We have a very nice translation system in place that is based on translating fields on entities. For many cases this work very well, but in some cases we need to special care. One of these places are menu items. Right now, when you display menu items, fx with the menu block from core, all menu items are displayed regardless of it being translated or not. This is bad for a few reasons.

• Having a menu with mixed languages is often not desired for site builders / end users
• Different menu blocks can have different requierments (e.g. filter main menu by current language, but not the footer menu)
• It's not possible to hide menu items on certain languages (where they might not be relevant)

Steps to reproduce:

1. Install Drupal with several language and enable menu translation
2. Display the main menu with the core menu block
3. Create some pages with links in the main menu
4. Visit a page with the menu with a UI missing translations for menu items

Actual result:

All the menu items are displayed in the menu, untranslated in the original (or another) language.

Expected result:

Only the translated menu items are displayed in the menu.

Proposed resolution

Display menu items for the current language, or those without a specific language (not specified, not applicable).

Remaining tasks

Decide how handle different types of menu items (from code. *.links.menu.yml, from views, from menu link entity). This could potentially be a follow-up issue.

User interface changes

TBD.

API changes

None.

Data model changes

None.

Available work-arounds

• Content Language Access
• Menu Manipulator
• Menu Multilingual
• Menu block current language

This is postponed on:

a) #2920309: Add experimental module for Help Topics being committed

b) #3027054: Help Topics module roadmap: the path to beta and stable having all the other tasks being done.

So the task for this module is to finally merge the Help Topics module into the core Help module for stable release. Sub-tasks:

• Merging the hook_help() from the experimental Help Topics module into existing topics
• Making sure that no help topics mention the Help Topics module (because it will be part of the Help module instead).
• Adding to the drupal.org docs page for the existing Help module
• #3087499: Merge Help Topics classes into Help with BC layer
• Changing function names of hook implementations, deprecate help_topics' classes
• The standard things done in Core to finalize a module, such as adding templates to the Stable/Classy themes, updating the module category in the .info.yml file, removing @internal tags, adding @api tags, etc., (Is there a standard procedure for this?)
• #3025577: Move help topics to core or the correct modules
• #3074040: Move testing of help topic rendering into InstallUninstallTest
• #3358340: Update help.help_topic_search to remove mention of Help Topics module
• #3144933: Merge help topics admin theme test into base class
• #3370070: Update Maintainers for the Help module
• ...issue to remove help topics in D11 ... [TBD]
• #3031642: Deprecate hook_help() and combine with Topics -- the part about "Deprecate and remove hook_help()"

Problem/Motivation

#2521800: List key|label entry field is textarea, which doesn't give guidance towards the expected input changed the options field types to use similar pattern that is used for fields allowing unlimited field cardinality. This is nice because the new UI makes it clear what the user needs to enter, as well as automates generating the machine names when possible. However, what could be improved is that adding multiple values to the field requires more steps now than it did before.

Proposed resolution

Allow adding a new value to a list of fields by pressing enter on the last item. When pressing enter on a value that is not the last item, navigate to next item instead of adding a new item.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Follow-up to #3368789-9: Improve \Drupal\Tests\TestFileCreationTrait::generateFile() for PHP 8.3

The function is used only 3 times in core few times in contrib http://codcontrib.hank.vps-private.net/search?text=generateFile%28&filen...

Implementation using very slow algo to generate files so is the cause of slow test

Proposed resolution

- deprecate the method and suggest to use new PHP random extension instead

Remaining tasks

- agree
- patch
- review/commit

User interface changes

no

API changes

\Drupal\Tests\TestFileCreationTrait::generateFile() is deprecated

Data model changes

no

Release notes snippet

MigrationLookup::transform() calls a helper method, skipOnEmpty(), and that throws a MigrateSkipProcessException if the source value for the lookup is empty.

But that means that a process pipeline can't specify a default value if a source row .

eg:

process:
  uid:
    -
      plugin: migration_lookup
      migration: users
      source: author
    - 
      # we never get here is 'author' is empty
      plugin: default_value
      default_value: 1

In particular, this means that a stub row created for an outer migration's lookup will always skip processing here, because the stub row creation won't provide a source value for the inner lookup.

Problem/Motivation

In the Olivero theme, color for the chevron icon is not as per the Figma design for all the screen sizes.
Before the patch



After the patch

Steps to reproduce

Make sure you have selected the Olivero theme and open it using Chrome or a similar browser inspect the chevron icon color and compare it to the Olivero theme Figma design

Proposed resolution

Replace the color with the one that is mentioned in the Figma design.

Remaining tasks

None

User interface changes

Changing the color from var(--color--gray-45) to var(--color--gray-90) as mentioned in the Figma design.

API changes

None

Data model changes

None

Release notes snippet

None

Problem/Motivation

TermStorage::loadChildren returns not sorted children for term.
Actually it comes from TermStorage::getChildren which actually runs the EntityQuery for getting the children for the given parent.

Steps to reproduce

Build a custom Taxonomy with custom weights for its children.
Then try to to get the children for a parent - programatically.

For UI/UX:
From code ... there are no usage in core - only in tests ... but they do not check the sorting.

I noticed some usage in contrib Facets - Taxonomy hierarchy

Proposed resolution

- Fix TermStorage::getChildren but adding sorts by weight and name for the EntityQuery there.
- Test the sorting for getting the children

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

None

Original summary repoty

When I upgrade Drupal core from 8.4.6 to 8.6.16 I faced an issue in TermStorage::loadChildren.

I was using this function
:\Drupal::entityTypeManager()->getStorage('taxonomy_term')->loadChildren($parent_term->id());
for manging the website navigation by parent client relation . But after the upgrade the order was not by weight .

Adding the API page, someone else also faced the issue: https://api.drupal.org/api/drupal/core%21modules%21taxonomy%21src%21Term...

Adding a patch to fix this by adding :" ->sort('weight', 'ASC'); to the getChildren function.

Problem/Motivation

Currently there is no way to dynamically set up a custom url for more link in views display.

I use node_keep_token module to create a custom token for the page e.g. [node-keep:news_overview:url].

In my views, I would like to display an overview of latest content and more link in the bottom that leads to the full overview page.

Would be nice to use the token in the custom url, so the path is dynamic and I do not need to worry about multilingual differences or path updates.

Steps to reproduce

Add a block views, enable more link, add token to custom url under link display settings.

Proposed resolution

Replace tokens before url parse in \Drupal\views\Plugin\views\display\DisplayPluginBase::getMoreUrl()

Remaining tasks

- Upload a patch
- Write some tests

Problem/Motivation

When trying to refactor ModuleHandler in #3368812: Hux-style hooks, proof of concept, I noticed that some bugs or changes of behavior introduced into the ModuleHandler did not cause ModuleHandlerTest to fail, while other tests did fail.

This means that Drupal\Tests\Core\Extension\ModuleHandlerTest is incomplete in its coverage of Drupal\Core\ExtensionModuleHandler.

I also noticed a heavy reliance on mocking protected methods. It would be nice to avoid or reduce that.

Steps to reproduce

Look at failed runs in the other issue #3368812.

Proposed resolution

Add more cases in ModuleHandlerTest.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

The kittens you are looking for cannot be found from here.

Problem/Motivation

While reviewing #2949991: Add workspace UI in top dialog I found a bug with the toolbar and the off-canvas dialog.

The current patch updates the off_canvas_top to be able to demonstrate the problem without the workspaces module involved.

1. Login with a user who has access to the toolbar
2. Goto /off-canvas-test-links
3. Click Open top panel 1
4. When the top dialog opens notice the toolbar is at the bottom of the top dialog
5. Click "Open modal!" on the main page
6. Notice that now the toolbar is at the top of the top dialog.
7. Close the dialog
8. Notice that now the toolbar remains at the top of the top dialog.

This behavior happens whether the dialog link is the off-canvas dialog or on the main page.

Proposed resolution

Not sure

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

• Create an Article node. For the Body field, choose the "Full HTML" format, click the "Source" button in the CKEditor toolbar, and enter the following HTML:
  

  <iframe src="http://example.com/"></iframe>
  <!--break-->
  stuff below the fold
  

• Save that article. Notice that the iframe and the "stuff below the fold" is displayed, because the article is being shown in the "Full" view mode.
• Go to the home page. Notice that nothing is shown for the article's teaser, not even the iframe.
• This is because for the teaser, text_summary() is called and passed a FilteredMarkup object, marking the string as safe for rendering, because it's already been processed by a text format (in this case, by "Full HTML" which allows iframes). However, text_summary() then extracts the part before <!--break-->, and returns it as a plain string. Because it's a plain string, not a MarkupInterface object, when it gets rendered it gets passed to Xss::filterAdmin(), which strips out the iframe.
• We're running into this problem in #2940029-89: Add an input filter to display embedded Media entities, where the iframe is a rendered YouTube video. In other words, this bug prevents the "Media Embed" filter from working as expected when embedded videos should otherwise be displayed in a content teaser.

Proposed resolution

Fix text_summary() to return a MarkupInterface object when a MarkupInterface object is passed in.

Remaining tasks

This issue is tagged with "Needs security review", because we should make sure that the proposed resolution is in fact a safe thing to do. In other words, if an HTML string has been determined to be safe to render, is it valid to assume that a fragment of it is also safe to render?

User interface changes

API changes

Data model changes

Release notes snippet

Read many usability tests for Drupal Core. I notice no one to do a test for drupal with less permissions configs.

e.g. #1038330: Allow specific vocabulary permissions to work on vocabulary admin pages

Hi

As you know page numbers is like 1 2 3 4 ...
And when 10 nodes added and if the page limit is 10 then the page numbers stay as they are and the nodes move from one page to the other.

to avoid this i tried to create the page numbers like : 45 44 43 42 .... instead of 1 2 3 4 .... if we have 45 pages. This way when new nodes are added the ones on the last page will have still the same page number. Of course i am talking about a view with tons of nodes and where the nodes are ordered by descending creation time.

There are mainly 2 reasons why i try to reverse the page numbers:

1- users memorise the page numbers, and after some time when they come back, all the nodes are moved to other pages since lots of nodes are added.

2- google bot and other bots memorises the page numbers, and when it comes back it sees that all pages with the same url have different pages, and thinks that it should reindex reindex reindex.... keep indexing. and when displaying result to its' users bots always point to a wrong page. And this i believe drops the page rank of the site.

I wonder if anyone can help me to reverse the page numbers.

thank you
arda

There are some cases where we're sharing the same form IDs across multiple forms in core. For example, any entity form, like node/1/edit and node/2/edit (assuming both nodes are the same type), the $form['#token'] for both is 'article_node_form'. We should probably make this form token use 'node_[node:nid]_form' instead.