Right now, the Migration plugin does a lot of grunt work related to instantiating and managing source, destination, and ID map plugins and their configuration. This is a shame, because core already has an API for abstracting and encapsulating that kind of thing -- namely, plugin collections. The Migration plugin should use this plumbing, rather than reinventing the wheel. It's considered good practice to use plugin collections, and it's nice to delegate as much of the details of plugin management as we can.

Problem/Motivation

7.x port of #992540: Nothing clears the "5 failed login attempts" security message when a user resets their own password (8.3.x & 8.4.x)

If a user forgets their password and tries to log in 5 times then they get blocked by flood control. They can now use the password reset functionality per email, but once they log out shortly after that they are still blocked when trying to log in again.

Proposed resolution

Clear the user specific flood events once they used the password recet functionality so that they are able to normally log in again. Do not clear IP address specific flood events because then an attacker with a valid account could clear flood events for victim user accounts.

Remaining tasks

Update and review the patch.

Problem/Motivation

At present if an attempt to authenticate via the user login form is blocked by flood control, nothing useful is logged.

The form gets an error set on it, but the response is still a 200 which means that access log entries cannot be identified by anyone interested in whether a site is being brute-forced.

e.g. core/modules/user/src/Form/UserLoginForm.php

      if (!$this->flood->isAllowed('user.failed_login_ip', $flood_config->get('ip_limit'), $flood_config->get('ip_window'))) {
        $form_state->set('flood_control_triggered', 'ip');
        return;
      }

...and then:

      if ($flood_control_triggered = $form_state->get('flood_control_triggered')) {
        if ($flood_control_triggered == 'user') {
          $form_state->setErrorByName('name', $this->formatPlural($flood_config->get('user_limit'), 'There has been more than one failed login attempt for this account. It is temporarily blocked. Try again later or <a href=":url">request a new password</a>.', 'There have been more than @count failed login attempts for this account. It is temporarily blocked. Try again later or <a href=":url">request a new password</a>.', [':url' => $this->url('user.pass')]));
        }
        else {
          // We did not find a uid, so the limit is IP-based.
          $form_state->setErrorByName('name', $this->t('Too many failed login attempts from your IP address. This IP address is temporarily blocked. Try again later or <a href=":url">request a new password</a>.', [':url' => $this->url('user.pass')]));
        }
      }

Whereas in core/modules/user/src/Controller/UserAuthenticationController.php

    if (!$this->flood->isAllowed('user.failed_login_ip', $flood_config->get('ip_limit'), $flood_config->get('ip_window'))) {
      throw new AccessDeniedHttpException('Access is blocked because of IP based flood prevention.', NULL, Response::HTTP_TOO_MANY_REQUESTS);
    }

...so that yields a 403 in access logs.

At present we see something like this when the login form is brute-forced:

==> syslog <==
Jul  3 15:57:53 xenial-php drupal: http://drupal8x.xp|1530633473|user|10.0.3.1|http://drupal8x.xp/user/login||0||Login attempt failed for foo.

==> access.log <==
drupal8x.xp 10.0.3.1 - - [03/Jul/2018:15:57:53 +0000] "POST /user/login HTTP/1.1" 200 11726

..repeated a few times, until flood control kicks in, at which point we just see:

==> access.log <==
drupal8x.xp 10.0.3.1 - - [03/Jul/2018:15:57:55 +0000] "POST /user/login HTTP/1.1" 200 11726
drupal8x.xp 10.0.3.1 - - [03/Jul/2018:15:57:57 +0000] "POST /user/login HTTP/1.1" 200 11798
drupal8x.xp 10.0.3.1 - - [03/Jul/2018:15:57:58 +0000] "POST /user/login HTTP/1.1" 200 11798

Proposed resolution

Anyone wanting to gather threat intelligence from a Drupal site's logs would ideally want specific log entries to say "a login from this IP was blocked by flood control".

There may be performance reasons why we wouldn't want to make these log entries (e.g. it may represent a DoS risk especially on sites which are using the default database logging).

Filing this issue to discuss and work on potentially a couple of changes (follow up issues can be filed if appropriate):

* Respond with a 403 (consistently) when a login attempt has been blocked due to flood control limits.
* Log these blocked login attempts to logger (/ watchdog if we backport) - possibly as an opt-in change in order to avoid possible performance regressions.

Remaining tasks

* Discuss proposed changes.
* Implement them.

User interface changes

