Problem/Motivation

Our CSS standards have a recommendation about the order of property declarations so we should apply it to core (or change the standard).

Proposed resolution

Add https://www.npmjs.com/package/stylelint-order and use the existing CSScomb config to configure it and use the --fix option to generate a patch.

Blocked on #3024518: Upgrade stylelint to the latest version

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

None

Problem/Motivation

As decided in #2745619: [policy, no patch] Which core entities get revisions?, taxonomy terms should be converted to be revisionable and publishable.

Proposed resolution

Do it.

Remaining tasks

Decide how we want to deal with term hierarchies, see #2705389-48: Selected content entities should extend EditorialContentEntityBase or RevisionableContentEntityBase.

User interface changes

In the vocabulary overview page, the drag-and-drop interaction will be disabled if the vocabulary has at least one term with a pending revision:

API changes

Nope.

Data model changes

Taxonomy terms are now revisionable and publishable.

First discovered in the ClamAV module: #2864506: Long ajax process causing files to disappear.

A slow implementation of hook_file_validate() can cause inappropriate entries in the file_managed table, causing an in-use file to be treated as orphaned, and therefore deleted on a cron-run. This causes permanent loss of data.

More significantly, the upload appears to succeed and the data is available for a period of time, whilst the data-loss happens on cron, between 6 hours and 3 months after the data was uploaded. This can make the cause of the issue harder to recognise, and reduce the likelihood that the original file is still available for recovery.

Steps to reproduce:

1. Prepare a Drupal install with a content-type that contains a file field.
2. Enable a module which has a slow implementation of hook_file_validate() (example code provided below for test purposes)
3. Go to the node-add page for the relevant content-type
4. Click the "browse" button, and choose a file to upload
5. Click the form's "Save and publish" button quickly, before the AJAX upload + validate process has completed

The outcome is that two entries are added to the file_managed table, and one entry added to the file_usage table. Here is an example:

mysql> select * from file_managed;
+-----+--------------------------------------+----------+------+----------+----------------------------+------------+----------+--------+------------+------------+
| fid | uuid                                 | langcode | uid  | filename | uri                        | filemime   | filesize | status | created    | changed    |
+-----+--------------------------------------+----------+------+----------+----------------------------+------------+----------+--------+------------+------------+
|   1 | 3bcdd711-988e-4906-b8c6-0b22df271b93 | en       |    1 | foo.txt  | public://2017-04/foo_0.txt | text/plain |        9 |      0 | 1492187343 | 1492187343 |
|   2 | 0a7a9874-7e73-43da-8eeb-a7caa03ae63d | en       |    1 | foo.txt  | public://2017-04/foo_0.txt | text/plain |        9 |      1 | 1492187346 | 1492187346 |
+-----+--------------------------------------+----------+------+----------+----------------------------+------------+----------+--------+------------+------------+
2 rows in set (0.00 sec)


mysql> select * from file_usage;
+-----+--------+------+----+-------+
| fid | module | type | id | count |
+-----+--------+------+----+-------+
|   2 | file   | node | 1  |     1 |
+-----+--------+------+----+-------+
1 row in set (0.00 sec)

One entry is correctly recorded in the file_managed table, with a corresponding file_usage entry; the second is an orphaned file. However, both entries share the same uri. When the cron cleanup process deletes orphaned files, the valid, in-use file is deleted, causing permanent data loss.

The issue was originally reported in the context of the ClamAV module, however, I've been able to reproduce using nothing more than a sleep(10) command in a new debug module:

/**
 * Implements hook_file_validate().
 */
function mydebug_file_validate(Drupal\file\FileInterface $file) {
  $errors = array();

  // Add a delay of 10 seconds.
  sleep(10);

  return $errors;
}

This particularly affects the ClamAV module, where certain virus-scan configurations can add 10 seconds to the file-validate process, but this issue could affect any scenario where validation invokes a slow external process.

Problem/Motivation

Menu item is not removed after deleting feed types

Problem/Motivation

