To reproduce:

Make a site that has Content Type A with an entity reference field to Content Type B
Make some content that has this reference as a sample
Make a view that shows content of Type A
Add an exposed grouped filter on Content Type A's ER field to Content Type B
Fill in a few examples of Content type B as options for the grouped filter. Use the Type B nid as the value.
Save and look at the view on a page. You should see the following:

"Notice: Undefined index: value in Drupal\views\Plugin\views\filter\NumericFilter->acceptExposedInput()"

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
• Write a change record documenting all the BC notes in the issue for using js-cookie 2.2.1 directly rather than jquery.cookie.
• Write release note snippet

API changes

Yes, with backwards-compatibility layer.

Release notes snippet

TBD

Problem/Motivation

Packages were held back because of the older version of PHP should now be upgradable since we use PHP 7.2.

Proposed resolution

Upgrade all the packages we can.

Remaining tasks

Test all the things.

User interface changes

None.

API changes

None (hopefully).

Data model changes

None.

Release notes snippet

TBD.

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the internationalization modules: config_translation, content_translation, locale, language module(s).

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.

Hm. Perhaps I'm doing sth. wrong, but after upgrading a few sites to Drupal 8.8 I found that I cannot save newly translated nodes anymore. The error message is "Either the path '/node/[nid]' is invalid or you do not have access to it." where [nid] is of course the corresponding NID.

Steps to reproduce:

* Use sth. other than the administrator account. You should have the usual editor permissions to create nodes and create/update translations and translate any entity, of course. You should not have any url alias permissions.
* Create a new node in the original language (in my case: German)
* Save the node
* Edit the node again
* Click on translation, add translation (English)
* Try to save
=> Error.

I found that this error comes from "ValidPathConstraintValidator::validate". If I insert a return statement in the first line of that method, everything works as expected.

I don't have pathauto installed or sth. I *would* like to set/assign an automatic alias in a custom hook_node_presave, but the validation error seems to be trigged before this hook is even called. I checked pathauto and they are also using that hook to do their auto-path magic.

I don't understand the error message to be honest. Yes "/node/123" is of course not a valid alias, because it's reserved for the nodes. But I didn't assign anything. I don't even have permissions to assign any manual alias.

It used to work with 8.7 but not with 8.8.

Although max_execution_time is set to 300 in php.ini, its picking 240 because it's hardcoded in the core causing a fatal error.

In docroot/core/lib/Drupal/Core/Cron.php

// Try to allocate enough time to run all the hook_cron implementations.
Environment::setTimeLimit(240);

The time limit should be dynamic.

Every other media type provided by core has revisions enabled by default. I can only assume this is just a simple mistake unless someone has a reason this was done intentionally for Remote Video?

Just crash testing patches

Problem/Motivation

Queries generated by AliasStorage::preloadPathAlias() taking huge amount of time to execute. A good example is the /admin/content page which takes 10 seconds and more to load for around 75k nodes.

SQL-Query example below:

2018-07-24 11:02:11 NZST [4923-1] drupal-site@drupal-site LOG:  duration: 10990.918 ms  statement: SELECT url_alias.source AS source, url_alias.alias AS alias, langcode AS langcode, pid AS pid
        FROM 
        url_alias url_alias
        WHERE ((source::text ILIKE '/node/28') OR (source::text ILIKE '/node/29') OR (source::text ILIKE '/node/30') OR (source::text ILIKE '/node/31') OR (source::text ILIKE '/node/24') OR (source::text ILIKE '/node/25') OR (source::text ILIKE '/node/26') OR (source::text ILIKE '/node/27') OR (source::text ILIKE '/node/23') OR (source::text ILIKE '/node/211996') OR (source::text ILIKE '/user/13') OR (source::text ILIKE '/node/87382') OR (source::text ILIKE '/node/134983') OR (source::text ILIKE '/user/25222') OR (source::text ILIKE '/node/216888') OR (source::text ILIKE '/node/149705') OR (source::text ILIKE '/node/216524') OR (source::text ILIKE '/node/209767') OR (source::text ILIKE '/user/24341') OR (source::text ILIKE '/node/216536') OR (source::text ILIKE '/node/135065') OR (source::text ILIKE '/user/53277') OR (source::text ILIKE '/node/173142') OR (source::text ILIKE '/user/30085') OR (source::text ILIKE '/node/188349') OR (source::text ILIKE '/user/69670') OR (source::text ILIKE '/node/147160') OR (source::text ILIKE '/node/147245') OR (source::text ILIKE '/node/174863') OR (source::text ILIKE '/user/59491') OR (source::text ILIKE '/node/216527') OR (source::text ILIKE '/node/174530') OR (source::text ILIKE '/node/178984') OR (source::text ILIKE '/node/154121') OR (source::text ILIKE '/node/172192') OR (source::text ILIKE '/node/216869') OR (source::text ILIKE '/user/93926') OR (source::text ILIKE '/node/216876') OR (source::text ILIKE '/node/216881') OR (source::text ILIKE '/user/93929') OR (source::text ILIKE '/node/215571') OR (source::text ILIKE '/user/58627') OR (source::text ILIKE '/taxonomy/term/50463') OR (source::text ILIKE '/node/202776') OR (source::text ILIKE '/user/47599') OR (source::text ILIKE '/node/210401') OR (source::text ILIKE '/node/215338') OR (source::text ILIKE '/node/87208') OR (source::text ILIKE '/node/190312') OR (source::text ILIKE '/node') OR (source::text ILIKE '/user/1')) AND (langcode IN ('en', 'und'))
        ORDER BY langcode ASC NULLS FIRST, pid ASC NULLS FIRST