* Perhaps an option to turn flood control / brute force logging on and off?
* More / different log entries, if those count as UI.

API changes

None?

Data model changes

None?

Problem/Motivation

This is a follow up to #3024682: Migrate UI - add human-friendly module names to the Review form.
Here we want to "make the styling 10,000% better and match the Upgrade Status module" , as webchick said in comment #54 of that issue.

Work on this does not need to wait for #3024682: Migrate UI - add human-friendly module names to the Review form to be committed. It is near RTBC and any changes are likely to be small as easy to merge. Finally, setting to Major since this will be a big improvement to that form.

Proposed resolution

The details of the suggestion by webchick, from #45 are:
We could handle that bit like Upgrade Status module does (https://www.drupal.org/files/project-images/UpgradeStatus8UI.png), which is:
1) A full table of all modules in alphabetical order (could indeed group sub-modules under package if you'd like; Update Status module does that: https://www.drupal.org/files/issues/2019-10-09/d8-update-manager.png)
2) Colour + icon the table rows according to their statuses
3) Allow filtering the table to show only rows with a problem

The Upgrade Status Module uses 3 columns and the Review page 2. Should we stay with 2 or add a third?

Remaining tasks

1. Decide if the table should have 2 or 3 columns?
2. Modules grouped by project. Functional but needs work from front-end folks.
3. Add colour + icon. Functional but needs work from front-end folks
4. Add a filter to show only rows with a problem.

User interface changes

Yes, the Migrate UI review page /upgrade/review

Screenshots

Before
Three columns as it will be once #3024682: Migrate UI - add human-friendly module names to the Review form is committed.

After

API changes

Data model changes

Release notes snippet

Is it reasonable to ask to add support for .FLAC and .AAC audio type of file with HTML 5 audio player?
Is it scheduled? Does it ask a lot of dev?

the problem i face is that i use mediaelement.js as audio player and i can play flac and aac with it on front end. the problem is that in the backend if i render audio file with the native drupal player audio, the player audio display for mp3, wav and ogg, but dont display for flac and aac. i dont want to use the mediaelement.js in the backend.

Problem/Motivation

Following on from #2842431: [policy] Remove PHP 5.5, 5.6 support in Drupal 8.7 we need to decide how to treat PHP 7 support.

Each release branch of PHP is fully supported for two years from its initial stable release. During this period, bugs and security issues that have been reported are fixed and are released in regular point releases.

After this two year period of active support, each branch is then supported for an additional year for critical security issues only. Releases during this period are made on an as-needed basis: there may be multiple point releases, or none, depending on the number of reports.

PHP 7.0 has security support until 3 Dec 2018

PHP 7.1 has security support until 1 Dec 2019

Drupal 9 will require PHP 7.2 at least as per #3079791: Bump Drupal's minimum PHP version to 7.2 as soon as 9.0.x is branched (a higher version may be required later), however that might be raised further based on this issue later.

Proposed resolution

Option 1. Increase the explicit requirement for PHP version each time security support for the previous version has been dropped. This will prevent the next minor release from installing on the version that has no security support, and show a warning on any existing installs.

Advantages:
- very clear cut off point

Disadvantages:
- prevents using Ubuntu LTS releases that still backport security fixes to the older version.

Option 2. Disable automated testing etc., but don't actually increase the requirement in code (except possibly to show a hook_requirements() warning if we add that). This will allow people running older PHP versions to keep doing so, but we won't accept bug reports etc. for anything specific to that version. The hard requirement may be added once a dependency relies on a PHP 7 + n feature though.

Advantages:
- allows people on Ubuntu LTS to keep going if they want to

Disadvantages:
- less clear warning for people self-hosting who haven't updated
- could result in bug reports specific unsupported PHP versions which require triaging.

Remaining tasks

Track PHP ecosystem responses to PHP 7.0 and 7.1 EOL.

Hosting provider information

See #2938725: [tracking issue] Track hosting provider support for PHP 7.

Distros

• Debian
  • Debian 9: Ships with PHP 7.0. Released in 2017; LTS coverage until "~2022" as per https://wiki.debian.org/DebianReleases).
  • Debian 10: Ships with PHP 7.3. (LTS coverage likely until at least 2024, even an approximate is not yet available).
• Ubuntu
  • 16.04: Shipped with PHP 7.0. Released April 2016; supported until April 2021.
  • 18.04: Shipped with PHP 7.2. Released April 2018; supported until April 2023.
  • 20.04: PHP version TBD? Will be released April 2020; supported until April 2025.

