Problem/Motivation

Symfony stuff:

symfony/* v3.4.14 v3.4.15            Symfony components
symfony/polyfill-* v1.8.0  v1.9.0             Symfony polyfills

Other stuff:

guzzlehttp/guzzle         6.3.0   6.3.3   Guzzle is a PHP HTTP client library
paragonie/random_compat   v2.0.11 v2.0.17 PHP 5.x polyfill for random_bytes() and random_int() from PHP 7
twig/twig                 v1.35.3 v1.35.4 Twig, the flexible, fast, and secure template language for PHP

Proposed resolution

Update these packages.

Remaining tasks

Review.

User interface changes

None

API changes

None

Data model changes

None

https://www.drupal.org/node/2941566

contributed and custom project maintainers are encouraged to keep up with core deprecations each minor release, so that the work to make projects compatible with the next major release will be minimal.

It means contrib maintainers are encouraged to remove usage of deprecated code, but Drupal core is not doing it.
Code inspection of the core folder for Drupal 8.5.0-rc1 found 19175 warnings where deprecated code is used. This is unacceptable.
If we really want to convince anyone that continuous upgrades for Drupal is a real thing, then this problem must be fixed.
Contrib maintainers do not care about deprecations when core looks like this. D9 (the next Drupal major release) will just break almost all the contrib, and continuous upgrades will be mentioned as "it was a nice idea"..

My proposal is to do not release Drupal 8.6 until there is 0 usage of deprecated code.

Problem/Motivation

I had a WSOD problem on a page showing many view results, because of too many cache tags in header (see #2952277: Minify the cache tags sent in the header for why it can be a problem when cache tags are needed on production environment). When looking at the cache tags, I saw many "node:42", "node:43",... tags, and the "node_list" tag.
You can reproduce this on a fresh install by showing the cache tags in headers ($settings['container_yamls'][] = DRUPAL_ROOT . '/sites/development.services.yml';), creating a few nodes and checking the headers of the front page.

I might be all wrong but as I understand it, a cache tag is here to fire invalidation if some event occurs:
- the entity cache tag such as node:42 triggers invalidation if the node 42 is edited or deleted
- the entity list cache tag such as node_list triggers invalidation if any entity of the given type is created, edited or deleted
Which means that any event triggering node:42 invalidation will also trigger node_list invalidation, so that node:42 is a useless tag if node_list is here. Right? I could not find any discussion about this, but it might have been thought long ago, so tell me if I'm wrong!

Proposed resolution

If I'm right, I guess we could remove individual cache tags in Cache::mergeTags() if the corresponding list cache tag is here. This would lead to very shorter cache tags headers, and it might improve performance in some way, because of a simpler cache info.
I'm still wondering if the check would have a negative impact on performance though, and I don't know if removing individual entity cache tags early in the process would not lead to bugs because they would be expected by some other code even if the node_list tag is set.
Then another solution would be to remove the useless cache tags at the very end, just to not put them in the headers. At the moment I don't know if this could/should be done in a contrib module or if it would be better in core.

Remaining tasks

* Ensure that this simplification is a right thing to do, or close this issue otherwise (and sorry for the lost time!)
* Agree on the best way to do it, do some performance tests.
* Do it.

User interface changes

None. Developers might wonder why their node:42 tag does not appear anymore though.

API changes

None?

Data model changes

None?

Focusable elements across the site have these various focus style scenarios

1. default browser focus style only
2. default plus Umami focus styles
3. Umami successfully overriding default focus styles

	Mac OS - Safari	Windows - Edge
Skip link
Menu - active
Menu - not active
Umami logo
Search field
Search submit button
Log in link
Banner top button
Article card - image
Article card - title
Article card - view more
Recipe card - small - image
Recipe card - small - title
Recipe card - small - view more
Recipe card - large - image
Recipe card - large - title
Recipe card - large - view more
Footer links
Breadcrumb
Tags

Pages tested

<front>
/articles
/articles/give-it-a-go-and-grow-your-own-herbs
/recipes
/recipes/super-easy-vegetarian-pasta-bake

Most of the images are from the home page. Components that appear to be re-used are only included once – this includes the cards on the collection pages (/articles and /recipes).

Elements which have two focus states (default and Umami)

*names and screenshots*

Elements which do not have Umami theme focus states

*names and screenshots*

The default focus style on Firefox is a dashed line which is weak (stated in this issue as stated here https://www.drupal.org/project/drupal/issues/2942506 (the problem is when the thin dark outline directly abuts a dark image).

Chrome's is a thick blue line which doesn't always look great (off-centered, a side cut off the border, etc), and fails doesn't satisfy WCAG SC 1.4.11 Non-text contrast against the grey footer.

Proposed solution

- Carry on down the road of using focus styles from the theme?
- overriding the default selector and styles that browsers use to set their styling ie. :focus ?

Problem/Motivation

Plugin derivers are essentially a foreach loop for providing plugin definitions.
Typically they iterate over the result of some other service, creating a definition for each item.
If that list of items changes, the plugin definition cache must be cleared so that the deriver can accurately reflect the up-to-date list.

In practice, this has meant that another piece of code, like a hook implementation, will manually clear the plugin definition cache.

For example, \Drupal\system\Plugin\Derivative\SystemMenuBlock loops over all menu entities to provide menu blocks.
\Drupal\system\Entity\Menu::save() and \Drupal\system\Entity\Menu::delete() are then responsible for clearing the block plugin definition cache.

Proposed resolution

Plugin managers already support the use of cache tags for their definitions cache.
Allow the derivers themselves to affect the list of cache tags used.
This will remove the need for external code (like a hook) to clear the cache.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Layout Builder's block listing is not filterable, which makes it hard to quickly find the block you're looking for.

Proposed resolution

We should add a filter for the block listing similar to the core one at /admin/structure/block.

Remaining tasks

Write a patch.

User interface changes

A filter will be added to the Layout Builder block listing.

API changes

None.

Data model changes

None.

Is this cool for me to do?

When the layout_builder module is enabled, trying to view a term page crashes with:

Drupal\Component\Plugin\Exception\ContextException: Assigned contexts were not satisfied: entity in Drupal\Core\Plugin\Context\ContextHandler->applyContextMapping() (line 101 of /var/www/html/web/core/lib/Drupal/Core/Plugin/Context/ContextHandler.php).

Steps to reproduce

1. Activate layout_builder
2. Create a vocabulary and term
3. View the term page

Problem/Motivation

When accessing Layout Builder overrides via REST (i.e. when accessing an overridden entity's layout field), the contents of sections appear empty.

Proposed resolution

We should add a normalizer for the layout_section DataType, which ensures that sections can be properly serialized and unserialized via the serialization API (and REST).

Remaining tasks

Write a patch, possibly discuss what setting (unserializing) sections looks like via an API like REST.

User interface changes

None.

API changes

A new normalizer will be added for the layout_section DataType.

Data model changes

None.

Problem/Motivation

This is easily reproducible on simplytest.me:

1. Install Drupal w/ standard profile
2. Add an article node with garbage info
3. Create a view with base table of Content Revisions, displaying fields.
4. Add field "Tags" under category "Content (historical data)"
5. In settings for that field, rewrite the field using "Override the output of this field with custom text" (actually doesn't matter what you pick, you just need something that exposes the replacement tokens)
6. Observe that the replacement token for that field contains a hyphen: "{{ field_tags-revision_id__target_id }}"

Before

The problem is that you cannot have hyphens in twig variables like that. I believe it should be two underscores instead based on what I've seen in some other issues.

Proposed resolution

- Use the field alias instead, but don't break things that use field name in the view.
- Views post-update.
- Write a test to assert the problem.

After

Remaining tasks

- Add upgrade path test to assert that view config created before the patch is properly updated after the patch per @alexpott's review. @InterX mentions a good start to this in comment #35.
- Change the post-update so that it uses Batch API for scalability per @alexpott's review.

Completed

- Patch #25 with views post-update, fix and test to assert the issue.
- Manual testing (DONE): Add Before/After screenshots.

Original report by bkosborne

This causes a couple issues:

1. There's an assertion in PluginBase::viewsTokenReplace() that checks if tokens are valid twig variables. So if the token replacement is performed for whatever reason, this assertion will fail and cause a 500 error.
2. I believe this would also prevent twig from performing the replacement correctly and/or using the proper field template for the field, but I can't be sure because I didn't test that behavior. The replacement token replaces the string 0 or 1, but not the actual value for the field.

I did a little big of digging and see that the token name for a given field is literally the "id" of the field, see FieldPluginBase::getFieldTokenPlaceholder(). Not sure on the solution here since I'm completely unfamiliar with this code.

Hi,

I need some help to characterize this issue, i try to figure out what is going bad in Drupal as our hosting provider OVH doesn't help on site management.
I see this kind of message since last night but people said site crashed in the afternoon.
[Thu Sep 20 02:41:51 2018] [error] [client ****] [host ****] AH10039: FastCGI: server "/homez.105/****/www/docroot/index.php" stderr: PHP message: PDOException: SQLSTATE[HY000] [1203] User **** already has more than 'max_user_connections' active connections in /home/****/www/docroot/core/lib/Drupal/Component/DependencyInjection/PhpArrayContainer.php on line 79 #0 /home/****/www/docroot/core/lib/Drupal/Core/Database/Driver/mysql/Connection.php(149): PDO->__construct('mysql:host=ll21...', '****', '****', Array)
Is it a clue for someone?

