Steps to recreate:

- Create an AJAX enabled view with exposed filters (as drop down), enable the reset button
- Create a page and place the view as a block on the page.
- Load the view page - no reset button
- Click filter submit button
- Reset button appears
- Click Reset button

- The page is redirected to a system/404

Problem/Motivation

In order to be able to do #2982680: Add composer-ready project templates to Drupal core., it is first necessary to provide a list of scaffold files in the drupal/core project. This will allow the Scaffold component from #2982684: Add a composer scaffolding plugin to core to move all of the "scaffold" files (index.php et. al.) thus provided to their original location so that a project based on the subtree split of drupal/core may still assemble a complete and functional Drupal site.

Proposed resolution

This patch creates duplicate copies of every scaffold file. Each file remains in its original location, and will be used there by drupal/drupal (Drupal core development) and also by sites based off of the drupal-composer/drupal-project template. Each file will additionally have a copy in a new location, core/assets/scaffold. The original locations for each of the scaffold files will be considered deprecated by this issue, and will be removed in Drupal 9. To ensure that no mistake is made during the remainder of the Drupal 8.8.x cycle, unit tests will be added to compare the contents of each copy of the scaffold files, and throw an error if someone makes a change in just one location.

Remaining tasks

• Update patch.
• Write change record.
• Identify documentation that needs to change and update it.

Follow-on Tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

The Drupal "scaffold" files (index.php and so on) now exist in two locations: core/assets/scaffold, for use by the Drupal Composer Scaffold plugin, and their original location, used in Drupal Core development, and with downloaded copies of Drupal. Any change made to one of these files will need to be made to both locations.

The list of all scaffold files is:

• .csslintrc
• .editorconfig
• .eslintignore
• .eslintrc.json
• .gitattributes
• .ht.router.php
• .htaccess
• INSTALL.txt
• README.txt
• example.gitignore
• index.php
• robots.txt
• update.php
• web.config
• modules/README.txt
• profiles/README.txt
• themes/README.txt

Problem/Motivation

Since this is now a separate interface, the return type is wrong. Possibly should've been $this all along? Also it needs a reference to EntityRepositoryInterface::getTranslationFromContext

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Steps to Reproduce -

1. Admin sends invite to user by assigning role and notifying user to through an email
2. User will receive an email on his email address with one time link to log in to the site
3. User have to click on 'Log in' button on first screen
4. Now on next screen, user will have 'password' and 'confirm password' fields , but if user clicks 'Save' button without entering 'password' and 'confirm password', drupal allows to save the form as the fields are not mandatory

Actual Result - Password and confirm password are not mandatory fields while setting up password using one time link following by email. This misguides user at UX and functionality level.

Expected Result - When user follows one time link to set the password, 'Password' and 'Confirm Password' fields should be mandatory fields.

Updated: Comment #28

Problem/Motivation

The minimum password length is currently 1 character. This not good from a security point of view.

Conversation goes on to say minimum password length should be Configurable and discusses where the settings should be kept.

Proposed resolution

Propose to have minimum password length as a per site configurable value.

Remaining tasks

1) Add 'Minimum Password Length' setting to some form. Probably the Configuration > People > Accounts form.
2) Change JS behaviour to implement this setting.
3) Check minimum length when the entity is created, not on user form validation or on the password element, as we want to cover situations when a user is created via the form or API but we don't want to force this when the password element is utilized - although it would be nice to have as a configurable property for the element.
4) Backport to D7 if possible.

User interface changes

New setting on the Configure > People > Accounts form which specified 'Minimum Password Length' (user.settings.yml - core/modules/user/config/user.settings.yml)

Original report by Tsalop

When user types new password - password can be only 1 letter long.
So I suggest a check that the password is at least 4 characters long....

Problem/Motivation

WS-2018-0072 high severity
Vulnerable versions:< 2.2.0
Patched version: 2.2.0
Versions of https-proxy-agent before 2.2.0 are vulnerable to a denial of service. This is due to unsanitized options (proxy.auth) being passed to Buffer().

