Problem/Motivation

Drupal requirements list the following MySQL/MariaDB/Percona requirements currently:

Required MySQL 5.5.3/MariaDB 5.5.20/Percona Server 5.5.8 or higher with InnoDB as the primary storage engine, and requires the PDO database extension. MySQL 8 is supported only on Drupal 8.6 or higher.

Decide on Drupal 9 requirements changes if any.

Distros

• Debian
  • 9 (17th june 2017): Ships with MariaDB 10.1.41 & MySQL 5.6.47
  • 10 (6th july 2019): Ships with MariaDB 10.3.18 & MySQL 5.7.29 and 8.0.19
• Ubuntu
  • 16.04 (21 th april 2016): Ships with MariaDB 10.0.24 & MySQL 5.7.29 and 8.0.19
  • 18.04 (26th april 2018): Ships with MariaDB 10.1.29 & MySQL 5.7.29 and 8.0.19
  • 20.04:
• Red Hat Enterprise Linux
  • 6 (10th november 2010): Ships with No MariaDB & MySQL 5.5.73
  • 7 (10th june 2014): Ships with MariaDB 5.5.64 & MySQL 5.6.47
  • 8 (7th may 2019): Ships with MariaDB 10.3.17 & MySQL 8.0.19

Databases

• MySQL (https://endoflife.software/applications/databases/mysql)
  • 5.6 released on 5th february 2013 and EOL February 5, 2021
  • 5.7 released on 21th october 2015 and EOL October 21, 2023
  • 8.0 released on 19th april 2018 and EOL April, 2026
• MariaDB (https://mariadb.com/kb/en/mariadb-server/ and https://mariadb.org/about/#maintenance-policy)
  • 5.5 released on 25th february 2012 (already EOL)
  • 10.1 released on 30th june 2014 and EOL October 2020
  • 10.2 released on 18th april 2016 and EOL May 2022
  • 10.3 released on 16th april 2017 and EOL May 2023
  • 10.4 released on 9th november 2018 and EOL June 2024

Proposed resolution

TBD.

Remaining tasks

Discuss.

User interface changes

None.

API changes

TBD.

Data model changes

TBD.

Release notes snippet

TBD.

Problem/Motivation

The Drupal core Bartik theme was released as part of Drupal 7 in January 2011, 9 years ago. It was great! It also stayed pretty much the same ever since and been included with Drupal 8 as well and potentially will be the default theme of Drupal 9 even. The web moved forward a whole lot in 9 years and Bartik is not doing justice to Drupal anymore. It was great in 2011, it is not great anymore.

Proposed resolution

Drupal 9 needs a new default frontend theme. A new, modern, clean frontend theme, Olivero is being built in the contributed project https://www.drupal.org/project/olivero for inclusion in Drupal core. This issue is to gather requirements for Drupal core inclusion.

Designs are at #3088378: Designs for new front-end theme for Drupal 9.

Olivero beta criteria

Must-haves for the beta release:

Features

• #3115190: Configure and theme the Header Region using POC components
• #3115194: Configure and theme the body field using work pulled from POC
• #3117239: Theme inline Media types
• #3117242: Theme/style the Form elements
• #3118063: Theme Warming/Error Messages
• #3118065: Theme Pager/Pagination component
• #3118071: Theme Content/Article Listing - Node Teaser
• #3118086: Theme/Config Comments
• #3118088: Theme Tags/Categories component
• #3095736: Create content for Drupal's initial "Getting started" page (after minimal or standard profile installation)
• #3116047: Windows High Contrast Accessibility Feedback
• #3083081: Additional accessibility testing on design of new theme
• #3115160: Adding additional menu items overlapping with logo

Olivero Post MVP

Features

• #3086514: Investigate use of the changing color themes for Olivero

User interface changes

A new default frontend theme.

API changes

None.

Data model changes

None.

Release notes snippet

A new modern, clear frontend theme has been added to Drupal core called Oliver. (continue TBD)

3rd party tools needed

• #3092753: Allow PostCSS Plugin “Custom Media” in core for Olivero theme
• #3093013: Allow PostCSS Plugin “PostCSS RTL” in core for Olivero theme
• #3093010: Allow PostCSS Plugin “PostCSS Nested” in core for Olivero theme
• #3117698: Allow PostCSS Plugin “Px to Rem” in core for Olivero theme

Problem/Motivation

Empty sections create unnecessary markup. Also, if you've styled the sections with a background/padding you'll get some unwanted bars.

Proposed resolution

Remove empty sections while preserving their cache metadata.

Remaining tasks

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

Problem/Motivation

In #3107113: [policy] Decide on MySQL/MariaDB/Percona Server version support status for Drupal 9 the general direction of raising MySQL requirements to 5.7 and MariaDB requirements to 10.2 was agreed on.

Proposed resolution

Raise version requirements.

It was discussed that this may require resolving #2985788: Add a separate MariaDB driver first, but that does not seem to be the case.

Remaining tasks

Raise version requirements.
Update documentation.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

Raised the minimum MySQL version to 5.7 and MariaDB version to 10.2 in Drupal 9.

Problem/Motivation

jquery.cookie is no longer a maintained library. A replacement should be found.

> git grep core/jquery.cookie core\core.libraries.yml | wc -l
      3
	    
> git grep -l cookie -- "*.js"
core/assets/vendor/jquery-joyride/jquery.joyride-2.1.min.js
core/assets/vendor/jquery.cookie/jquery.cookie.min.js

This is used in jquery.joyride and the only real usage I have found. Also, jquery.joyride is not hard dependency on cookies.
https://github.com/zurb/joyride/blob/v2.1.0/jquery.joyride-2.1.js#L32

Proposed resolution

Replace jquery.cookie with js-cookie library adding a backwards-compatibility layer. We can model the BC layer off of js-cookie v1.5.1 as well as the js-cookie v2.0.0 release notes (#26).

This approach was originally reviewed by droplet and confirmed by _nod in 2017. There is now a major version 3 in js-cookie that has a beta release. Should we continue to implement js-cookie 2, wait until 3, or find a different dependency to use?

Remaining tasks

• Review approach by JavaScript subsystem maintainers

API changes

Yes, with backwards-compatibility layer.

Release notes snippet

jquery.cookie has been replaced with the js-cookie. The core/js-cookie library is introduced, and a backwards-compatible shim is provided as core/jquery.cookie for Drupal 9.

Problem/Motivation

I can no longer save changes to the layout after any kind of form has been added to the layout.

Steps to reproduce:
1. Enable layout builder on a content type, then open layout builder.
2. Add 'Search Form' block to a section
3. Save the layout
4. Re-open the layout builder, and make some change (e.g. reorder blocks)
5. Attempt to save the layout

The page refreshes, but still shows unsaved changes. At this point, it is no longer possible to save the layout until the search form is removed.

Proposed resolution

Since the layout_builder element is not a form element, and all the layout-related values are managed through the temp store, the layout_builder element can be placed outside the form element, preventing nested <form> tags

1. For the layout_builder render elements in the layout builder defaults and overrides forms, save the list of array parents to a property ('#layout_builder_element_keys') on the top-level $form element.
2. Override/decorate the controller.entity_form controller service.
3. If the form render array returned from the original service's getContentResult() method does not have the '#layout_builder_element_keys' property, return the form render array as is.
4. If the form render array does have have the '#layout_builder_element_keys' property, then use the property to extract the layout builder element from the form render array and move into a separate render array. Return a render array that has the form and the layout builder element array as sibling child elements.
   

   Remaining tasks

   N/A

   User interface changes

   Layout Builder UI will no longer break when rendering forms

   API changes

   N/A

   Data model changes

   N/A

   Release notes snippet

Problem/Motivation

In Bartik theme place block buttons work fine because they inherit the display: inline-block from Bartik theme buttons. In all Bootstrap based themes, and many other themes like Foundation, they collapse to a single line.

Like this:

Proposed resolution

Add display inline block to the place block buttons.

Remaining tasks

Add css

User interface changes

Buttons display correctly in other themes.

API changes

none

Data model changes

none

Problem/Motivation

Debugging caching can be hard.
https://www.previousnext.com.au/blog/ensuring-drupal-8-block-cache-tags-...
...

Although http.response.debug_cacheability_headers: true lets you see your tags and contexts, there's no easy way to see WTF is going on with max-age.

Unfortunately, just knowing what your #cache['max-age'] is doesn't tell you much until this pit of snakes is untangled:

• #2352009: [pp-3] Bubbling of elements' max-age to the page's headers and the page cache
• #2449749: Add #cache['downstream-ttl'] to force expiration after a certain time and fix #cache['max-age'] logic by adding #cache['age']
• #2835068: PageCache caching uncacheable responses (violating HTTP/1.0 spec) + D8 intentionally disabling HTTP/1.0 proxies = WTF
• #2951814: Always set X-Drupal-Cache and X-Drupal-Dynamic-Cache headers, even for responses that are not cacheable
• ...

But, at least knowing you're trying to do the right thing could help in the meanwhile. ;)

It also seems very useful to be able to compare Expires vs. Cache-Control vs. X-Drupal-Cache-Max-Age in various circumstances and configurations as we try to navigate the snake pit.

Proposed resolution

If http.response.debug_cacheability_headers: true is in your services.yml file, also set a X-Drupal-Cache-Max-Age response header.

Remaining tasks

1. Write code
2. Write tests
3. Reviews + refinements
4. RTBC
5. Commit
6. Reach back down into the snake pit and try to make progress on making max-age actually work. :/

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

Probably none.

Hello.

When trying to get Trash (8.2.x) working the Content Moderation module was enabled.
When trying to uninstall, the display says it will be deleting 2 moderation states.
After clicking Delete all content moderation states the below error is shown.

An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /batch?id=12&op=do_nojs&op=do
StatusText: Internal Server Error
ResponseText: {}

I try follow the URL given at the end to see the error but it just redirects back to the Extend page.

The site has no content (pages, articles, or anything).

Problem/Motivation

Drupal's private file access handling will grant access to the file to whoever has access to the entity where the field is attached. This means that a node with a file field will keep access to the node and the file in sync (granting access to the file if the user has access to the node, etc).

This is still true when using files attached to media entities, in the sense that Drupal will by default grant access to the file to users that can access the media entity. However, users may have the expectation that access is also inherited from the entity referencing the media items, which doesn't happen.

This could lead to a potentially misconfigured site, where users could think their assets are protected but they end up being exposed publicly. This mismatch in expectation has been brought up in several issues recently, such as:
#2904842: Make private file access handling respect the full entity reference chain
#2937642: Access to files attached via media entities should be ultimately controlled by the published state of related content
#2981131: Media Entity Pages Anonymous Permission
#2980424: "View media" grants permission on all private media files (no host entity check?)

While the real fix is being discussed in #2904842: Make private file access handling respect the full entity reference chain, this issue aims at reducing the confusion and making it explicit that Drupal does not do that out-of-the box, when using media entities instead of direct file fields.

Steps to reproduce:

Reference scenario (nodes with fields):

1) In a clean install, add a file field to a content type
2) When asked to configure the field storage, select "Private"
3) Create a node as unpublished, uploading a file to that field
4) As an anonymous user, try to reach directly the file URL

