Problem/Motivation

Drupal 9 will come with a new version of Stable. Initially, the plan was to replace the old Stable with a new Stable theme, which essentially would force all themes to upgrade to the next Stable theme as part of the major version upgrade. Upgrading Stable can be cumbersome. Given that upgrading to the next Stable theme comes with very little benefits, it seems unlikely that themes would be interested in upgrading unless they are forced to do so.

Proposed resolution

1. Make base theme a require property in themes: #3065545: Deprecate base theme fallback to Stable
2. Copy current Stable to contrib project so that it can be used with Drupal 9. There's already a namespace reserved for this.
3. Create a new Stable theme with a new name for Drupal 9, following the same steps used to create Drupal 8 Stable in #2575737: Copy templates, CSS, and related assets to Stable and override core libraries' CSS
   1. Automated test for library overrides to ensure completeness
   2. Automated test for template overrides to ensure completeness
   3. Copy all the CSS, changing image paths as necessary
   4. Copy all the images, no changes
   5. Add all the libraries-override needed to stable's .info.yml
   6. Copy all the templates, with appropriate doc changes
4. Deprecate the Drupal 8 Stable theme in Drupal 9 to be removed in Drupal 10.

Remaining tasks

• Agree on maintainers of the contrib project
• Copy code from Stable to the new project
• Decide what happens to Classy which depends on Drupal 8 Stable
• Agree on a name for the Drupal 9 Stable: #3094440: Agree on name for Drupal 9 Stable
• Create the Drupal 9 Stable theme and copy all the templates and assets to the new theme
• Deprecate Drupal 8 Stable

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Easyrdf is only used in tests and doesn't support php 7.4
It looks like its no longer maintained

Proposed resolution

Attempt to remove dependency on it

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Requests have their query parameters overridden by RouteProvider::getRouteCollectionForRequest() (here) when a route collection is matched in the cache. This is problematic if the cache entry was saved during a subrequest which alters the original request, specifically DefaultExceptionHtmlSubscriber, which sets two internal query parameters (_exception_statuscode and destination) for the error route.

This is problematic in so far as it's not intuitive behaviour (though this dates back to some early pre-8.0 work; see #2480811: Cache incoming path processing and route matching) but more importantly that the query parameters of later requests are overridden with those in the cache. For a form submission, this would mean the destination is overridden and incorrect, but in the case of a jsonapi path, it also means you get:

Drupal\\Core\\Http\\Exception\\CacheableBadRequestHttpException: The following query parameters violate the JSON:API spec: 'destination', '_exception_statuscode'. in Drupal\\jsonapi\\EventSubscriber\\JsonApiRequestValidator->validateQueryParams()

For instance, a common pattern in OAuth/JWT workflows is that a client will make a request with an existing access token; if it's unsuccessful (e.g., returns 401 - see #2840205: Error messages/codes should be more helpful & match spec.) then the client will attempt to obtain a new access token with a refresh token grant, and retry the original request. In this case, the retried request will fail with the above exception against a jsonapi endpoint as the now-authorized request will have the non-JSON:API spec compliant query string added.

Proposed resolution

The query string recovery from cache has mostly to do with the private files controller; see notes below. However, this issue is sensitive to alterations to the Request object prior to the cache ID generation for the collection cache, earlier even than incoming path processing.

Current thoughts are to not cache the match if we're doing a subrequest (though we currently lack that context as that's information stored in the kernel) or set the format for json:api requests sooner, so as to keep the html exception handler from firing to begin with. Or, something else?

Adjust the route collection cache cid to include the query parameters stored on the Request object after early processing.

Remaining tasks

Subsystem maintainer/core committer review.

User interface changes

None

API changes

None.

Data model changes

None.

Release notes snippet

Not necessary?

The Drupal\Core\Template\Attribute class and its helper classes have no Drupal dependencies apart from Drupal Components. There already exists at least one project where Attribute classes are used independently of Drupal, and it would be good if they could be used as a proper Composer package.

Problem/Motivation

When the manage toolbar is open, in the vertical orientation, sub-menus are available for each section. Visually they are just an icon, but for screen readers there is a visually hidden name.

Currently these buttons conflate the name and state; the name of the button is the opposite of the current state. There's some unnecessary cognitive effort there, to figure out what the current state is.

The behaviour of the button is only conveyed by the name string. The fact that it opens and closes a submenu isn't machine readable.

Proposed resolution

Use aria-expanded to convey the current open/closed state.
Use a constant name for the button: "parent-link-title sub-menu".

The button's name, role, and value will no longer be conflated. There's a clearer indication of the behaviour and current state, which is programmatically understood by assistive tech. Screen reader announcements will be along the lines of "structure submenu, button, expanded" and "structure submenu, button, collapsed".

Remaining tasks

Update JS + templates.
Update tests.

User interface changes

Improves semantics of toolbar submenu buttons for assistive technology.

API changes

None.

Data model changes

None.

Optimise entity reference autocomplete widget should load referencable entities as little as possible, instead of each time form element is rendered.