Best regards,

Gilles

When using an autocomplete widget, Drupal adds the entityID in brackets after the entity name. The entityID is unique, but the text label for that entity may not be, so adding the ID ensures the user will choose the "right" thing and that the "right" thing gets passed back to Drupal.

People often ask why this number in brackets is here, or wonder what it means, or assume it's something else. Some people ask for it to be removed. This has happened to me on four different projects, and now I search for it, it would seem I'm not alone.

"users on my site have been asking me what the number in brackets mean and getting confused by it." - joachim 5 Oct 2012

"I would be very interested in this as I am worried the [nid: 34] style appendage might be unfriendly for some users, and it certainly seems like we need a different solution." - danielb 17 Oct 2008

"one problem for my users is that they are not in the habit of seeing node/entity ID's, so this number in parentheses is confusing when they see it in the autocomplete list of suggested matches." - lucyp 9 Dec 2014

Shall we see if we can fix it?

It seems like such a little thing but it adds up over time, and it's poor UX from core, with many contrib attempts to work around it.

Here are some of the suggested work arounds:

1. Hide it with javascript
2. Use views instead
3. Use one of these modules:
   • https://www.drupal.org/project/chosen
   • https://drupal.org/project/chosen_ajax
   • https://www.drupal.org/project/select2
   • http://drupal.org/project/autocomplete_deluxe
   • https://www.drupal.org/project/nodereference_nid_trim