LanguageNegotiationBrowser correctly disables page cache in case an Accept-Language header is provided and it is asked for the language.

However, if there is no such header, then it doesn't, resulting in caching the response and the next request that does have such a header will receive the wrong response.

Proposed resolution

Always call trigger(). Extend test coverage to do multiple requests in a row, including some without a header.

\Drupal\Tests\language\Functional\LanguageUILanguageNegotiationTest is a very complex test that tests many different scenarios, but I think it would be preferable to have a dedicated test that just does this. Maybe a test method on that class, but it's pretty large already.

The test would have to set up language negotiation with url and secondary, browser negotation. Then do multiple requests, with language prefix and without, with accept-language header and without. Making sure that responses are cached/not cached as expected.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

#2368987: Move internal page caching to a module to avoid relying on config get on runtime moved the page caching to its own module and removed the caching setting instead (so caching is dependent on the module being enabled or not). Before that, the browser detection only worked if page caching was turned off. That setting was removed, so browser language negotiation now runs even with page caching enabled, but is not cached. It uses the kill switch instead:

\Drupal::service('page_cache_kill_switch')->trigger();

To make it cacheable, we need to overcome a few problems.

A. If browser language negotiation is before URL language negotiation, you may get different language negotiated for the same path. We should ensure browser negotiation is after URL negotiation.
B. Once we ensure that browser negotiation is after URL language detection, we need to ensure that browser negotiation redirects to the correct language specific URL.
C. You may use browser negotiation without URL language detection. We need to somehow ensure that you only use browser language negotiation if we can redirect to a concrete URL that is explicit for the negotiated language (contrib negotiation methods may be involved, session negotiation may be fed with an URL parameter to set this, etc).
D. Even if you use browser negotiation and URL negotiation, if one of the languages has an empty path prefix, it will fall through URL detection, so may still have different languages or is not redirectable to. Needs to be ensured that if browser language negotiation and URL negotiation is used, all languages have a prefix.

Proposed resolution

Problem B and C (implemented in #65)

Implement language redirect:
- Implement a new method onKernelRequestLanguageRedirect() on the LanguageRequestSubscriber.
- This method is called after current language is detected and routes are initialized.
- The method first ensures that redirect is allowed: request method is GET, there is no "destination" parameter in the current request, etc.
- The method constructs URL to the current route. The URL is processed with URL outbound processors, so it may contain language path prefix or other language identifier.
- The method compares the result URL with the requested URL. If the differs, it assumes that the language identifier was added and redirects to the result URL.

Here is a behavior example for the case when a) URL negotiation is enabled and language prefixes are set up properly, b) browser negotiation is enabled and goes after the URL negotiation.

Before patch:
- "domain.com/" URL accessed
- "domain.com/" page cache is killed
- all links rendered on the page leads to language prefixed URLs

After patch:
- "domain.com/" URL accessed
- "domain.com/" page cache is killed
- user is redirected to language prefixed URL ("domain.com/en") which can be cached

So, the patch does not avoid cache kill, instead it introduces language redirect. (Which in D7 was usually performed by globalredirect module.)

Problem A and D

Implement hook_requirements() that warns user about the possible cache issues
- if there is more that 1 language and the path prefix is not set for some language
- if browser negotiation is the only enabled method
- if URL negotiation is set after the browser negotiation

Alternatively, the language_negotiation_url_prefixes_update() function can be updated to always add language path prefix to all languages. But this requires some tests update, see #66 for details.

Alternative resolution

