Problem/Motivation

We currently have a token [site:url]. The URL of the site's front page. The language prefix is added if the page is multilingual (e.g. http://www.example.com/pl).

In many cases a language prefix is unnecessary.

Example:

Open graph image path
[site:url]/sites/default/files/og_image.jpg

JSON LD ImageObject path
[site:url]/sites/default/files/logo.jpg

We need a new token that returns the base url without the language prefix.

Proposed resolution

Add token [site:base-url]. Base URL.

Remaining tasks

Add test.

User interface changes

Users can use the new token [site:base-url].

API changes

Data model changes

Problem/Motivation

Cleanup the content management user experience.
The management of the visibility of the author and date information is living in the content type configuration page instead of the Manage display tab.

Proposed resolution

Show the author and creation date on the manage display tabs.
Remove the display author information on the content type settings page.
Remove the theme settings "show author picture on the nodes".

Remaining tasks

Show the author and creation date on the manage display tabs.
Remove the display author information on the content type settings page.
Remove the theme settings "User pictures in posts".
Handle the upgrade path.

User interface changes

Disappearance of the vertical tab "Display settings" on the content type edit page.
Disappearance of the theme setting "User pictures in posts"

API changes

None.

Data model changes

Probably none.

Problem/Motivation

As discovered and discussed in comments #2960643-27: Cannot load entity by uuid after rename - #2960643-32: Cannot load entity by uuid after rename the config entity updater might misbehave because it updates the #finished key in the sandbox based on the last entity type.
So if there are multiple entity types being updated in a single update and the last entity type has fewer entities than the previous ones, then not all previous ones will be updated as the sandbox will be flagged as finished.

Proposed resolution

Add a sandbox key to determine the caller and the line it was called from so that if the ConfigEntityUpdater is called twice with the same sandbox but from different code locations we can error.

• Create new updates to ensure all the updates that were updating multiple entity types are completed as expected.
• Publish a change record that custom and contrib has to recreate their updates as well if they update multiple entity types in a single update.

Remaining tasks

None

User interface changes

None

API changes

New exception thrown if ConfigEntityUpdater is called multiple times within the same the $sandbox from different code locations.

Data model changes

None

Release notes snippet

The ConfigEntityUpdater can only be invoked from one location per update hook. Updates that invoke ConfigEntityUpdater twice from the same hook need to be updated.

Problem/Motivation

Right now each content entity type needs to define its set of permissions from scratch, then declare a matching access handler. This is pure boilerplate, an entity type's permissions can very precisely be guessed based on the interfaces it implements and the permission granularity it specifies. Furthermore, requiring each developer to create a new access handler each time leaves room for frequent bugs, such as wrong cacheability metadata.

Proposed resolution

The permissions currently vary based on two factors:

• EntityOwnerInterface
• Permission granularity (bundle / entity_type)

Future iterations of the patch / issue followups would also take into account EntityPublishedInterface.

Generated permissions:

• "administer $entity_type_id" (god mode permission)
• "access $entity_type_id overview" (the basic permission for listings)
• "view $entity_type_id" OR "view own $entity_type_id" / "view any $entity_type_id" depending on EntityOwnerInterface
• create/update/delete permissions per bundle or per entity type, also taking into account EntityOwnerInterface

Note that view permissions are never per-bundle cause we have no way to enforce it, we'd need query access for that (ala node access).

Just like we did for route providers, we introduce the concept of permission providers. That makes this generation opt-in.
Each participating entity type would define the core's permission provider, and the matching access handler. Core calls the permission provider of each entity type when building permissions.