Core issues

* #322383: Autocomplete nid/vid extraction. i.e. CCK Nodereference
* #365241: Add select event to autocomplete feature
* #2537512: uid in the user autocomplete is confusing

Support requests

* Alter Node Reference Autocomplete Output - https://www.drupal.org/node/364768
* Can I remove [nid:n] in node reference fields? - https://www.drupal.org/node/487554
* Best way to get the uid from user in ajax autocomplete - https://www.drupal.org/node/2845850

Stack overflow
* https://stackoverflow.com/questions/1515722/removing-nidn-in-nodereferen...

Stack exchange
* https://drupal.stackexchange.com/questions/200498/hide-the-term-id-on-au...
* https://drupal.stackexchange.com/questions/146983/how-can-i-hide-the-ent...
* https://drupal.stackexchange.com/questions/227954/how-to-remove-taxonomy...

Contrib

Entity Reference (https://www.drupal.org/project/entityreference)

* #1802916: Add option to autocomplete widget to hide entity ID
* #1743342: Remove brackets (id) from display?
* #1411304: Autocomplete hide id options for use with unique labels

Other contrib issues

* #2389317: UX: how to hide entity ID from autocomplete list
* #2400015: When editing an existing entity with entityreference autocomplete fields, load the views dropdowns in Select2 or remove the parenthesised numbers
* #640832: Remove [nid:n] in nodereference fields, so only title is shown
* #157545: Have [nid:n] hidden from user
* #2179861: How To Hide The Term ID After the Term
* #2291575: How the entity id is handled on submission?

(note: Should this be forms system or entity system? Going with forms for now. But entity seems equally likely)

Problem/Motivation

I am marking this as a bug in the documentation as without this the Id documentation for the CKEditorPlugin is incomplete and redundant.

Currently the only doc string for the core/modules/ckeditor/src/Annotation/CKEditorPlugin.php CKEditorPlugin.id is "The plugin ID."

This has two problems.

1. It uses "ID" when it should be "Id"
2. It is completely useless and redundant because the attribute name is "id" so it is obvious that we are defining an Id

Proposed resolution

There are actually some requirements for this attribute so we should have some documentation that points that out. I opened #3000962: [upstream] Improve JS error when a @CKEditorPlugin PHP plugin ID doesn't match the JS CKEditor plugin name to attempt to improve the errors that happen if this attribute isn't set correctly, but it also should be mentioned in the docs what those requirements are. As far as I know the only requirement is that the Id matches name declared to CKEditor in the JS.

Remaining tasks

Write doc patch.

User interface changes

none

API changes

none

Data model changes

none

Problem/Motivation

Currently if a developer creates a plugin for a ckeditor plugin and the CKEditorPlugin.id and the name of the plugin as it is called in the Javascript don't match then they are met with this very un-useful error.

ckeditor.js?v=4.8.0+2018-04-18-security-patch:242 Uncaught TypeError: Cannot read property 'icons' of null

Proposed resolution

Make this error more useful. I am not really sure what the working should be, but I know that this isn't doing anyone any good.

This might also be an upstream issue.

Remaining tasks

Come up with better wording.
Find way to display this error to the use.

User interface changes

API changes

Data model changes

Problem/Motivation

format_size() is still a procedural function, while it can be turned into a static method in an utility class.

Proposed resolution

• Add a ::toUnitAndSizesize calculation method to the \Component\Utility\Bytes class.
• Convert format_size() to OO code, using the new method provided in \Component\Utility\Bytes::toUnitAndSize class.
• Add related PHP unit tests.

Remaining tasks

• reviews

User interface changes

none

API changes

• Add a Bytes::toUnitAndSize() method to return separately a unit of measurement and the size expressed in the unit of measurement, given a byte quantity.
• Add a Bytes class in \Drupal\Core\Utility, extending from \Drupal\Component\Utility\Bytes, with a toTranslatableString method where we call Bytes::toUnitAndSize() and format the size string.
• Refactor format_size() to use Bytes::toTranslatableString().
• format_size() is deprecated.

Problem/Motivation

When applying the telephone link field formatter on number with 5 digits or less, Drupal miserably breaks, displaying some kind of WSOD with the following message: "The website encountered an unexpected error. Please try again later". Another message can be then found in the watchdog: InvalidArgumentException: The URI 'tel:112' is invalid. You must use a valid URI scheme. in Drupal\Core\Url::fromUri() (line 301 of /media/alex/4126b75c-86e8-4b12-a7c2-08e2d7dbfb08/alex/201310/drupal/core/lib/Drupal/Core/Url.php).

Steps to reproduce

• Create a content type with a telephone field.
• In the "Manage Display" page, choose the "Telephone link" field formatter for this field.
• Create a node of that content type with "123" as value of this field.
• The exception is thrown when the page is displayed.

Cause

The bug occurs in the parse_url PHP function, which processes numbers with 5 digits or less like TCP ports.

Proposed resolution

• Not allowing numbers with 5 digits or less: however, short numbers do exist, like emergency numbers, internal numbers, etc.
• We might have to deal with these numbers differently, though: are there specifications about this?
• Writing our own function, instead of the parse_url PHP function.
• Use a tiny hack to force parse_url to behave as expected. (add an empty query string at the end of the uri)

The underlying parse_url PHP function problem can be managed in a follow up issue. See https://www.drupal.org/node/2575577

Remaining tasks

User interface changes

None.

API changes

None.

Data model changes

None.

When trying to load a translation for a language not provided in the current revision of an entity you are met with the following fatal error.

Uncaught exception 'Error' with message 'Call to a member function wasDefaultRevision() on null'
in /docroot/core/modules/content_moderation/src/ModerationInformation.php

$latest_revision_id is null because $storage->getLatestTranslationAffectedRevisionId returns null if no revision affecting the specified translation could be found

The attached patch only changes the following:
if ($latest_revision_id != $default_revision_id) {
to
if ($latest_revision_id != $default_revision_id && $latest_revision_id != '') {
in core/modules/content_moderation/src/ModerationInformation.php

This blocks #2571235: [regression] Roles should depend on objects that are building the granted permissions and hence at least a major because it is blocking a critical.

Problem/Motivation

Profiles can override configuration used in an install. For example, a profile can provide a user.role.anonymous that is used instead of the one in user/config/install. This works fine at the moment because user roles have no dependencies. But #2571235: [regression] Roles should depend on objects that are building the granted permissions will break this because that adds them and as user is installed right after system there is no way this can work without causing an \Drupal\Core\Config\UnmetDependenciesException error. This behaviour is tested in \Drupal\config\Tests\ConfigInstallProfileUnmetDependenciesTest.

Proposed resolution

This is not an ideal situation as it means we can't really add any new dependency information without breaking install profiles that do this. According to @Berdir we've done this several time over the 8.x dev cycle.

Maybe instead of replacing the configuration we can just install the configuration from the module and then when the install profile is instead we can update the configuration entity instead.

Remaining tasks

User interface changes

None.

API changes

None.

Data model changes

None.

In Drupal core, there is a single permission 'administer users' that controls whether a user can 'administer' the user account of another user. However the Drupal 8 Entity API makes it possible to refine the access, for example by means of hook_entity_access. This allows modules such as Administer Users by Role to create a "sub-admin" - a user without 'administer users' permissions that nevertheless has access to update some other users' account.

Drupal allows an admin with permission 'administer users' to create/edit/cancel a user with a blank email address. However there is no easy way for a site to extend that permission to a sub-admin. That means that a sub-admin cannot even edit or cancel an account with blank email address unless they set a value for the field.

We should provide a hook to alter permission to assign a blank email address. A secondary use of the hook is so a site can have a policy that blank emails are not allowed, even for a full admin.