(implemented in #116)

- Introduce new response policy `Vary`, that will be less disruptive than `KillSwitch`.
- Modify PageCache to respect Vary headers coming from response.

Latter is a good thing in general, going beyond the scope of language detection.
Currently PageCache distinguishes cached pages only by predefined "tags": host, URL, and requested format. The only supported Vary header is cookie, and it's handled in ad-hoc manner.

Since page cache occurs on the early stage of request processing, the fastest/easiest way to get the list of vary headers is to fetch them from "generally" cached response object, and then check if there are any headers in request object that match vary criteria.

Regarding redirect and related problems A-D, I believe they should be handled in #2641118: Route normalizer: Global Redirect in core, and this issue should take care of cache awareness of browser language detection.

Remaining tasks

+ Fix tests
+ Write specific tests
- Review
- Maybe address Problem A and D.

User interface changes

Possibly errors for unsupported configurations.

API changes

Not likely. Additions needed.

The Page Cache module caches whole responses for requests. It does not respect the Http Vary header though.

The Page Cache module calculates the CID as follows:

<?php
  /**
   * Gets the page cache ID for this request.
   *
   * @param \Symfony\Component\HttpFoundation\Request $request
   *   A request object.
   *
   * @return string
   *   The cache ID for this request.
   */
  protected function getCacheId(Request $request) {
    $cid_parts = [
      $request->getSchemeAndHttpHost() . $request->getRequestUri(),
      $request->getRequestFormat(),
    ];
    return implode(':', $cid_parts);
  }
?>

-> It does not include cache contexts, which is a critical thing to consider, and developers might oversee this very easily.

Example
Suppose you have a controller which sets cache contexts for HTTP request headers Origin (for cross-origin resource sharing). The controller legitimately adds 'Origin' to the 'Vary' response header entry. The Page Cache does not respect this, and thus a mismatched response might be returned. Browsers might then react with a blocked resource by the same origin principle.

How to avoid this problem

When writing custom controllers: One current workaround for this problem is to completely skip Page Cache by not creating CacheableResponseInterface responses. This is a huge minus though, because then you might have no cache at all for the backend.

Another way is to use Drupal's opt-in CORS support. This can be sufficient if the response header generation is kind of static and especially not conditionally. One use case I have found where this opt-in support is not sufficient, is when to implement a resource for serving Accelerated Mobile Pages, since these ones require a certain logic for generating an acceptable response header. Especially when having a site running on multiple domains and protocols, this might get really tough.

Proposed solution

Currently know of 3 options:

1. Page Cache must automatically create a cache context on its own regards the Vary header entry, if it's something different than Cookie value or
2. Page Cache must either include cache contexts during its CID calculation, at least a minimum of the available ones which affect anonymous request variation - especially HTTP request headers or
3. Page Cache must skip (but not set Cache-Control to must-revalidate, no-cache etc.) caching for anonymous requests having other values than Cookie in the Vary entry of the response header.

(I'd go for option 1)

Problem

impossible to add a view block using content entities with revision

Steps to reproduce

1) Add new view using entities with revisions for example : Content revisions, paragraph revisions
2) Check "Create a block"
3) Feel all required fields
4) Save the view

As a result you should see few warnings

Notice: Undefined variable: table in /web/core/modules/views/src/Plugin/views/wizard/WizardPluginBase.php on line 942

Notice: Undefined index: type in /web/core/modules/views/src/Plugin/views/wizard/WizardPluginBase.php on line 944

Which lead to the error

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "" plugin does not exist. in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 52 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

I have debugged it a little bit and found that in WizardPluginBase.php, we receive the wrong bundle value ".type" as result we can't get table data

$table_data = Views::viewsData()->get($table);

Problem/Motivation

The media library field widget has styling issues when used with the off canvas dialog. This is due to the aggressive styling the off canvas dialog uses to enforce consistent styling.

Proposed resolution

Add off canvas specific rules to the media library widget to support the styling of the off canvas dialog.

Before the patch:

After the patch:

Remaining tasks

Review patch.

User interface changes

The media library looks better when used with the off canvas dialog.

API changes

None.

Data model changes

None.

Problem/Motivation

This is a regression caused by #2208429: Extension System, Part III: ExtensionList, ModuleExtensionList and ProfileExtensionList.

system_get_info() used to return the module name passed in even when it was handed something invalid. ModuleHandler::getName() used to call it, when it was changed to call ExtensionList::getName() directly, that behaviour wasn't preserved.

The issue is that the module list always includes the profile (for example on an 8.5 site I have locally, 'standard' is in core.extension.yml as a module). However the newly added extension list only has the profile as a profile.