The proposed solution was implemented in the Entity API contrib module (#2801031: Provide a generic entity access handler and permissions) and is used by Commerce and other contrib modules.

Remaining tasks

Roll the patch

I get this error when i try to run the database update:

Failed: Drupal\Core\Entity\EntityStorageException: The entity update process    [error]
failed while processing the entity type menu_link_content, ID: 3. in
Drupal\Core\Entity\Sql\SqlContentEntityStorageSchema->copyData() (line
216 of
D:\FILES\REPOS\detroitmi-test\docroot\core\lib\Drupal\Core\Entity\Sql\SqlFieldableEntityTypeListenerTrait.php).

Tried to add a new taxonomy, this worked, I think, but I can't view it in the admin area or list terms of other taxonomies.

Here are the errors from reports.

Notice: Undefined index: value in Drupal\taxonomy\TermStorage->getTermIdsWithPendingRevisions() (line 381 of /home/feafccef/public_html/live/outdoorfood.club/core/modules/taxonomy/src/TermStorage.php) #0 /home/feafccef/public_html/live/outdoorfood.club/core/includes/bootstrap.inc(587): _drupal_error_handler_real(8, 'Undefined index...', '/home/feafccef/...', 381, Array) #1 /home/feafccef/public_html/live/outdoorfood.club/core/modules/taxonomy/src/TermStorage.php(381): _drupal_error_handler(8, 'Undefined index...', '/home/feafccef/...', 381, Array) #2 /home/feafccef/public_html/live/outdoorfood.club/core/modules/taxonomy/src/Form/OverviewTerms.php(291): Drupal\taxonomy\TermStorage->getTermIdsWithPendingRevisions() #3 [internal function]: Drupal\taxonomy\Form\OverviewTerms->buildForm(Array, Object(Drupal\Core\Form\FormState), Object(Drupal\taxonomy\Entity\Vocabulary)) #4 /home/feafccef/public_html/live/outdoorfood.club/core/lib/Drupal/Core/Form/FormBuilder.php(519): call_user_func_array(Array, Array) #5 /home/feafccef/public_html/live/outdoorfood.club/core/lib/Drupal/Core/Form/FormBuilder.php(276): Drupal\Core\Form\FormBuilder->retrieveForm('taxonomy_overvi...', Object(Drupal\Core\Form\FormState)) #6 /home/feafccef/public_html/live/outdoorfood.club/core/lib/Drupal/Core/Controller/FormController.php(93): Drupal\Core\Form\FormBuilder->buildForm('taxonomy_overvi...', Object(Drupal\Core\Form\FormState)) #7 [internal function]: Drupal\Core\Controller\FormController->getContentResult(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\RouteMatch)) #8 /home/feafccef/public_html/live/outdoorfood.club/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array) #9 /home/feafccef/public_html/live/outdoorfood.club/core/lib/Drupal/Core/Render/Renderer.php(582): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() #10 /home/feafccef/public_html/live/outdoorfood.club/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure)) #11 /home/feafccef/public_html/live/outdoorfood.club/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) #12 /home/feafccef/public_html/live/outdoorfood.club/vendor/symfony/http-kernel/HttpKernel.php(151): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() #13 /home/feafccef/public_html/live/outdoorfood.club/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1) #14 /home/feafccef/public_html/live/outdoorfood.club/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #15 /home/feafccef/public_html/live/outdoorfood.club/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #16 /home/feafccef/public_html/live/outdoorfood.club/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #17 /home/feafccef/public_html/live/outdoorfood.club/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true) #18 /home/feafccef/public_html/live/outdoorfood.club/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #19 /home/feafccef/public_html/live/outdoorfood.club/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #20 /home/feafccef/public_html/live/outdoorfood.club/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #21 /home/feafccef/public_html/live/outdoorfood.club/core/lib/Drupal/Core/DrupalKernel.php(693): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #22 /home/feafccef/public_html/live/outdoorfood.club/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #23 {main}.

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ') AS expression FROM drup_ tfr INNER JOIN drup_ tr ON tfr. = tr. AND tr. = 0 INN' at line 1: SELECT tfr.tid AS tid, MAX(tfr.) AS expression FROM {} tfr INNER JOIN {} tr ON tfr. = tr. AND tr. = 0 INNER JOIN (SELECT t.tid AS tid, t.langcode AS langcode, MAX(t.) AS expression FROM {} t WHERE t. = :db_condition_placeholder_0 GROUP BY t.tid, t.langcode) mr ON tfr. = mr. AND tfr.langcode = mr.langcode GROUP BY tfr.tid; Array ( [:db_condition_placeholder_0] => 1 ) in Drupal\taxonomy\TermStorage->getTermIdsWithPendingRevisions() (line 404 of /home/feafccef/public_html/live/outdoorfood.club/core/modules/taxonomy/src/TermStorage.php).

I haven't had any issues with adding new taxonomies or editing old ones until updating to 8.7.

I have other issues occuring when updating core and content showing page not found but finding no fixes for them.

ContentEntityStorageBase::loadUnchanged() implies that its argument is a valid entity id, but never checks it. Supplying, eg, NULL as an argument can lead to a number of side-effects, such as resetting static cache, calling preload hook for all entities etc, to say nothing about just time it takes. It should return NULL and exit instead.

Problem/Motivation

We have \Drupal\node\ContextProvider\NodeRouteContext that can be used in ConditionPlugin(for example).
But we haven't analogs to another entities. Taxonomy term is very essential page/route and this Context can be useful for Drupal DX.

Proposed resolution

Provide new service in taxonomy module.

Remaining tasks

1. Write code
2. Write tests

User interface changes

No.

API changes

New service.

Data model changes

No.

Problem/Motivation

Currently the Secondary tabs are using the wrong size and spacing, taking too much vertical space:

Proposed resolution

Correct secondary tabs styles according to the design system. Full specs can be checked on Figma, and here's an screenshot:

User interface changes

Vertical spacing will be smaller.

Test instructions

- /admin/content
- /admin/people

Problem/Motivation

Currently if you try to go to /batch?id=123 you get redirected to the homepage with a message stating "No active batch".

Beta phase evaluation

Proposed resolution

Since the batch doesn't exist Drupal should just emit a 404 instead

User interface changes

Error message displayed, "The requested batch ({ID}) could not be found."

Before

After

API changes

If you try to go to /batch?id=123 Drupal emit a 404.

Layout builder incorrectly assumes it can get global contexts and values with getAvailableContexts. This means context providers that correctly adhere to \Drupal\Core\Plugin\Context\ContextProviderInterface currently do not resolve values with layout builder.

When rendering layouts, \Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay::getContextsForEntity should call contextRepository->getRuntimeContexts on the result of contextRepository->getAvailableContexts since by design the value are not intended to be added in getAvailableContexts.

It so happens the CurrentLanguageContext and CurrentUserContext incorrectly populate values in getAvailableContexts, which likely lead to this unnoticed issue. The way these context providers are allowing empty arrays to be passed to getRuntimeContexts is cheating. Even the contract for \Drupal\Core\Plugin\Context\ContextProviderInterface::getRuntimeContexts specifies only those provided must be returned. The attach patch basically does the empty-array cheat on contexts, but using the API as specified.

Contexts like NodeRouteContext correctly implement the interface, and could be made to work with LB. Currently this context also doesnt work properly because it doesnt set a default context value on layout builder build pages (See \Drupal\layout_builder\Context\LayoutBuilderContextTrait::getAvailableContexts). Note, solving NodeRouteContext is not within scope of this bug.

See the documentation for \Drupal\Core\Plugin\Context\ContextProviderInterface::getAvailableContexts, and the interface in general, for more information.

Problem/Motivation

If you call Editor::getFilterFormat() to see if it's set, it doesn't work, and the error message isn't very helpful:

  $format = $editor->getFilterFormat();
  if (empty($format)) {
    return;
  }

If you do this before an editor object is saved, you get a frustrating fatal error about trying to load an entity with a NULL id.

This usually happens calling code in a subroutine at '/admin/config/content/formats/add'.

The error message should be more helpful. The correct way to use this code is to check first with ::hasAssociatedFilterFormat().

  if (!$editor->hasAssociatedFilterFormat()) {
    return;
  }

  $format = $editor->getFilterFormat();
  if (empty($format)) {
    return;
  }

Proposed resolution

Throw a \DomainException with a helpful message if $editor->getFilterFormat() called without a text format assigned to the Editor.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The hard-coded /admin/modules#module-content-moderation uri string in WorkflowListBuilder's empty message leads to a non-existent URL if Drupal is installed in (webroot) subfolder.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

The BC layer for revision metadata keys has been a source of dozens of lost hours and frustration for Entity API maintainers...

Problem/Motivation

When adding new media through the Media Library, it's possible to add more than the allowed number of media items.

Steps to reproduce:
1) In the Media Library, if you can select two items, select two.
2) Now upload a third item.