Not sure what part of Drupal this issue is actually coming from path alias or PostgreSQL driver.

Proposed resolution

1. Lower all existing aliases in url_aliases so that no ILIKE condition is required any more.
2. Make sure all new aliases are stored lowercase.

Remaining tasks

Finalize patch

User interface changes

None

API changes

Data model changes

Problem/Motivation

Adding an autocomplete field to an area styled by off-canvas.form.css causes illegible text due to inadequate contrast. Present using Firefox Quantum 69.0 (64-bit) and Google Chrome 77.0.3865.75 (Official Build) (64-bit) on Mac OS.

Steps to reproduce:

On a new Drupal install, create a custom block type with an autocomplete entity reference field, and add a custom block of that type to a new piece of content using layout builder.

Proposed resolution

edit off-canvas.form.css to add
background: #eee;
to
#drupal-off-canvas .ui-autocomplete li a {

as in:

Problem/Motivation

Using the autocomplete field widget in a block content type with layout builder is inaccessible due to a styling issue with the autocomplete results.

Steps to reproduce:
1) Add an entity reference field to a block type
2) Add that block type via Layout builder
3) Start typing in the ER field and view the resulting list.

Proposed resolution

Fix the styling
Check if this affects other widgets

Remaining tasks

User interface changes

Better UI for autocomplete dropdown in the off-canvas window.

Problem/Motivation

There is a d6 and d7 ValidateMigrationStateTest both of which use ValidateMigrationStateTestTrait::testMigrationState() but that actually checks both the d6 and d7 migration states whereas it should only do one. Plus the test will be a bit easier to read without the version index in all the arrays.

Proposed resolution

Get the legacy version from the source database.

Remaining tasks

Patch, review, commit.

Problem/Motivation

When using route:<nolink> the LinkGenerator class creates a <span> tag instead of an anchor tag which makes sense for certain scenarios, but it is not accessible if the non-link will have interactivity added to it via JavaScript. It would be beneficial to have the option to use the semantically-correct <button> HTML tag here for such cases.

Proposed resolution

Since the only way to modify the HTML tag is through a special route (demonstrated by route:<nolink>), it would appear a new special route is required for this use case: route:<button>

Remaining tasks

User interface changes

API changes

None: If someone defined a <button> route it would break, but that is unlikely. Also, when route:<nolink> was added there was not a corresponding change record.

Data model changes

Problem/Motivation

The 7.x Date module allowed the field to has an optional or required end date. D8 requires the end date always.

Proposed resolution

Make end_value in DateRangeItem optional, add validation constraint via configuration.

Remaining tasks

