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.

Drupal 8

Consistent failures

• #2918570: Drupal\KernelTests\Core\Image\ToolkitGdTest fails on PHP 7.1.x-dev and 7.0.x-dev following a PHP bugfix

Intermittent failures

1. #2806697: Random fail for AlreadyInstalledException
2. #2828143: Stop tests like LocaleConfigTranslationImportTest from failing if l.d.o becomes unavailable
3. #2796757: Failing test with stable version string
4. #2825845: DST-related test failures in FilterDateTimeTest
5. #2843024: Random fail in LanguageUILanguageNegotiationTest
6. #2906317: Random fail due to problems with database
7. #2926309: Random fail due to APCu not being able to allocate memory
8. #2924753: Random fail in ExposedFormUITest
9. #2920590: (canard?) Big Bos of Random Fails is ChainedFastBackend::markAsOutdated()
10. #2934997: Intermittent failure in MediaUiJavascriptTest
11. #2936427: Intermittent failure in MediaSourceImageTest
12. #2975644: Random Failure in Drupal\Tests\Core\Command\QuickStartTest

Investigation and hardening for past random failures

• #2853905: Figure out why there were segfaults in every test run on PHP 7.1.x-dev
• #2842393: Discover why gc_disable() improves update.php stability
• #2919863: Discover why gc_disable() during non-interactive install improves tests stability
• #2936432: Review use of pressButton() in functional javascript tests in the Media module

Drupal 7

• #2820962: Investigate random fail in d7 test
• #2762541: PHP 5.5 and 5.6 branch tests fail on Drupal 7 core, even though they pass when run on a patch

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

As a user I want to be able to install Drupal from a package of configuration that is maintained in git.

At DrupalCon New Orleans, a workflow was discussed that would allow a profile would contain the config sync directory and this full config export should be used at install time.

Proposed resolution

If a install profile contains a config/sync directory this will be used to install the site.

To create an install profile that works this way on an existing site you can use https://www.drupal.org/project/install_profile_generator

To be clear, this issue would only pertain to certain install profiles. Especially where you have built an install profile to install a single site. The separate use case of allowing a site to be installed from an existing configuration export which is not part of a profile is covered in #1613424: Allow a site to be installed from existing configuration.

Remaining tasks

Add config validation
Add more test coverage

User interface changes

None

API changes

No API changes per se, there are new steps possible in the installer.

Data model changes

None

We have trouble with alt text for Thumbnail formatter. It is very similar to Media entity bug, but we use module Media in core.

In core/modules/media/src/Plugin/Field/FieldFormatter/MediaThumbnailFormatter.php is code

$media_items = $this->getEntitiesToView($items, $langcode);

I was inspect in Xdebug variable $items and I found, that there are using Thumbnail as alt ($items->list[0]->properties['entity']->target->entity->values['thumbnail']['x-default'])

I don't know, where is source of $items. How can I fix it?

Problem / motivation

Drupal 7 has a contributed module Entity Translation which allows to have field level translations on fieldable entities. This capability has moved to core in Drupal 8.

The scope of this issue is

• Migrate the actual translated data of the fields.

The migration of entity translation settings is being done in #2073467: Migrate Drupal 7 Entity Translation data to Drupal 8.

Remaining tasks

• Write the patch
• Review
• Commit

Problem/Motivation

Workflows currently provides StateInterface and TransitionInterface for the State and Transition value objects. Content Moderation also uses StateInterface for ContentModerationState value object.

Do we need these interfaces?

Discussion started in #2899553: Architectural review of the Workflows module (documentation cleanups) at #29.

Proposed resolution

Discuss.

Remaining tasks

User interface changes

API changes

Possible removal of these two internal interfaces.

Data model changes

Problem/Motivation

On a site using the Workflows and Content Moderation modules, I created a table using Views, and enabled click-to-sort for the "Moderation state". When I click on the column header, I get a WSOD with the error message

The website encountered an unexpected error. Please try again later.