I am running a Drupal 8 site behind a load balancer/reverse proxy. There are three Drupal servers, one primary database and one replication database. We have cookie connection persistence enabled on the load balancer.

The configuration works well, except for CSS and JS aggregation. The servers have inconsistent sets of files in the sites/default/files/[js|css] directories, and this can result in 404 errors when people are loading the pages.

I have cleared cache repeatedly on the servers, but cannot get consistent results. As a result, we have disabled aggregation.

Is there a way to maintain consistency of aggregated css/js files across multiple servers behind a reverse proxy?

Problem/Motivation

Pointed out by @xjm in Slack:

"We need to update the styling/logo here for D9"

Proposed resolution

Fix the branding for this.
Perhaps we can use the new "evergreen" Drupal logo? But maybe that's fraught with legal hassles.
TBD.

Remaining tasks

1. Decide what we should do.
2. Do it.
3. Reviews/improvements.
4. RTBC.
5. Commit.

User interface changes

Change the branding on the status report. Details TBD.

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Problem/Motivation

Some blocks, like user login, should be shown on 403/404 pages.
Others, like the help block, should not.

Proposed resolution

Add a visibility setting to blocks that shows them on 403/404 pages.
Default this to TRUE.

Remaining tasks

Write tests

User interface changes

API changes

Problem/Motivation

In #3032686: Remove references to unused packages in Drupal 9's vendor hardening we added new test methods. To avoid blocking Drupal 9.0.0-rc1 the patch was committed with missing parameter and return type documentation.

Proposed resolution

See #3032686-31: Remove references to unused packages in Drupal 9's vendor hardening

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

This is a follow-up to #2545520: The same link "available updates" links to two different pages in the same paragraph when there is a problem checking available updates. The following changes were considered out of scope for that issue, especially since changing the text would break existing translations.

See the screenshots for various cases listed in Comment #122 on that issue. Also see Comment #124.

1. When there is a problem checking for updates (to Drupal core or to contributed modules and themes) the status report includes this text from _update_message_text():

There was a problem checking [available updates] for Drupal.

or

There was a problem checking [available updates] for your modules or themes.

(with the link going to /admin/reports/updates).

We considered using the same text in both cases, removing " for Drupal" or " for your modules or themes".

2. When updates are available, the status report includes this text from _update_requirement_check():

See the [available updates] page for more information and to install your missing updates.

Replace that with

Review and install [pending updates].

Proposed resolution

1. Use the simpler text for both cases.

2. Replace the deprecated \Drupal::url() with \Drupal\Core\Url::fromRoute().

3. Screenshots

(a) Status Report:

(b) Status Report - no update manager access:

(c) Updates available email:

Remaining tasks

Review how this will affect the Status report and the e-mail generated by update_mail().

User interface changes

This will affect the status report (/admin/reports/status) and the system e-mails generated by update_mail().

API changes

None.

Data model changes

None.

Greetings, first of all I apologize for my English, I do not speak it, I use a translator. I also apologize for not knowing if I am publishing my problem correctly, I am new to this community and I find its use somewhat complicated. I present my excuses.

I am trying to add an additional style sheet to my site that only works on 4 pages. I have a week reading and researching but I can't get it, this year, thanks to the pandemic, I had time to migrate from Drupal 7 to Drupal 8 and although I finished uploading my page I have a couple of little things pending and I can't grasp how to do it. I have in my theme a style sheet (I add that my theme is a Bootstrap Subtheme and that it is working well), in the following address my_theme\css\style.css and in that same folder I have the one that I want to add style2.css.

The first one I did by configuring my_theme.libraries.yml as follows:

framework:
css:
theme:
css/style.css: {}

If I add the following: ccs/style2.css: {} after the last line I can add the other one, but it is not what I want since I need it to only affect 4 pages of my site. I try to implement TEMA_preprocess_HOOK in the following way:

function my_theme_preprocess_corporative (array &$variables) {
$ variables ['# attached'] ['library'] [] = 'my_theme/style2.css';
}