I found #2939904: Fix system_get_info() for non-installed modules. ModuleHandler::getName() used to call system_get_info(), but now it calls ExtensionList() directly, so it needs to catch the exception too.

Proposed resolution

If an invalid module name is passed, catch the exception and return the raw module name passed in.

The root cause here is that profiles are sometimes treated as modules and sometimes not, #3023133: [PP-1] Extension System, Part V: Decouple profiles from modules is one issue trying to deal with that, but this is critical bug and clear regression.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Original report

I recently upgraded from Drupal 8.5.6 to 8.6.1 and everything appeared to go well. But I noticed today that when attempting to edit a view or review the user list on the site, I received this message:

Drupal\Core\Extension\Exception\UnknownExtensionException: The module minimal does not exist. in Drupal\Core\Extension\ExtensionList->get() (line 257 of /core/lib/Drupal/Core/Extension/ExtensionList.php).

I happened to be on the Status page for the install and noted the installation profile looked liked this:

This is what appears in the error log:

Uncaught PHP Exception Drupal\Core\Extension\Exception\UnknownExtensionException: "The module minimal does not exist." at /core/lib/Drupal/Core/Extension/ExtensionList.php line 257

So it looks like the install profile was removed when the upgrade was conducted.

When opening a view in a modal dialog, the title says '[object Object]' as this title is set as an array.

Problem/Motivation

node_node_access() always adds the user cache context for the update/delete operations.

There are however several cases where that's actually unnecessary, for example for users without the edit/delete own permission.

It could still end up being merged in if a user has the permission, but you can at least avoid it if no user has that permission.

This isn't a huge deal by default as it "just" results in the local tasks block being given the user cache context, but if you combine it with #2972308: Allow users to translate content they can edit, then through content_translation_language_fallback_candidates_entity_view_alter(), you can end up with the user cache context on the main content, disabling dynamic page cache in the process.

Proposed resolution

Check the permission first, do not add the user cache context if the user doesn't have the permission.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In the installer, I've found several typos ("settigns.php", "the the", and "profile's" where it should be "profiles") which should be fixed in code comments as well as a missing @param declaration in a docblock.

Proposed resolution

I've included a patch which should fix all of these.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

The template suggestions for the More link template provided by the Views module are in the wrong order.

To reproduce:

1. Activate the theme debug mode
2. Create fake nodes
3. Create a new view with a block display
4. Add a more link
5. Display the block somewhere
6. Look at the suggestions in the page

Problem/Motivation

The PageTitle block is special and only works when passed directly through \Drupal\block\Plugin\DisplayVariant\BlockPageVariant which only block.module does. Other block-using mechanisms (such as layout builder) cannot use it for this reason.

Proposed resolution

Determine the best way to handle PageTitleBlock either by:

1. Removing it from the list of blocks Layout Builder can place
2. Providing a mechanism for Layout Builder to conditionally exclude blocks from being place-able.
3. Consider revamping PageTitleBlock in some fashion to make it more globally usable.
4. Some other solution not yet considered.

Remaining tasks

1. Choose a path forward from the list above.
2. Implement choice.

User interface changes

Depending on our choice above, this could change nothing (Make the block work everywhere) or go so far as to add a new interface for removing blocks from the list of place-able blocks.

API changes

TBD

Data model changes

TBD

Browser language detection is skipped, if a browser/robot without Accept-Language header calls the page and the default language node is put into cache. Afterwards, the default language node is always delivered until cache is cleared/rebuilt, the browser language of subsequent requests is ignored.

My language detection order is:

• URL
• Browser
• Default / selected language

I built a test to illustrate this issue (drupal-browser-detection-test-2986325-1-D8.patch).

My solution for this issue is to trigger page_cache_kill_switch even if no Accept-Language header is set (but $this->languageManager and $request are not NULL). That is in the middle between the old code and the current.

LanguageNegotiationBrowser.php:

if ($this->languageManager && $request) {
      if ($request->server->get('HTTP_ACCEPT_LANGUAGE')) {
        $http_accept_language = $request->server->get('HTTP_ACCEPT_LANGUAGE');
        $langcodes = array_keys($this->languageManager->getLanguages());
        $mappings = $this->config->get('language.mappings')->get('map');
        $langcode = UserAgent::getBestMatchingLangcode($http_accept_language, $langcodes, $mappings);
      }
      // Internal page cache with multiple languages and browser negotiation
      // could lead to wrong cached sites. Therefore disabling the internal
      // page cache.
      // @todo Solve more elegantly in https://www.drupal.org/node/2430335.
      \Drupal::service('page_cache_kill_switch')->trigger();
}

Problem/Motivation

In #2542050: Toolbar implementation creates super annoying re-rendering. Toolbar added the following code:

/**
 * Implements hook_preprocess_HOOK() for HTML document templates.
 */
function toolbar_preprocess_html(&$variables) {
  if (!\Drupal::currentUser()->hasPermission('access toolbar')) {
    return;
  }

  $variables['attributes'] = new Attribute($variables['attributes']);
  $variables['attributes']->addClass(['toolbar-tray-open', 'toolbar-horizontal', 'toolbar-fixed', 'toolbar-loading']);
}

Up to this point $variables['attributes'] is an array instead of an object. hook_preprocess_html functions in themes might expect the variable to be an array instead of ArrayAccess object since this change was introduced in 8.4.0.

This also makes theming fragile because depending on whether Toolbar module is enabled or not, the variable will be ArrayAccess object or an array.

Proposed resolution

Use the existing array to add classes rather than converting the array to an Attribute object.

Remaining tasks

1. Write a patch
2. Agree on how to handle the BC break
3. Review
4. Commit

User interface changes

None.

API changes

'attributes' variable in hook_preprocess_html will be always an array instead of Attribute object.

Data model changes

None.

Problem/Motivation

Currently there is no enforced standard for deprecation error messages triggered but @trigger_error in core and contrib. Having a standard template for these deprecations would assist in automated parsing of the messages, and allow for the possibility of determining things like which version of drupal a particular deprecation was added.

Proposed resolution

Add a new component utility class DeprecationError, with static methods for triggering deprecation errors in the correct format for core and contrib. This also gives the benefit of a single point of processing for any additional things we may want to do around deprecation errors in the future.

Introduce this utility class now, and require its use over directly calling @trigger_error for new deprecation errors. When all current deprecation errors are removed in Drupal 9.0.0, all new deprecations will go through this method.

Remaining tasks

Reach consensus on naming and functionality
Reach agreement on exact error template
Commit it and make policy

User interface changes

None

API changes

New utility class DeprecationError. Proposed methods:

 public static function triggerCore($change_record, $deprecation, $replacement, $deprecated_version, $removal_version = NULL)
 public static function triggerContrib($deprecation, $replacement, $deprecated_version, $removal_version, $project = "")

Data model changes

Release notes snippet

Problem/Motivation

History

We added support for CRUD operations on content entities via REST without test coverage. Test coverage followed in #2737719: EntityResource: Provide comprehensive test coverage: for every entity type, every format, every method. Translation support never materialized — this issue is the proof of that:

1. this was created in November 2013 (when REST was still in heavy development).
2. Then it was only commented on again almost a year later, in Q4 2014! From #3–#25, there was a solid discussion about how this should work. But no patches.
3. One comment in all of 2015: #26, just updating this issue summary.
4. Then another year later, I commented, in February 2016, in #27, bumping it from Normal (GASP) to Major.
5. Now we're another year later, and still no work happened.

As such, we have no official, and no documented way to handle translations of entities. Do we return all translations at once or not? How do you modify existing translations? And so on.

@Crell and @dixon_ outlined how they thought it should work in #21 and #22: they tried to adhere to RESTful principles as closely as possible. But alas, per the timeline: no work was done.