Result: Anonymous users do not have direct access to the file, if the node is unpublished.

"Problematic scenario" (nodes with media):

1) In a clean install with the Media module enabled, configure the "File" field on the "File" media type to use the "Private" file storage scheme
2) Add a media field (entity_reference) to a content type, allowing users to reference the "File" media type
3) Create a node as unpublished, uploading a file to that field
4) As an anonymous user, try to reach directly the file URL

Result: Anonymous users have direct access to the file, even though the node is unpublished.

Proposed resolution

Action 1:
Show some messages to the site builder to make that situation clear:

- When configuring a media source field to use the private filesystem

- When checking messages at the status report page

- In hook help text

Action 2:
Add some more detailed information about media access handling and possible misconfiguration scenarios in drupal.org documentation
- Created https://www.drupal.org/docs/8/core/modules/media/setting-up-private-acce... for that

Remaining tasks

- Review patch / Address feedback
- Complete documentation on https://www.drupal.org/docs/8/core/modules/media/setting-up-private-acce...
- Collect sign-off
- Commit

User interface changes

- New warning message(s) will appear to site builders in some contexts (see screenshots above)

API changes

None.

Data model changes

None.

Problem/Motivation

Core and contrib have been using inline variable type declarations in the wild. In the past there were several competing standards, but in recent months and years this has settled on one single standard which has gained widespread adoption (ref. original issue summary, and the discussion in the comments up to #40).

We need to document this standard.

Proposed resolution

Add documentation to the API documentation and comments coding standards page, in a new section titled "Drupal standard for inline variable type declarations", to be placed underneath the existing section Drupal standards for in-line code comments.

The @var tag can document variables in addition to class properties. This can be used when you know more about the type of a variable than is self-evident from the code, such as when you load a specific entity type, or a specific service. In this case you can typehint inline, which improves Developer Experience and Tools Experience.

Syntax example:

/** @var \Drupal\node\NodeInterface $node */
$node = $this->entityTypeManager->getStorage('node')->load(123);

When documenting variables with the @var tag note that you should use the special /** */ delimiters with a double opening asterisk. Always use the fully qualified namespace of the class or interface, and include the name of the variable at the end.

Remaining tasks

• Agree on the proposed standard to adopt, if possible
• Add documentation to the API documentation and comments coding standards page.
• Make a patch for code that isn't using the adopted standard (on related issue #2305641: Use the "standard" format for @var inline variable type declarations).
• Add this standard to Coder.

User interface changes

None.

API changes

None, but new coding standards will be adopted.

Original report by @pfrenssen

There are two three standards for declaring variable types inline currently in use in core:

There are two standards for declaring local variable types inline currently in use in core, and a third standard that is under discussion as part of PSR-5. The Drupal project currently does not have a stated standard on how to document these variables; it should.

The three possible standards are:

1. Using a single asterisk and putting the variable name before the type. From \Drupal\node\Tests\NodeTokenReplaceTest::testNodeTokenReplacement:
   

    /* @var $node \Drupal\node\NodeInterface */
   

   This format is supported by Eclipse, Netbeans, PHPStorm and Zend Studio. If /** is substituted, orif the order is reversed it does not work in Netbeans (not sure about the other IDEs) as of this time (July 2014).

2. Using a double asterisk and putting the variable name after the type. From \Drupal\comment\CommentForm::submit():
   

     /** @var \Drupal\comment\CommentInterface $comment */
   

   This format is only supported by PHPStorm, as of July 2014.

3. Using a double asterisk and @type instead of @var, and optionally followed by a description. This is not yet used in core, so here's an arbitrary example:
   

     /** @type \Drupal\comment\CommentInterface $comment The comment */
   

   This is the proposed standard for PSR5, which has not yet been finalized as of July 2014.

There is a difference of opinion on whether we should be pragmatic and adopt #1 because it actually works now, or #2/#3, because they are more correct and consistent. If we adopt #1, we will most likely need to revise this standard if #3 or something similar is adopted as PSR-5, after IDEs adapt. If we adopt #2 or #3, then people who use some IDEs will not be able to benefit from it.

Hello,

I have just started my journey with Drupal 8 and I discovered that it is not possible to save two different nodes at the same time in D8. The explanation seems to be simple (but I am too novice to be sure of it): Every node_save must invalidate a subset of identical tags (aka ‘4xx-response’ and ‘node_list’). As the doPostSave (which will do first the tags invalidation and then other things like calling the hooks hook_xxx_update and hook_xxx_insert) is in the transaction opened by the node save method, if another node has to be saved at the same moment, it will be blocked by the first node being saved (when its tags invalidation will take place).

As I am using hook_node_update to do processing that can be quite heavy, especially for the automated node updates (I am using automated services to synchronise hundreds to thousands of entities provided by external systems), if my users have to compete with these automated services, they could have to wait for quite a long time before being able to save their contributions…

It would be nice to have the doPostSave executed right after the node has been stored in the DB and the transaction has been closed, this could also solve problems like differing the memcache deletes until the doPostSave to avoid race condition in node_save, to invalidate pages in Varnish when the new data is really available, to allow quite heavy processing without blocking other users….

If this is not possible, it would be nice to add some warnings into the documentation of the hook_xxx_update/insert so developers know that, at that moment, they have to consider that the entity is still not stored (as a rollback is still possible if something bad happens in one of the hook_xxx_update/insert implementations) and heavy processes must be differed…

To reproduce this issue:

• put a breakpoint at line 58 of Drupal\Core\Database\Connection\DatabaseCacheTagsChecksum
• Save one node and execute the merge
• From another window, save another node and try to execute the merge. This 'save node' will be blocked until the transaction of the first node is committed

Thanks

It's possible to fix this for D7 in a BC-compatible way:

https://www.drupal.org/files/1364670.9-pass-image-source-to-dimensions-c...

The editor_entity_update() function gets an EntityInterface, and checks if it is a FieldableEntityInterface. After that it tries to call getRevisionId(), which will succeed in case of the content entities, since content entities are revisionable and fieldable at the same time. However, if a custom entity type (that is not a subclass of content entity) gets saved and it happens to be fieldable but not revisionable then the editor module will trigger a fatal error.

Problem/Motivation

You cannot create a view and try to list rendered entities using relationship.

Steps to reproduce (based on Standard profile):

1. Add an entity reference field named "field_content" to the "page" content type. Allow content > article references.
2. Create and edit a content view.
3. Add a relationship for "Content using field_content." or "Content referenced from field_content."
4. The row style plugin is "Content" by default.
5. Click on "Teaser" in order to change the view mode, nothing happens.
6. You can't choose a view mode even if you don't want to actually use a relationship, just having one on your view triggers this.

The problem is a fatal AJAX error triggered when RowPluginBase::buildOptionsForm() calls RelationshipPluginBase::init() while providing a wrong argument type (Array instead of DisplayPluginBase).

Argument 2 passed to Drupal\views\Plugin\views\relationship\RelationshipPluginBase::init() must be an instance of Drupal\views\Plugin\views\display\DisplayPluginBase, array given, called in /app/web/core/modules/views/src/Plugin/views/row/RowPluginBase.php on line 93

Proposed resolution

Fix it, by passing along the relationship as needed and using it.

Remaining tasks

None.

User interface changes

None

API changes

None

Problem/Motivation

While working on #2831274: Bring Media entity module to core as Media module we identified UX issues with the metadata mapping UI on the Media type form. We agreed to solve this problem in a follow-up.

Proposed resolution

- Offer automatic creation of fields.
- Don't allow same field to be selected for more than once
- Update UI and potentially add checkboxes to opt-in
- If mapping to existing fields, we might want to filter target fields by their data type
- Should we describe metadata attributes?

More info: #2834608: Media entity UI review

Remaining tasks

- Decide on solutions.
- Implement changes

User interface changes

Media type form will be updated.

API changes

None.

Data model changes

None.

Follow-up to #2711099: Categorize migrations according to their type

Problem/Motivation

From #2711099-24: Categorize migrations according to their type, there was mention of adding this functionality into the migrate UI. Here's the follow-up to take the classifications from there and build an option toggle to migrate all/configuration/content. This could help with the things like #2748609: [meta] Preserving auto-increment IDs on migration is fragile, by letting folks push off hitting the final content migrate button a little bit longer.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

The wording for the contextual filter:

Content: Has taxonomy term ID :: Provide default value :: Taxonomy term ID from URL :: Load default filter from node page, that's good for related taxonomy blocks

..is quite confusing and should be expanded to inform users that the ALL fields of the node are checked for entity_reference fields referencing taxonomy terms.

/core/modules/taxonomy/src/Plugin/views/argument_default/Tid.php L119

      '#title' => $this->t('Load default filter from node page, that\'s good for related taxonomy blocks'),

Problem/Motivation

In proposing to make Contact the successor to webforms, we need to make the UI more generic by removing references to 'contact' forms.

Proposed resolution

Change the labels from 'contact form' to 'form'

Remaining tasks

Update the label wherever it is used. Here's a list of places, likely incomplete:

• admin/structure: 'Contact forms' / 'Create and manage contact forms'
• admin/structure/contact: 'Add contact form' (note: possible to change the URL?)
• Breadcrumb

User interface changes

Change references from 'Contact form' to 'Form'

API changes

Data model changes

Came across a site recently which output duplicate HTTP headers for example:

Link: </node/123>; rel="shortlink"
Link: </node/123>; rel="revision"
Link: </node/123>; rel="shortlink"
Link: </node/123>; rel="revision"

Eventually the duplicate headers were sufficient for Varnish (4) to throw an error, along the lines of:

--  BogoHeader     Too many headers: Link: </node/123/trans
--  HttpGarbage    "HTTP/1.1%00"
--  BerespStatus   503
--  BerespReason   Service Unavailable
--  FetchError     http format error

This happened when these sets of headers were each being emitted 4 times:

$ curl -SLIXGET example.com | grep '^Link' | sort | uniq -c

      4 Link: </devel/node/123/definition>; rel="devel-definition"
      4 Link: </devel/node/123>; rel="devel-load"
      4 Link: </devel/node/123/render>; rel="devel-render"
      4 Link: </node/123/delete>; rel="delete-form"
      4 Link: </node/123/devel/token>; rel="token-devel"
      4 Link: </node/123/edit>; rel="edit-form"
      4 Link: </node/123/manage_display>; rel="display"
      4 Link: </node/123>; rel="revision"
      4 Link: </node/123>; rel="shortlink"
      4 Link: </node/123/revisions>; rel="version-history"
      4 Link: </node/123/translations/add>; rel="drupal:content-translation-add"
      4 Link: </node/123/translations/delete>; rel="drupal:content-translation-delete"
      4 Link: </node/123/translations/edit>; rel="drupal:content-translation-edit"
      4 Link: </node/123/translations>; rel="drupal:content-translation-overview"

It's almost certain that the site is doing something wrong in order to be generating these duplicate headers.

However, should core prevent the duplicate headers from being output? It's relatively simple to do so.

Patch on the way which implements this - would welcome any opinions on whether this is core's responsibility though.