Expected: You should not be able to select more than the allowed number, or should receive a warning if you do.
Actual: no warning appears, and if you then insert the media you get nothing is attached. It fails without warning.

Video:
https://www.drupal.org/files/issues/2019-10-08/overflow-bug-demo.mov

Proposed resolution

1. When the number of selected items exceeds the maximum allowed, display a warning.
2. If the user then persists on inserting the media items, do not allow it, but display a stronger error message.

Video:
https://www.drupal.org/files/issues/2019-10-08/overflow-fix-demo.mov

Video using two media types:
https://www.drupal.org/files/issues/2019-10-08/overflow-fix-demo-2-two-m...

Remaining tasks

• Discuss solution
• Write patch
• UX Review
• A11Y Review
• Code review
• Frontend framework manager review
• Commit

User interface changes

Added error / warning messages to the media library.

Video of #21: https://www.drupal.org/files/issues/2019-07-17/media-library-exceeds-lim...

The warning after adding and exceeding the limit:
https://www.drupal.org/files/issues/2019-07-17/media-library-add-warning...

The warning after clicking 'Save and select':
https://www.drupal.org/files/issues/2019-07-17/media-library-save-and-se...

The error after clicking 'Save and insert' or 'Insert selected':
https://www.drupal.org/files/issues/2019-07-17/media-library-save-and-in...