As per @lauriii this can be fixed publically.

it could be public because it only affects our development tooling, and it’s also already public information since its in a 3rd party dependency

Proposed resolution

Update the yarn package.

Remaining tasks

Create a patch

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

TBC

I was trying to do this:

// Create a file in '/tmp/some-path'.
$file = drupal_tempnam('temporary://some-path', 'prefix');

But the returned filename will always reside in the base directory of the 'temporary' wrapper, because the implementation of drupal_tempnam uses the wrappers getDirectoryPath method, which basically returns the root of the filesystem represented by the wrapper.

Is this on purpose? Or a bug that needs fixing?
If the former, the docs need changing.

Problem/Motivation

There are a number of TwigLoader interfaces and methods that have been deprecated in Twig 1.x and need to be removed in Twig 2.x.

Proposed resolution

Remove deprecated interfaces and methods, replacing them with equivilents if possible.

Remaining tasks

TBD

User interface changes

None

API changes

None, aside from removing what isn't supported in Twig 2.x.

Data model changes

None

Release notes snippet

TBD

Problem/Motivation

The default action on /admin/content is "Delete selected content". It's really easy to push "Apply" button by mistake, thinking it will apply the filter, because of the button title, and because it's positioned at the bottom of the form, typically where people expect to look for submit buttons. (This actually happened to me today, and I've been using Drupal for 8 years.)

Proposed resolution

• Use the D7 sort order (#3)
• Make the default action something safer (or make the default a no-op).
• Change the "Apply" button back to "Update" (like D7), "Execute", or even something action specific ("Delete").

Proposed alternatives

Alternatives for order of operations. The first operation in a list is the default.

Alternative 1: D7-like

• Publish content
• Unpublish content
• Promote content to front page
• Remove content from front page
• Make content sticky
• Make content unsticky
• Delete content
• Save content

Variation: Unpublish as default, by swapping Publish and Unpublish. This has the same Cons. For consistency the other operation pairs should also be swapped.

Alternative 2: Safe default

• - None -
• Publish content
• Unpublish content
• Delete content
• Save content
• Promote content to front page
• Remove content from front page
• Make content sticky
• Make content unsticky

Variation: Place Delete and Save at the bottom of the list as in D7.

Alternative 3: Safe first

• Make content sticky
• Make content unsticky
• Promote content to front page
• Remove content from front page
• Publish content
• Unpublish content
• Delete content
• Save content

Variation: Use Promote/Demote as first operation pair.

Remaining tasks

• Implement the suggestion in Comment #75
• Fix the failing tests: see Comment #72
• Make follow-up to delete the Save content option

User interface changes

Yes!

API changes

N/A

Problem/Motivation

      @trigger_error('Automatically creating the first item for computed fields is deprecated in Drupal 8.5.x and will be removed before Drupal 9.0.0. Use \Drupal\Core\TypedData\ComputedItemListTrait instead.', E_USER_DEPRECATED);

\Drupal\Core\TypedData\Plugin\DataType\ItemList::get() should include field name/entity type or so in the message, because it's pretty annoying to even track down right now what is causing it.

Proposed resolution

Add more context.

Remaining tasks

Do it!

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

I added my theme css using the following in the *.info.yml:

ckeditor_stylesheets:
  - css/style.css

While updating the css/style.css I found that my changes wasn't reflecting into the WYSIWYG editor. Watching at the html head of the editor iframe I found that my css file was include as follow:

<link type="text/css" rel="stylesheet" href="/my_project/docroot/themes/unepmap/css/style.css">

That is, the above isn't included with any cache busting as any of the other css includes!?...

Now, not sure what is supposed to do CKEDITOR.timestamp included in #2679903: CKEditor uses separate cache-busting query string from Drupal's but it doesn't seems to cover the the above...

Problem/Motivation

The migration system has no support for migrating node reference fields, with their settings and values, from Drupal 7 to Drupal 8.
The source module is https://www.drupal.org/project/references.

Proposed resolution

Add a field plugin to handle Drupal 7 node reference fields.

Remaining tasks

• Write the field plugin
• Write tests of said plugin
• Update the Drupal 7 fixture with a node reference field or two
• Update our integration tests to ensure that the node reference fields and their configurations are migrated correctly
• Update other integration tests to ensure that node reference fields' values are migrated properly
• Commit the patch
• Jump into a ball pit and roll around happily

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

With the release of Symfony 4.3 the event dispatching changed: https://symfony.com/blog/new-in-symfony-4-3-simpler-event-dispatching
This already causes issues for drupal regarding the upgrade to Symfony 4.x or 5, for example in
#3055194: [Symfony 5] The signature of the "Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher::dispatch()" method should be updated to "dispatch($event, string $eventName = null)", not doing so is deprecated since Symfony 4.3. and #3055180: [META] Make Drupal 8 work with Symfony 5 (along with Symfony 3 and 4).

But Drupal isn't the only system that has to deal with that. Third party libraries drupal leverages directly or via contributed modules need to adapt to this change. Therefore the symfony project itself provides a migration path by decorating the event dispatcher with LegacyEventDispatcherProxy as described in blog post linked above.

This LegacyEventDispatcherProxy has been released as part of symfony/event-dispatcher 4.3.0.
The event-dispatcher has no dependency to any 4.3 versions of other symfony components but is backward compatible to symfony 3.4 which we use in Drupal 8:

"require-dev": {
        "symfony/dependency-injection": "~3.4|~4.0",
        "symfony/expression-language": "~3.4|~4.0",
        "symfony/config": "~3.4|~4.0",
        "symfony/http-foundation": "^3.4|^4.0",
        "symfony/service-contracts": "^1.1",
        "symfony/stopwatch": "~3.4|~4.0",
        "psr/log": "~1.0"
    },
"conflict": {
        "symfony/dependency-injection": "<3.4"
    },

See https://github.com/symfony/event-dispatcher/blob/4.3/composer.json

But no matter how we deal with the migration within the Drupal project, we already have a critical issue.
As an example, the upcoming 5.1.0 release of the solarium library implements the migration path as recommended by the symfony project:
https://github.com/solariumphp/solarium/pull/690

This library is required by the search_api_solr module that has more than 14,000 active 8.x installations already. search_api_solr injects the Drupal event dispatcher into the solarium Solr Client.

From my point that works perfectly fine. But Drupal prohibits the update because of this version constraint:
"symfony/event-dispatcher": "~3.4.0",

This version constraint is simply wrong as Drupal doesn't use the event dispatcher provided by this module but only it's EventDispatcherInterface which has been kept compatible in symfony 4.x.

So the current situation is that Drupal blocks feature and security updates of third party libraries which use symfony event dispatching and adopting to symfony event dispatching changes in the proposed and compatible way. That has to be considered as critical.

Proposed resolution

Adjust the version requirement like this:
"symfony/event-dispatcher": "~3.4.0|~4.0"
Afterwards composer will resolve the correct combination of module versions without upgrading the other symfony components at all.
Drupal will still use 3.4.

Remaining tasks

Just apply the patch.
The (failing) test result of https://www.drupal.org/project/drupal/issues/3055194#comment-13221924 already proves that drupal will work perfectly fine with symfony/event-dispatcher:4.3

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Todo, maybe not required at all.

Looks like it was missed in #2003330: Rename Views method render_items() to renderItems().

Remaining tasks

Notify this change to contrib modules as we can by creating new issues.

• Created one for search_api module #3074732: Rename Views method render_item() to renderItem()

Problem/Motivation

In #2962525: Create a field widget for the Media library module, the media edit/view link was disabled in the field widget and widget view in order to prevent unintended data loss. Long term, we would still like the ability to quickly edit media items from the field widget, without navigating to a new page.

Proposed resolution

Allow media items to be edited in a modal while using the field widget. The Entity Browser module allows for similar functionality.

Remaining tasks

Write a patch, discuss scope.

User interface changes

Undecided.

API changes

None.

Data model changes

None.

Problem/Motivation

Cache of entities are not invalidated when the entity label changes.

Steps to reproduce for nodes & breadcrumbs (from #3):

1. Create a node with title 'Title A'.
2. Change the title to 'Title B' and check the 'Create new revision'.
3. Open the Revisions tab > Breadcrumb shows the right title (Title B).
4. Change the title to 'Title C' and check the 'Create new revision'.
5. Open the Revisions tab.

Expected: The title in the breadcrumb is 'Title C'.
Actual: the title in the breadcrumb is 'Title B'.

Steps to reproduce for users (from #48):

1. 1. Log in
2. 2. Edit your username and save.
3. 3. Return to the edit screen for your user account.

Expected: Breadcrumb shows your new username
Actual: You'll see your old username is still utilised in the breadcrumb.

Proposed resolution

Allow attaching cacheability metadata to titles with a new CacheableTitleResolverInterface that returns a static or dynamic title (with cacheable metadata).

Problem/Motivation

In reviewing #2994702: Allow editors to alter embed-specific metadata, as well as `data-align` and `data-caption`, the UX team had this feedback about the "remove" button that appears for each embedded media item:

...it [is] entirely too easy to accidentally stray-click the "X" icon and remove an embed. They asked for a confirmation dialog to be displayed first. Since the existing image embed button does not display an "X" (you just have to click the embedded image and press Delete on your keyboard), we agreed to remove the "X" button from this patch and add it back, with a confirmation alert box, in a follow-up.

That's this follow-up.

Proposed resolution

Restore and update the relevant code from #2994702-43: Allow editors to alter embed-specific metadata, as well as `data-align` and `data-caption` into a new patch in this issue, and add a confirmation dialog when the "remove" button is clicked. (Also, figure out if the presence of the confirmation should be configurable.)

Remaining tasks

Restore the old code, then determine what the text of the confirmation box should be, whether it should be configurable, etc. Then add tests, get UX and accessibility sign-off, and commit.

User interface changes

Media items embedded in a CKEditor instance will receive a new button which allows them to be removed from the content.

API changes

None expected.

Data model changes

None.

Release notes snippet

TBD

I have a problem with update core from 8.6.x to 8.7.x. My site use default content type article with field_tags. Currently, I have about 600k term and when I can't finish drush updb because memory leak issue. When post update Taxonomy terms have been converted to be revisionable run about 90k this task using about 4G ram and still increase.

TL;DR: dev site initially installed fine, then after a little development, started getting integrity violations on the router table each time it was rebuilt, and then found I was even getting them on a brand new install on a clean DB. I switched from MariaDB to an older MySQL server install on same machine - all the problems went away and I was able to restore from my backup.

---

I had a working site and suddenly found that drush cr failed with errors along the lines of:

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'system.cron_settings' for key 'PRIMARY'

for an SQL insert into the router table. There was indeed an existing row with that name, but deleting the row doesn't help as it merely complains about another record in turn until I've removed the entire table. drush cr will then finish, but of course I have no routing…

Restoring my latest DB backup didn't help, along with truncating cache* tables manually etc.

I noticed the router table only had ~90 rows and on checking earlier backups (I usually take them at every few hours, minimum) it had had around 630 before. The weird thing was that backup was several generations old - well over a day, and I had definitely cleared the cache multiple times since then without seeing any errors, and added/removed various modules.

So I tried bringing that larger table into the most recent copy of the database, that restored my homepage and access for anonymous users, but then I started getting an error about a missing book.admin route as soon as I logged in (the book module is enabled, and I couldn't find a way to disable it cleanly in Drush, or access any of the admin pages).

At this point, I wondered if it would be easier to export all my configuration with `drush cex` (it's a new site so there's no important data, and anyway I have DB backups), commit that to Git, wipe the database completely, rerun the installation script and reimport the config.

So I completely erased the DB, and deleted all the non-core modules from web/modules/contrib.

I ran the installer on a completely empty DB, and the existing composer managed codebase (with modules removed) and it then failed with:

Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'system.401' for key 'PRIMARY': INSERT INTO {router} 

(looking at the DB it's written 63 routes to the router table, most of them system.*, as well as the front page and so on.)

I've actually restored the composer.json to the default version for drupal-composer/drupal-project, and run composer update, and also done a composer dump-autoload (it says 558 classes)

Any suggestions what I could try next? Is there anywhere else in the file system I need to cleanup?

My first thought was the t one of the modules I used and later uninstalled somehow trashed the DB.

There was also a brief power cut last night, and this happened after that, but I think I can rule it out as I mentioned I've been restoring backups from before then and when the router table "wasn't right", and MySQL had no issues on startup this morning.

Drupal 8.7.4 (tested with both PHP 7.2 and 7.3, running on Laravel Valet on macOS)

Here are the modules I've been using (I did also install and uninstall a couple, such as inline_entity_form)

"drupal-composer/drupal-scaffold": "^2.5",
"drupal/auto_entitylabel": "^2.1",
"drupal/coffee": "^1.0",
"drupal/config_ignore": "^2.1",
"drupal/config_override_warn": "^1.2",
"drupal/console": "^1.0.2",
"drupal/content_access": "^1.0",
"drupal/core": "^8.7.0",
"drupal/devel": "^2.1",
"drupal/double_field": "^3.3",
"drupal/environment_indicator": "^3.6",
"drupal/field_group": "^3.0",
"drupal/field_permissions": "^1.0",
"drupal/field_tools": "^1.0",
"drupal/flag": "^4.0",
"drupal/ga_login": "^1.0",
"drupal/hms_field": "1.x-dev",
"drupal/masquerade": "^2.0",
"drupal/metatag": "^1.8",
"drupal/pathauto": "^1.4",
"drupal/required_by_role": "^1.0",
"drupal/role_delegation": "^1.0",
"drupal/seo_checklist": "^4.1",
"drupal/spambot": "^1.0",
"drupal/stringoverrides": "1.x-dev",
"drupal/structure_sync": "^1.16",
"drupal/tfa": "^1.0",
"drupal/token": "^1.5",
"drupal/toolbar_menu": "^2.1",
"drupal/unique_field_ajax": "^1.2",
"drupal/views_secondary_row": "^1.0",

Problem/Motivation

When I set a certain block to be cached for up to e.g. 15 minutes, then I expect that the containing page also emits a corresponding header. And I also expect Drupal's page cache to honor this.

Examples:

1. A block with a weather forecast summary. The data constantly changes so e.g. cache for maximum 15 minutes.
2. A View with a date filter relative to current time, such as "Upcoming Events", showing say 3 soonest future events. The block can be cached for maximum until the time/day of first event, then it must be refreshed to exclude the event now in the past.

Proposed resolution

TBD

Workaround

Install contrib module Cache Control Override. However this is not perfect, and if you use it you might hit the exact same problems that are making this issue be postponed (see #113).

1. Other system blocks such as forms, language switcher that are in fact cachable currently may emit max-age = 0 so will prevent caching after CCO is installed.
2. CCO disables dynamic cache as well as static cache.
3. CCO only detects max-age = 0 so it won't work if your block has a small positive max-age.

Also note that in the case of the second example above, Views will not automatically emit the correct max-age based on the presence of a date filter - you need to write a hook to do that.

Remaining tasks

We need to fix these issues first:

• #2888838: Optimize render caching
• #2578855: Form tokens are now rendered lazily, so forms now *can* be cacheable: stop setting max-age=0 on form token
• #2232375: Make language switcher block cacheable
• #2483181: Make book navigation block cacheable
• #2351015: URL generation does not bubble cache contexts: this one is marked as closed but RedirectFormBlock still contains max-age 0.

User interface changes

None.

API changes

None.