Drupal\Core\Entity\Sql\SqlContentEntityStorageException: Column information not available for the 'moderation_state' field. in Drupal\Core\Entity\Sql\DefaultTableMapping->getFieldColumnName() (line 215 of core/lib/Drupal/Core/Entity/Sql/DefaultTableMapping.php).

Drupal\views\Plugin\views\field\EntityField->clickSort('asc') (Line: 139)

The site I am using is Drupal 8.5.0. I have not yet tried to reproduce the problem on a plain Drupal install, but it seems like a bug in Drupal core.

Proposed resolution

TBD

Remaining tasks

User interface changes

None

API changes

TBD

Data model changes

TBD

We have not found it possible to use the MenuActiveTrail service to get the active trail since it breaks for certain view pages, including 2 of the built-in views. Not all of this is necessary to demonstrate the problem, but I wanted to prove this problem wasn't with the default Views configuration from any previous version of Drupal:
-- install Drupal 8 (last tested on 8.2.1) with Standard profile
-- drush en devel kint
-- add to bartik.theme & rebuild theme registry:

function bartik_preprocess_page(&$variables) {
  $route_match = \Drupal::routeMatch();
  $route_raw_parameters = $route_match->getRawParameters()->all();
  $getActiveTrailIds = \Drupal::service('menu.active_trail')->getActiveTrailIds("main");
  kint(
    "MenuActiveTrail::getActiveTrailIds(main)", $getActiveTrailIds,
    "raw parameters for MenuLinkManager::loadLinksByRoute()", $route_raw_parameters
  );
}

-- add a basic page Foo, provide a menu link on main menu:

• getActiveTrailIds shows one menu link (the current page menu link ID), before empty string that terminates the returned array: as expected.

-- create a view Bar (e.g. a Page of all Basic page summaries); set its Page settings to be a Normal menu entry on the Main menu.

• getActiveTrailIds also shows one menu link (the current page view ID): as expected.

-- enable the built-in Glossary view, which is pre-configured to be on the Main menu.

• getActiveTrailIds shows NO menu link IDs.

-- enable the built-in Archive view; set its Page settings to be a Normal menu entry on the Main menu.

• getActiveTrailIds shows NO menu link IDs.

Taxonomy pages, though they are also built-in views, also work normally, as does the Frontpage view. One difference between the working & not working views is that the user-defined, correctly working view (Bar) shows these raw parameters:

array(0)

and the non-working view (Archive, Glossary) show these raw parameters:

array(1)
    'arg_0' => NULL

If this behaviour is by design, or if a fix is pushed back to a future version, please we need the best practice to fix the above cases in modules (e.g. this issue for Menu Breadcrumb) that expect menu links in the active trail to always be returned from functions like MenuActiveTrail::getActiveTrailIds (and ::getActiveLink) and MenuLinkManager::loadLinksByRoute.

For instance we might filter out a NULL argument from the raw parameters before passing them to loadLinksByRoute(), but need to know first if that would break anything else.

Problem / motivation

Drupal 7 has a contributed module Entity Translation which allows to have field level translations on fieldable entities. This capability has moved to core in Drupal 8.

The scope of this issue is

• Migrate entity translation settings.

The migration of the actual translated data will be done in #2975666: Migrate Drupal 7 Entity Translation data to Drupal 8.

Remaining tasks

1. Write the patch
2. Review
3. Commit

Problem/Motivation

When writing a custom Views Display Extender plugin, you may need to validate it before submission of view edit form. Validation of plugins is performed in the validate() method of the DisplayPluginBase class. However, there is no validation of extender plugins in this method.

Proposed resolution

Add display extenders validation in DisplayPluginBase::validate().

Problem/Motivation

This was raised as a review point in #2784921-135: Add Workspaces experimental module:

+++ b/core/modules/workspace/src/Entity/Workspace.php
@@ -0,0 +1,223 @@
+      ->setDefaultValueCallback('Drupal\workspace\Entity\Workspace::getCurrentUserId')
...
+  /**
+   * Default value callback for 'uid' base field definition.
+   *
+   * @see ::baseFieldDefinitions()
+   *
+   * @return int[]
+   *   An array containing the ID of the current user.
+   */
+  public static function getCurrentUserId() {
+    return [\Drupal::currentUser()->id()];
+  }

Node and Media also have this, this is the 3th occurance of this exact code + docblock in core, should we open a followup to figure out if it makes sens to move this to a common class, or a trait?

Proposed resolution

Add a EntityOwnerTrait, similar to EntityPublishedTrait.

Remaining tasks

Do it.

User interface changes

Nope.

API changes

Nope.

Data model changes

Nope.

Problem/Motivation

https://tools.ietf.org/html/rfc7231#section-6.5.6 says

6.5.6.  406 Not Acceptable

   The 406 (Not Acceptable) status code indicates that the target
   resource does not have a current representation that would be
   acceptable to the user agent, according to the proactive negotiation
   header fields received in the request (Section 5.3), and the server
   is unwilling to supply a default representation.

   The server SHOULD generate a payload containing a list of available
   representation characteristics and corresponding resource identifiers
   from which the user or user agent can choose the one most
   appropriate.  A user agent MAY automatically select the most
   appropriate choice from that list.  However, this specification does
   not define any standard for such automatic selection, as described in
   Section 6.4.1.

… i.e. there's no standardized way to communicate the list of acceptable formats. Also see https://httpstatuses.com/300. See https://github.com/Respect/Rest/issues/39 for an example discussion of a project attempting to implement this … and getting sucked into an endless discussion. That being said, I think we should do something until it's standardized.

Proposed resolution

Update \Drupal\Core\Routing\RequestFormatRouteFilter

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

None.

Problem/Motivation

During the 2015 usability study, users struggled with the process of adding a new content type. After creating a content type, you are redirected to the Manage fields screen; however, the heading for this page does not contain the name of the content type you are managing fields for. It can only be found in the breadcrumb (and even that has issues, see #2513570: Changing name (label) of content type is not reflected in breadcrumb link text).

Consequently, some users thought they failed to create a content type because when they were redirected to the manage fields screen, they said "This page has nothing to do with what I just did."

This is a regression from D7, since that screen uses the content type in the heading.

Proposed resolution

Include the content type name (or entity type name) in the heading of the Manage fields page to orient the user and inform them what they are managing fields for:

Not just for noobies

This will also benefit experienced users because it will help prevent adding fields to the wrong content type.

User interface changes

Manage fields heading will have more text.

API changes

None.

Data model changes

None.

Beta phase evaluation

Problem/Motivation

ContentEntityBase::hasTranslationChanges is being called in core two times during the saving process.
1. ChangedItem::preSave
2. ContentEntityStorageBase::populateAffectedRevisionTranslations

In each of this cases the method will be called for each translation and having a lot of entity translations with complex fields one might want to somehow cache the output of the first execution of the method in order to serve the result on subsequent calls from this cache instead of having the complex logic running over and over again.

Additionally the core uses the method two times during the saving process but one might have hook_entity_update and running the method there as well in order to do stuff based on the output of the method, so caching the output of the method will be really useful and will have a real performance boost.

Proposed resolution

1. In ContentEntityBase::preSave flag the entity as being in a state of saving. - Should we set the flag at this point or it would be better to do in the storage after the field preSave method has been executed as after it the field values might have changed.. but actually the only place where the method might be correctly used is in the hook_entity_update which is running after field preSave which makes it unnecessary setting the flag from the storage.
2. In ContentEntityBase::hasTranslationChanges check if the flag from ::preSave is set and if so cache the output, otherwise if it is already cached serve it from the cache.
3. In ContentEntityBase::postSave reset the ::preSave flag and the cache of the ::hasTranslationChanges method.

With this change our system gained a real performance boost as we use the method also in hook_entity_update and during save we call it a lot of times on a lot of entities.
Numbers: 14 % less memory usage and 65 % faster saving.

Remaining tasks

Review & Commit.

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

Issue #88183: Relative URLs in feeds should be converted to absolute ones added a response subscriber (RssResponseRelativeUrlFilter) that converts relative URLs to absolute ones. It does this for any response that has the 'application/rss' Content-Type HTTP header.

However, that Content-Type HTTP header for feeds coming from views is set way down in template_preprocess_views_view_rss(), which means that information is not cached. Once such a feed (with its relative URLs) is in the render cache, that preprocess hook will not be called for subsequent requests, and so the default Content-Type header will be used, of 'text/html'. This is both wrong, and stops that RssResponseRelativeUrlFilter service from changing the URLs.

Steps to reproduce:

1) Build an RSS feed in views using the Feed display, or use an existing one (e.g. /rss.xml)
2) Ensure there is a 'real' render cache in place, not the null one often used for development.
3) View the feed
4) View the feed again to ensure you're getting the cached version this time.