1. Add tests for formatters (and probably widgets). (See #75.)
2. Add missing match limit to test code. (See #81.)
3. If the start date is missing, stop deleting the end date on saving the form. (See #84.)
4. If missing, indicate that the end date is unknown/unspecified on display. (See #84.)

User interface changes

API changes

Data model changes

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the search module(s).

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.

Problem/Motivation

The use of HTML5 "required" attribute in D8 has resulted in an accessibility regression. Basic client-side validation now occurs *before* hitting the server and running FAPI validation functions, so the browser jumps in and provides an error as you attempt to submit the form.

In Drupal 7, the FAPI error messages include a) an icon + alt tag to indicate their relative importance (e.g. warning/notice), b) an error message which included the name of the field for reference, c) a red outline on the field.

But in D8, those enhanced error messages are never displayed, in favor of the default browser response to a required field, which in Chrome's case is "Please fill out this field," without any mention of which field is referred to.

Proposed resolution

The accessibility team's goal for form validation is #1493324: Inline form errors for accessibility and UX. HTML5 best practices are:

1. Javascript validation first
2. HTML5 validation for no-Javascript
3. Server-side validation

Implementing Javascript validation before the HTML5 validation would restore accessibility for most users. A proposed patch changing the error message to "SomeFormField is required" would improve accessibility for those without Javascript.

Related Issues

#1696648: [META] Untie content entity validation from form validation
#742344: Allow forms to set custom validation error messages on required fields
#1845546: Implement validation for the TypedData API

Original report by mgifford

I was very surprised to see that in D8 that we've lost some accessibility in the current release as far as how error messages are presented.

They were much better in D7. In D8 they just say "Please fill out this field.", where in D7 there was a red box describing the problem at the top of the page. The error also had an image and text which identified what exactly the problem was.

Ultimately we need this in core #742344: Allow forms to set custom validation error messages on required fields

But the defaults for D8 should be at least as good as they were in D7.

Problem/Motivation

As stated in #3050389: Remove dependency to Classy from core themes, Classy will be moved to contrib before Drupal 9 and we have to remove dependencies on Classy from all core themes.

Part of this process includes creating theme-specific copies of all Classy libraries to core themes. This ensures Classy can be removed without impacting those themes.

Because this is the first of several issues for copying a Classy library to Umami, there are no tests for this yet.

Also because this is the first of several similar issues, this will also be used to collect feedback about the process and naming conventions, with the goal of making the additional issues as easy as possible to patch and review.

Proposed resolution

• Make an Umami-specific copy of classy/dropbutton This includes:
  • The library should be called classy.dropbutton, using the classy. prefix to make it clear that it is copied from Classy, not custom to Umami
  • Umami should extend core/drupal.dropbuttonso the end result behaves identically to Classy's extending of the library.
  • The CSS file will be located in css/classy/components. As a rule, copied assets from Classy should go in a classy subdirectory of that asset type, but otherwise maintain the directory structure from classy (such as going in a components or theme directory)
• Add a test class that confirms the copy is successful, and build it so it is easily capable of testing other libraries when they are copied to a theme that previously depended on the Classy library.
• Manually test in Umami by comparing elements that use the dropbutton css before-patch and after-patch, and provide screenshots.

Remaining tasks

Currently all the steps above.

User interface changes

no

API changes

no

Data model changes

no

Release notes snippet

...

Problem/Motivation

Upgrading a Composer plugin can be an error-prone operation. If the Plugin class instantiates objects (or, more specifically, loads classes) in the `activate` method (or any pre-command hook), and those classes are updated as part of a `composer update` operation, then the old version of the code loaded in `activate` will continue to be used in the post-update hooks, whereas in contrast, classes loaded after the update will be loaded from the new code. This can cause old versions of the classes that were pre-loaded attempt to use methods that no longer exist, e.g. if things are removed. If new versions of the classes have references back to the older (pre-loaded) classes, then errors could be thrown if methods that did not previously exist are called.

Proposed resolution

In the Scaffold plugin, avoid instantiating objects in the `activate` hook, and add a test that confirms whether an upgrade from the Scaffold plugin version 8.8.0 to the current code under test (e.g. in the current patch) works.

The ProjectMessage plugin is already written in a way that makes it resilient against changes. Consider opening a follow-on issue to add a test protecting ProjectMessage from future changes that might alter this.

The VendorHardening plugin has both pre and post hooks, so it would be difficult to protect it by lazy-loading objects. There are not many objects in this plugin, though, so it might be possible to protect it by pre-loading all classes in `activate`. The objects that exist have a simple API, though, so it is less likely that they will need to change. Consider opening a follow-on issue to add a test protecting VendorHardening from future changes that might alter this.

Remaining tasks

Not sure.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

Probably not needed.

Problem/Motivation

When submitting a views exposed form that uses the FieldOrLanguageJoin plugin (as set here) an invalid SQL is produced, e.g.

media__field_tags.langcode = .langcode

This happens because ViewsQueryAlter::alterQueryForEntityType sets the leftTable property of a join plugin to null. This works for simple cases but breaks when the plugin uses a left_field in $join->extra.

Proposed resolution

First, make it possible to set the left_table property separately for each of the $join->extra entries (tracked in #3104598: JoinPluginBase::buildExtra breaks when left_field is a formula).

Once it's possible, scan the extra items and preserve the left_table value.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

Submitting the exposed forms of views that use the FieldOrLanguageJoin plugin no longer breaks the SQL query.

Problem/Motivation

In Drupal 8.5 menu editing has regressed because if you add a menu link from this form you are redirected back to the menu list form. It is very jarring. This is a regression from the 8.4.x behaviour introduced by #2767857: Add destination to edit, delete, enable, disable links in entity list builders.

Steps to reproduce the issue:

1. Install standard and login
2. Go to admin/structure/menu
3. Click on any edit menu
4. Click on add link
5. Fill out the add link form and press save

You should be back at the menu with its list of links but actually you're back at the list of menus.

Proposed resolution

Remove the destination as we did in #2940165: [regression] Cannot add effects to image style via the UI

Remaining tasks

Add a test

User interface changes

The destination is removed from the links on admin/structure/menu

API changes

None

Data model changes

None