Currently \Drupal\Core\Field\Plugin\Field\FieldWidget\EntityReferenceAutocompleteWidget::formElement is called for each field item, but calls $items->referencedEntities() each time. This method loads referencable entities for all field items.

In cases for example where Entity Reference Revisions are used, referencedEntities actually loads revisions, which do not have a cache! (See #2620980: ContentEntityStorageBase::loadRevision() should use the static and the persistent entity cache like ContentEntityStorageBase::load()), so page load time and database queries increase exponentially.

I ran into the issue of admin_toolbar_tools being incompatible with dynamic page cache - #2897309: admin_toolbar_tools module makes all pages uncacheable. After some debugging I figured the cause are the CSRF tokens in the links. However those where already correctly place-holdered, still they ended up being rendered too early causing the 'session' cache context being added in, making the requests uncachable.

Turns out, problem is that toolbar forces replacing placeholders. Fixing that resolves the problem admin_toolbar_tools and it works just fine.

There is a bug in URL alias AliasStorage for Drupal core 8.6/8.7

On path update, the "pid" is set to the affected rows return value, which is "1" not the actual path id.

This means the alias save return value and also hook_path_update gets the incorrect path id value of "1"

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Path%21Al...

Previously, in 8.5 the $fields['pid'] = $pid; was set before the path update query:

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Path%21Al...

Patch pending.

Problem/Motivation

It looks like someone removed the ability to attach inline JS. No idea why, but I need this and I cannot move this to a library file.

Issues:

• JS cannot attached with 'html_head' as the order is random.
• The order of code is broken as inline JS need to be added after JS files and not before.
• CDATA is not added automatically and could be theme specific
• Inline JS code cannot moved to files in many cases as these are dynamic and may not automatically drupalSettings.

LogicException: You are not allowed to use js in #attached in drupal_process_attached() (line 1759 of drupal8\core\includes\common.inc).

Example code. See http://cgit.drupalcode.org/google_analytics/tree/google_analytics.module... for more:

    if ($config->get('track.adsense')) {
      // Custom tracking. Prepend before all other JavaScript.
      // @TODO: https://support.google.com/adsense/answer/98142
      // sounds like it could be appended to $script.
      $page['#attached']['js'][] = array(
        'data' => $googleanalytics_adsense_script,
        'group' => JS_LIBRARY-1,
        'type' => 'inline',
      );
    }

    $page['#attached']['js'][] = array(
      'data' => $script,
      'scope' => 'header',
      'type' => 'inline',
    );

Additionally Wim pointed indirectly to #2368797: Optimize ajaxPageState to keep Drupal 8 sites fast on high-latency networks, prevent CSS/JS aggregation from taking down sites and use HTTP GET for AJAX requests. The presentation Optimizing the critical rendering path in this case shows that the objections about inline JS are fairly invalid and the document proves that inline CSS/JS assets are highly critical feature and placing all stuff in external files is simply incorrect for page load speed and mobile first, too.

Proposed resolution

Respect dependency and load order for inline JS and utilize the libraries api for inline js.

Remaining tasks

• Write tests
• Refactor patch from #173 to be used for JS and not CSS
• Document any api changes

API changes

Unknown

Problem/Motivation

Follow-up to #3013210-30: Add drupal/core-filesecurity component for writing htaccess files

+++ b/core/lib/Drupal/Component/FileSecurity/FileSecurity.php
@@ -0,0 +1,160 @@
+# If we know how to do it safely, disable the PHP engine entirely.
+<IfModule mod_php5.c>
+  php_flag engine off
+</IfModule>

core no longer running on php5 so this lines should be removed

Proposed resolution

Do not add protection for unsupported php version

Remaining tasks

- discus when to remove
- check supported apache versions

User interface changes

no

API changes

no

Data model changes

no

Release notes snippet

TBD

I would like a token site:base-path which contains the value returned by base_path().

If approved, I will write a patch.

Following is the current language fallback logic used in the path.alias_repository service:

    // Always get the language-specific alias before the language-neutral one.
    // For example 'de' is less than 'und' so the order needs to be ASC, while
    // 'xx-lolspeak' is more than 'und' so the order needs to be DESC.
    $langcode_list = [$langcode, LanguageInterface::LANGCODE_NOT_SPECIFIED];

This logic doesn't take into account where custom/contrib modules may implement hook_language_fallback_candidates_alter() to add/remove fallback candidate languages.

Example of one such contrib module:
Language hierarchy: https://www.drupal.org/project/language_hierarchy

Attaching a patch to user proper fallback mechanism. i.e.:

    // Get list of all languages that current language falls back on.
    $langcode_list = $this->languageManager->getFallbackCandidates([
      'langcode' => $langcode,
      'operation' => 'path_alias',
    ]);

The properties of the upper iframe are missing the allowfullscreen = "" property. Therefore, full-screen mode will not work with remote videos.

Problem/Motivation

(/admin/content/files allows only to browse the files.

There seems to be no way in Drupal to overwrite a file, and keeping the same filename.

Deleting the file and replacing it with a new version while retaining the same filename does not work, as the new version would automatically get a prefix ("_0") attached to it each time a new version is uploaded (for example: "filename_0.pdf"; "filename_1.pdf", etc.).

"/admin/content/file/fiiename.pdf" seems to allow the file to be replaced when it is saved, but it still does not automatically replace it with the new version.

Proposed resolution

It should be possible to overwrite a file and keeping the same filename.

Original report by [dupal.user]

(There seems to be no way in Drupal 8 to to manually delete a file, other than waiting for some automatic cleanup of orphaned files.

Primitive solution: /admin/content/files may allow deleting files just as /admin/content allows deleting content.

Better solution: It should be possible to choose between deleting or unlinking previously uploaded file field attachments when editing a node.

Deleting is required in order to replace a file with a new version.)

Found using Umami profile on Chrome at admin/config/media/image-toolkit

In form-text.css, .form-element with is set to 100% at widths up to 600px. This pushes suffixes to a new line.

Hi all,

I just found one issue in menu configuration. When you add link to a menu, it was redirection to the menu type listing page. Actually, it should redirect to that particular menu links listing page.

Thanks & Regards,
Saranya.P

When importing a config where system.site UUID is empty, the following error is thrown:

Site UUID in source storage does not match the target storage.

If the system.site UUID is deliberately empty in the imported config, the config importer should not fail. It should only fail if the system.sit UUID is set and is different from the current system.site UUID.

After a good looking upgrade from 8.6.x to 8.7.9 the Drupal instance fails with this error:

AH01071: Got error 'PHP message: Uncaught PHP Exception Drupal\\Component\\Plugin\\Exception\\PluginException: "Entity not found through the menu link plugin definition and could not fallback on UUID '8a83e685-b195-4ba8-892b-3e511149972c'" at /var/www/web/core/modules/menu_link_content/src/Plugin/Menu/MenuLinkContent.php line 157\n'

Not sure if this may be related to revisonable menu items.

Best,
Chris

After upgrading to 8.4 we noticed a performance decrease on one of our sites. The page that is taking minutes to load is a multilanguage page with several field collections and revisions enabled.

Some debugging lead me to the change in issue 2864995.

This change introduces a latestRevision() method which is used by QuickEdit (this explains why it is only when logged in). On a field collection that has about 4000 revisions, this query takes seconds to run.

If I understand correctly the change introduces a self-join to the base revision table. Because of this, for each revision in the table, a set of revisions + next revisions is added to the result. From this result only the row that has no next revision (is null) is used (in my case 7000000 rows are searched for the one that has no next revisions).

Maybe we can think of a more efficient way of querying the latest revision?

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the breakpoint, color, layout_builder, layout_discovery, and field_layout modules.

Also the parts of the system module related to installing/uninstalling/configuring themes.

Proposed resolution

Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:

1. Find the hook_help() implementation function in the core/modules/MODULENAME/MODULENAME.module file(s). For example, for the core Contact module, the module files is core/modules/contact/contact.module, and the function is called contact_help().
2. Locate the module overview portion of this function. This is located just after some lines that look something like this:
   

     switch ($route_name) {
       case 'help.page.contact':
   

   And ends either at the end of the function, or where you find another case 'something': line.

3. We want to end up with one or more topics about the tasks that you can do with this module, and possibly a section header topic. So, read the help and figure out a good way to logically divide it up into tasks and sections. See Standards for Help Topics for information on how to do this.
4. See if some of these tasks are already documented in existing topics. Currently, all topics are in core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
5. For each task or section topic that needs to be written, make a new Twig topic file (see Standards for Help Topics) in core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix).
6. File names must be MODULENAME.TOPICNAME.html.twig -- for example, in the Action module, you could create a topic about managing actions with filename action.managing.html.twig (and "MODULENAME" can be "core" as discussed above).
7. Make a patch file that adds/updates the Twig templates. The patch should not remove the text from the hook_help() implementation (that will be done separately).

Remaining tasks

a) Make a patch (see Proposed Resolution section).

b) Review the patch:

1. Apply the patch.
2. Turn on the experimental Help Topics module in your site, as well as the module(s) listed in this issue.
3. Visit the page for each topic that is created or modified in this patch. The topics are files in the patch ending in .html.twig. If you find a file, such as core/modules/help_topics/help_topics/action.configuring.html.twig, you can view the topic at the URL admin/help/topic/action.configuring within your site.
4. Review the topic text that you can see on the page, making sure of the following aspects:
   • The text is written in clear, simple, straightforward language
   • No grammar/punctuation errors
   • Valid HTML -- you can use http://validator.w3.org/ to check
   • Links within the text work
   • Instructions for tasks work
   • Adheres to Standards for Help Topics [for some aspects, you will need to look at the Twig file rather than the topic page].
5. Read the old "module overview" topic(s) for the module(s), at admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.

User interface changes

Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.

API changes

None.

Data model changes

None.

Release notes snippet

None.