So, that brings us to today, where Drupal 8 has been out for more than a year (since November 2015), Drupal 8.0, 8.1 and 8.2 have been released, and 8.3's beta is being tagged in a few days. Drupal 8.3 will ship without this too. That's 4 minor releases without support for this. Time to change that. 8.4 MUST have this fixed.

How to move forward: just add test coverage?

However, that also means that we can't just do anything. We cannot break backwards compatibility. Unfortunately, the #21/#22 proposal would break BC.

As I wrote in #46:

Just had a discussion about this with @damiankloip & @tedbow. (On January 30, but only got around to finish this now.)

There are two key observations that were made:

1. Doing the multipart approach @dixon_ suggested in #22 may very well be the most correct approach (the ideal solution), but doing so is unquestionably a BC break.
2. Ted showed in #32 that this already works today. In a way that is natural/intuitive/guessable to a Drupal developer: via a langcode path prefix. Changing that now would also effectively be a BC break, since it's extremely likely that multilingual sites are already suing this.

So doing the ideal isolation would result in a double BC break, hence that approach must be postponed to D9.

---

The pragmatic solution is therefore to just expand the test coverage in EntityResourceTestBase to test all HTTP methods against all entity types in multiple languages.

Why does the existing code already kinda work? Thanks to \Drupal\Core\ParamConverter\EntityConverter::convert(), which calls getTranslationFromContext().

In other words, the ideal solution is without question off the table. But is adding tests enough? There are several problems/questions to answer:

1. #49 points out that getTranslationFromContext() supports not just path-based language negotiation, but also domain etc. Do we want to support that?
2. #51 points out that the HAL normalization and hence the HAL+JSON format in fact does not return a single language, but all translations of every single field. So the HAL normalization is already kind of doing what #22 wanted to do. If a particular language is requested, does that mean that HAL should return only that translation?

Proposed resolution

1. Add test coverage for serialization-normalizer-based formats (currently only json): test that /de/node/1?_format=json returns the German translation, and also allows modifying that translation
2. Add test coverage for hal-normalizer-based formats (currently only hal_json): test that /node/1?_format=hal_json returns all translations, and /de/node/1?_format=hal_json returns only the German translation
3. Language negotiation mechanisms other than the path-based one: TBD

Remaining tasks

TBD

User interface changes

None.

API changes

TBD

Data model changes

None.

Problem/Motivation

To reproduce:

1. Enable rest, hal, language, content_translation on a standard profile.
2. Enable a second language (German) and make the node type "page" translatable with all fields.
3. Save the attached JSON text file (generated by NodeHalJsonCookieTranslationsTest).
4. Enter the Drupal console and use the following commands:

$serializer = \Drupal::service('serializer');
$data = $serializer->decode(file_get_contents('JSON_FILE'), 'hal_json');
$node = $serializer->denormalize($data, 'Drupal\node\Entity\Node', 'hal_json');

The deserialized node's translation contains values for all "default" items (status, sticky, created, changed, langcode, etc.)

print count($node->changed); // 1
print count($node->getTranslation('de')->changed); // 2

The duplicates increase each time the node is normalized and denormalized.

$node = $serializer->denormalize($serializer->normalize($node, 'hal_json'), 'Drupal\node\Entity\Node', 'hal_json');
print count($node->changed); // 1
print count($node->getTranslation('de')->changed); // 3
$node = $serializer->denormalize($serializer->normalize($node, 'hal_json'), 'Drupal\node\Entity\Node', 'hal_json');
$node = $serializer->denormalize($serializer->normalize($node, 'hal_json'), 'Drupal\node\Entity\Node', 'hal_json');
print count($node->changed); // 1
print count($node->getTranslation('de')->changed); // 5

This looks like a bug in the field denormalization which causes it fail to properly clear default values.

Tested on 8.5.x and 8.3.7. This is causing test failures in #2135829: [PP-1] EntityResource: translations support.

Proposed resolution

Avoid the field value duplication.

Remaining tasks

1. Get patch to green.
2. Review.
3. Commit.

User interface changes

None.

API changes

None.

Data model changes

None.