API changes

Data model changes

None

Release notes snippet

Hello
Steps required to reproduce the bug
I have set the account registration (/admin/config/people/accounts) to "visitor" and unchecked the field "Require email verification when a visitor creates an account" ) so that the registration form includes password fields, and as soon as the form is submitted, the account is created and you can login (see first image).

However the user receives the same notification with a one time login to 'Reset password' the password (see second image).
1. (more important) problem: The first time the user follows the one time login he get s the message:

You have tried to use a one-time login link that has either been used or is no longer valid. Please request a new one using the form below.

and has to request a one time login again.(see third image)
The second time he can reset the password.

2. Problem: The password is already set when the user registered, so why he has to set it twice.

Expected behavior
1 Problem: no failure
2. Problem: either no email is send or https://www.drupal.org/project/drupal/issues/2977578

Problem/Motivation

The function referencedEntities() in class EntityReferenceFieldItemList return all the referenced entities without access check. As a result it's mandatory to put a access check for every render and provide multiple occasion to forget it and then display a content link to a users that won't have access.

It's a data security access issue if the content is displayed to users who don't have permission.
It's a bad user experience for user to have a clickable link that open on a "access denied" page.

Proposed resolution

As the minimum access permission grant for every content should be the visibility for it. I suggest to have this ->access('view') permission check before returning the referenced entities and that globally.

At present we have core's 7.x branch set up to run automated tests with the following configs:

PHP 5.3 & MySQL 5.5
PHP 5.4 & MySQL 5.5
PHP 5.5 & MySQL 5.5
PHP 5.6 & MySQL 5.5
PHP 7.1 & MySQL 5.5
PHP 7.2 & MySQL 5.5
PHP 7 & MySQL 5.5 issue testing default

We need to review and update this.

For new versions of PHP and MySQL:

• When the branch passes under PHP 7.3 we should add that. See: #3012308: D7: Fully support PHP 7.3
• When the PHP 7.4 is released, and the branch passes we should add that. See: #3081386: [META] Fully support PHP 7.4
• When the branch passes with MySQL 8 we should add that. See: #2978575: Mysql 8 Support on Drupal 7

According to https://www.drupal.org/docs/7/system-requirements/php-requirements :

The minimum recommended PHP version for Drupal 7 is PHP 7.1.x (until it's official end-of-life at 1 Dec, 2019).

So we should update the issue testing default to PHP 7.1, and probably change that again to PHP 7.2 after 7.1's EOL.

According to https://www.php.net/supported-versions.php all versions of PHP 5 are now EOL, and so is PHP 7.0. Do we need to keep any of these enabled in our automated testing? Probably yes in at least some cases. For reference, D8 still has PHP 5.5, 5.6 and 7.0 enabled.

For MySQL, https://www.drupal.org/docs/7/system-requirements/database-server seems quite out-of-date for Drupal 7 - it mentions:

Drupal 7 supports MySQL 5.0.15/MySQL 5.1.30/MariaDB 5.1.44/Percona Server 5.1.70 or higher

https://en.wikipedia.org/wiki/MySQL#Release_history suggests that MySQL 5.5 is now EOL.

What versions of MySQL 5.x should we be testing against? D8 still has 5.5 enabled, but different branches also have combinations of 5.6 and 5.7 enabled.