The 'Content-Type' HTTP header will be 'text/html', but it should be 'application/xml'. Plus any relative URLs that would have been converted to be absolute when viewing the feed for the first time, before it was cached, will not have been converted.

Proposed resolution

The response object is deliberately passed down from the Feed display plugin through to the theme layer, to allow the HTTP header to be set. Cache it, so that the headers can then be used for subsequent requests.

Alternative possible resolutions are mentioned in comment 2.

Remaining tasks

Write tests - perhaps just extend those written for #88183: Relative URLs in feeds should be converted to absolute ones? Review the solution, and confirm it is the correct one.

User interface changes

Links will correctly be absolute, and the Content-Type HTTP header will correctly be application/rss.

API changes

None, as far as I can tell.

Data model changes

None, as far as I can tell.

DatabaseQueue::numberOfItems returns the result of a database query to count the number of rows in the the queue table.

The query returns a string. The method should cast to an int before returning.

(The method name numberOfItems suggests that an int will be returned.)

Hi,
I've added a field to the content type and configured it to be Inline, but it displays as block and without any styles.
I checked the code and was noticed what there is no any attributes: http://prntscr.com/jkztyx
I didn't override the template_preprocess_field() and field.html.twig file.
Can someone help me with this issue?
Thanks.

Split off of #2444003: Optimize Drupal\Core\Template\Attribute, this dealing with the Extension class. In addition to the tests, one method was found to be acting differently than documented - will try modifying it to behave as documented.

Problem/Motivation

Follow up to #2208429: Extension System, Part III: ExtensionList, ModuleExtensionList and ProfileExtensionList. A lot of the exceptions in the extension system use \IllegalArgumentException which is too generic. More specific exceptions are needed for specific conditions.

Proposed resolution

Add two new exception classes UnknownExtensionException and UninstalledExtensionException in the extension namespace and use as appropriate

Remaining tasks

Patch
Reviews
Commit

User interface changes

None

API changes

Two new Exceptions in the extension system

Data model changes

None

Problem/Motivation

In #2944113: Should Umami/OOTB support backwards compatibility and an offical upgrade path from one version to another? we discussed that it could be useful to have a reinstall button to make it easier to start over with the demo. This button would also signal that the demo is ephemeral and it should not be built on.

Proposed resolution

Explore adding a reinstall button. Design, technology, etc. Define whether this is a requirement for Umami for some milestone.

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

TBD

I just discovered that entity queries can handle relationships -- these docs in QueryInterface::condition() explain it:

   * @param $field
   *   Name of the field being queried. It must contain a field name, optionally
   *   followed by a column name. The column can be the reference property,
   *   usually "entity", for reference fields and that can be followed
   *   similarly by a field name and so on. Additionally, the target entity type
   *   can be specified by appending the ":target_entity_type_id" to "entity".
   *   Some examples:
   *   - nid
   *   - tags.value
   *   - tags
   *   - tags.entity.name
   *   - tags.entity:taxonomy_term.name
   *   - uid.entity.name
   *   - uid.entity:user.name

It would be really nice to be able to do reverse relationships as well.