Where THEMA = my_theme and HOOK = corporative (I'm not sure about this, this is the name of one of the pages where I want it to appear, when I type site/corporate I manage to go to it) but it doesn't work for me, don't add it and I realize when inspecting the pages.

Also check the specification of the cache metadata (although I'm still not very clear) and nothing that works What am I missing or what am I doing wrong? If I can solve this I will also solve the other pending thing which is to add a custom .js for those same pages. I would be very grateful for your indications in this regard.

Elements inside a form-item can cause unwanted overflow to happen (see screenshot).
Path: admin/content
Patch follows.

Extra space is there after header in mobile view , I have added screenshots for the reference.
You can go to /admin/content or /structure/types/manage/article/fields to reproduce this issue

The isFirstTimeModeration() method does not take into account the language of the revision being saved.

  protected function isFirstTimeModeration(EntityInterface $entity) {
    $original_entity = $this->moderationInformation->getLatestRevision($entity->getEntityTypeId(), $entity->id());

    if ($original_entity) {
      $original_id = $original_entity->moderation_state;
    }

    return !($entity->moderation_state && $original_entity && $original_id);
  }

To reproduce:

1. Turn on languages and enable a second language
2. Create a content node for a type governed by a moderation workflow
3. Set that node to a state X from which it is not allowed to transition to state Y
4. Create a new translation of the content node and attempt to save it in state Y, a valid initial state for the workflow

Expected:
Transition is allowed and translation save is successful

Observed:
Save operation fails with error message "Invalid state transition from X to Y"

OS: Linux 6d0059f22c0e 4.9.125-linuxkit
Distribution: Ubuntu 18.04.1 LTS (Bionic Beaver)
Web Server: Apache 2.4.29-1ubuntu4.5
PHP: Version 7.2.10-0ubuntu0.18.04.1
Drupal: 8.7.0-dev (commit 0d0356bfcba2f5b73eaa13f5598156585f3133e2)

Problem/Motivation

Autocomplete has the option to disable search for certain input using the attribute data-autocomplete-first-character-blacklist on the autocomplete form element. Unfortunately this doesn't stop EntityAutocomplete::validateEntityAutocomplete() to search for strings matching the blacklist or trying to validate these strings.
I stumbled across this while working on #2756247: UX improvement: use autocomplete for entity selection in area handlers.

Proposed resolution

EntityAutocomplete::validateEntityAutocomplete() does not search for strings matched by the configured blacklist and does not try to validate these strings.

Remaining tasks

Create patch.

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

Want to test out the Contrib Kanban board for Drupal 9 porting weekend issues list.

Proposed resolution

Create this meta issue and associate other issues.

Remaining tasks

1. Create this issue
2. Create contribkanban board
3. Add related issues that are worked on during the event

User interface changes

API changes

Data model changes

Release notes snippet

Updating from Drupal 8.7.10 to Drupal 8.8.0 and I've run into a few issues, not 100% sure they're all related but can't seem to find solutions.

1. After pulling in new code I run a drush updb and see a long list of database updates that need run.
2. All the updb's run except for views module :
Remove core key from views configuration.
3. The error I see on that failure is

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "content_moderation_state" entity type does not exist. in Drupal\Core\Entity\EntityTypeManager->getDefinition() (line 150 of /var/application/docroot/core/lib/Drupal/Core/Entity/EntityTypeManager.php

We are not using the moderation module and thus it's not enabled ( nor has it ever been enabled ). The site seems to be running okay except that when I go to /admin/config/development/configuration I get this error ( white screen as well )

TypeError: Argument 2 passed to Drupal\Core\Config\DatabaseStorage::write() must be of the type array, boolean given, called in /var/application/docroot/core/lib/Drupal/Core/Config/Storage

Doing a drush cim runs through a list of imports and ends successfully, yet if I re-run the drush cim it lists the same ymls and repeats the same success message.

Problem/Motivation

Follow-up to #3021653: Move file status constant to FileSystemInterface

This constant related to file entity, so better to keep it in interface

Proposed resolution

Move definition to \Drupal\file\FileInterface and replace all usage
Also make sure that file module enabled when new constant will be used

Remaining tasks

- discus naming STATUS_PERMANENT or just PERMANENT
- patch, review, commit

User interface changes

no

API changes

Constant FILE_STATUS_PERMANENT moved to \Drupal\file\FileInterface::STATUS_PERMANENT

Data model changes

Release notes snippet

Problem/Motivation

UnitTestCase::assertArrayEquals seems redundant now - PHPUnit's provided assertEquals method is actually doing a per-key comparison in associative arrays by default; in case the structure matters assertSame can do, and in case of simple arrays assertEqualsCanonicalizing can be used to pre-sort values before comparison.

Proposed resolution

Deprecate assertArrayEquals and replace its usages with standard PHPUnit methods.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet