Problem/Motivation

Backporting #3126566: Allow Drupal to work with Composer 2 to the 8.9.x branch exposed a Composer bug that caused composer update commands that should have upgraded to version 8.8.5 to instead upgrade to the unstable dev release 8.9.x-dev. The full details of this bug are described in composer/composer #8882.

Briefly, Composer confuses 8.9.x-dev as a stable release when updating drupal/core-recommended and composer/installers in the same composer update command. Composer becomes confused because Drupal 8.9.x-dev requires composer/installers 1.9.0, whereas Drupal 8.8.5 (and similar) requires composer/installers 1.7.0. Updating to 8.9.x-dev should be prevented by the prefer-stable flag, but somehow the fact that composer/installers 1.9.0 is stable, and upgrading to that version requires Drupal 8.9.x-dev, Composer apparently
forgives the non-stable status of Drupal 8.9.x and allows that upgrade in order to also allow composer/installers to upgrade to 1.9.0.

This bug can be avoided by setting "minimum stability" to "alpha" or better, or by pinning composer/installers to version 1.7.0 in the top-level composer.json file.

Proposed resolution

We presume that this Composer bug could be avoided if we remove composer/installers from drupal/core-recommended. composer/installers is not in the page-serving path, so it should be safe to allow it to float in Drupal projects that use drupal/core-recommended.

Additionally, we will make a new stable 8.8.6 release that does not have composer/installers pinned in drupal/core-recommended. This will make it more likely that Composer will find a stable 8.8.x release and not try to upgrade to 8.9.x-dev.

Remaining tasks

• Remove composer/installers from drupal/core-recommended
• Add a unit test
• Release 8.8.6

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

The project composer/installers is no longer pinned in drupal/core-recommended. It may now be upgraded whenever a new version is available, and a Composer-managed site runs composer update.

The documentation for \Drupal\user\UserInterface::setExistingPassword states that the $this is the return value:

  /**
   * Sets the existing plain text password.
   *
   * Required for validation when changing the password, name or email fields.
   *
   * @param string $password
   *   The existing plain text password of the user.
   *
   * @return $this
   */
  public function setExistingPassword($password);

However, \Drupal\user\Entity\User::setExistingPassword does not return a value:

  /**
   * {@inheritdoc}
   */
  public function setExistingPassword($password) {
    $this->get('pass')->existing = $password;
  }

I'll add a patch to the comments.

Problem/Motivation

In order to avoid mistakes like #3126784: \Drupal\ban\Plugin\migrate\destination\BlockedIP is not identical with its filename BlockedIp.php, field #3126781: Add a sniff to fix class name or interface name not identical with the filename, but found out there is a sniffer/rule existed already. It's called: Drupal.Classes.ClassFileName

Demo:

1. Interface

   $ mv core/lib/Drupal/Component/Annotation/AnnotationInterface.php core/lib/Drupal/Component/Annotation/AnnotationInterfacE.php
   $ composer run phpcs core/lib/Drupal/Component/Annotation/AnnotationInterfacE.php -- -s
   > phpcs --standard=core/phpcs.xml.dist --runtime-set installed_paths $($COMPOSER_BINARY config vendor-dir)/drupal/coder/coder_sniffer -- 'core/lib/Drupal/Component/Annotation/AnnotationInterfacE.php''-s'
   
   FILE: .../core/lib/Drupal/Component/Annotation/AnnotationInterfacE.php
   ----------------------------------------------------------------------
   FOUND 1 ERROR AFFECTING 1 LINE
   ----------------------------------------------------------------------
    8 | ERROR | Interface name doesn't match filename; expected
      |       | "interface AnnotationInterfacE"
      |       | (Drupal.Classes.ClassFileName.NoMatch)
   ----------------------------------------------------------------------
   

2. Class

   $ mv core/lib/Drupal/Component/Annotation/Plugin/Discovery/AnnotatedClassDiscovery.php core/lib/Drupal/Component/Annotation/Plugin/Discovery/AnnotatedClassDiscoverY.php
   $ composer run phpcs -- -s core/lib/Drupal/Component/Annotation/Plugin/Discovery/AnnotatedClassDiscoverY.php
   > phpcs --standard=core/phpcs.xml.dist --runtime-set installed_paths $($COMPOSER_BINARY config vendor-dir)/drupal/coder/coder_sniffer -- '-s''core/lib/Drupal/Component/Annotation/Plugin/Discovery/AnnotatedClassDiscoverY.php'
   
   FILE: ...omponent/Annotation/Plugin/Discovery/AnnotatedClassDiscoverY.php
   ----------------------------------------------------------------------
   FOUND 1 ERROR AFFECTING 1 LINE
   ----------------------------------------------------------------------
    18 | ERROR | Class name doesn't match filename; expected "class
       |       | AnnotatedClassDiscoverY"
       |       | (Drupal.Classes.ClassFileName.NoMatch)
   ----------------------------------------------------------------------
   

Proposed resolution

Just enable it.

Remaining tasks

Needs review
RTBC
Commit

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

#3108006: Replace assertInternalType() calls with dedicated methods removes usages of the assertInternalType() function from core in D9. It might be useful for contrib projects trying to maintain both 8.x and 9.x compatibility to have the new methods available in 8.9.x, or even 8.8.x.

This is a D8 only issue.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

I have created a new Text Format 'Simple Plain' and selected 'Ckeditor' and then save the format. Then in a node, I have used this text format and added some contents.

-Then after I edit Text Format 'Simple Plain' (/admin/config/content/formats/manage/simple_plain) and selected 'none' in Text editor (see image2.jpg), I got below mentioned error on save configuration .

TypeError: Argument 1 passed to Drupal\Core\Form\SubformState::createForSubform() must be of the type array, null given, called in /code/core/modules/editor/editor.module on line 251 in Drupal\Core\Form\SubformState::createForSubform() (line 56 of /code/core/lib/Drupal/Core/Form/SubformState.php)
#0 /code/core/modules/editor/editor.module(251): Drupal\Core\Form\SubformState::createForSubform(NULL, Array, Object(Drupal\Core\Form\FormState))
#1 [internal function]: editor_form_filter_admin_format_submit(Array, Object(Drupal\Core\Form\FormState))
#2 /code/core/lib/Drupal/Core/Form/FormSubmitter.php(114): call_user_func_array('editor_form_fil...', Array)
#3 /code/core/lib/Drupal/Core/Form/FormSubmitter.php(52): Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object(Drupal\Core\Form\FormState))
#4 /code/core/lib/Drupal/Core/Form/FormBuilder.php(591): Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object(Drupal\Core\Form\FormState))
#5 /code/core/lib/Drupal/Core/Form/FormBuilder.php(320): Drupal\Core\Form\FormBuilder->processForm('filter_format_e...', Array, Object(Drupal\Core\Form\FormState))
#6 /code/core/lib/Drupal/Core/Controller/FormController.php(91): Drupal\Core\Form\FormBuilder->buildForm(Object(Drupal\filter\FilterFormatEditForm), Object(Drupal\Core\Form\FormState))
#7 [internal function]: Drupal\Core\Controller\FormController->getContentResult(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\RouteMatch))
#8 /code/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#9 /code/core/lib/Drupal/Core/Render/Renderer.php(573): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#10 /code/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#11 /code/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#12 /code/vendor/symfony/http-kernel/HttpKernel.php(151): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#13 /code/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#14 /code/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#15 /code/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#16 /code/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#17 /code/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#18 /code/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#19 /code/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#20 /code/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#21 /code/core/lib/Drupal/Core/DrupalKernel.php(694): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#22 /code/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#23 {main}

Problem/Motivation

https://www.drupal.org/project/coder/releases/8.3.9 released on 8 May 2020 at 18:31 CST

Proposed resolution

Remember checking potential coding standard violations

$ composer update drupal/coder squizlabs/php_codesniffer
$ composer run phpcs -- -ps

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

The development dependency drupal/coder has been updated to 8.3.9. New coding standards rules are now available with this update.

Problem/Motivation

This is a follow-on from #3048498: [≈Nov. 11] Fix Drupal.Commenting.Deprecated coding standard where the automated patch fixed 653 of the 675 @deprecated messages reported under the Drupal.Commenting.Deprecated.IncorrectTextLayout sniff.

Remaining tasks

1. Commit the first huge automated conversion chunk
2. Follow-up with patches to fix the rest manually (Core 9.1 and 9.0)
3. Enable the new Drupal.Commenting.Deprecated in phpcs.xml (Core 9.1 and 9.0)
4. Fix the rest manually (Core 8.9)
5. Enable the new Drupal.Commenting.Deprecated in phpcs.xml (Core 8.9)

Release note snippet

The new Drupal.Commenting.Deprecated rule has been enabled to ensure that @deprecated documentation follows a standard format with relevant information for upgrading the code. See the deprecation policy for documentation of the standard.

Problem/Motivation

As discussed in #3134731: Update coder to 8.3.9 with @longwave and @jonathan1055, we decided to get phpcs.xml.dist sorted first. and furthermore in another issue, to write a test to ensure all sniffs (commented out or not) are in sync with the list got from the locked version of coder.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Follow up for #1987602: Convert ajax_form_callback() to a new style controller

Problem/Motivation

As specified in #1987602-79: Convert ajax_form_callback() to a new style controller Exception messages shouldn't be translated.

Reasons to not translate exceptions messages (from comments on this issue and #817160: Don't translate exceptions):

• "Additional uncaught exception while handling exception." Calling a whole huge codepath in our exception is liable to obscure the real problem in many situations.
• Adds a dependency on common.inc everywhere we want to throw (or test) an exception. Ugggghh.
• Exception messages are developer-facing strings, and as such, there is no real reason to translate them. As in SimpleTest, we don't need to pollute l.d.o with hundreds upon hundreds of strings no one will care about.
• Googling for translated error messages is more difficult.
• technical issues with ... calling t() ... [especially in the] bootstrap phase ... [and with] ... unit tests.

Proposed resolution

Remove translation of exceptions in code base.

However, it was pointed out that there are user facing exceptions, at least field errors are such., so we may have to specify when it is OK to translate exception messages or refactor these to error messages.

Coder sniff DrupalPractice.General.ExceptionT added to 8.9 in #3134731: Update coder to 8.3.9

Remaining tasks

- Update Coding standards - PHP Exceptions.
- Create a patch (or several patches) that removes all translations of exception messages.

User interface changes

Not really, exceptions should not be shown to end users

API changes

No.

Original report by @xjm

#1987602-79: Convert ajax_form_callback() to a new style controller

Problem/Motivation

We should ship Drupal 9.0 with the latest versions of our dependencies.

Proposed resolution

Update all dependencies.

Remaining tasks

Patch, test, fix any fallout, commit.

PHPUnit 8.5.3 has a seemingly relevant release note: "expectExceptionMessageRegExp() has been removed in PHPUnit 9 without a deprecation warning being given in PHPUnit 8"

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Drupal 9 ships with the latest versions of all of its dependencies.

Problem/Motivation

The minimum MySQL version for Drupal 9 is 5.7.8, but this requirement isn't checked when updating a site to Drupal 9.

Steps to reproduce

1. Given an existing Drupal 8.8.5 site running on MySQL 5.6
2. Update Drupal to 9.x (including update code and database updates)

Expected result
Some sort of warning. I'm not sure of the exact expected results, but I would expect Drupal to warn me at some point that the minimum requirements aren't met.

Actual result
Drupal updated and runs without warning me at all that the minimum requirements aren't met.

Proposed resolution

For 9.0.0, the site seems to run just fine on MySQL 5.6. Presumably this is because no new 5.7-specific features have been added yet. For now, perhaps a warning on the status report page would suffice. This would allow people to update and not WSOD, but would make it clear that the minimum is not met and that it (likely) won't work on 9.1.

Remaining tasks

User interface changes

Adds warnings on both the status report and on update.php that the minimum MySQL version is not satisfied.

Before

Status report

update.php

After

Status report

update.php

API changes

None.

Data model changes

None.

Release notes snippet

The default database is now checked when Drupal is updated to ensure it complies with the minimum version supported by the database driver. (Previously, this only happened during installation.) Updates will not proceed if the requirement is not met.

If you see an error about your database version when running update.php, ensure your database meets the minimum database requirements or install one of the legacy database drivers provided as contributed projects.

Problem/Motivation

This doesn't directly fall under the purview of any particular official initiative, but I'm tagging it for them anyway because it's relevant.

We all know the installer is the red headed stepchild of Drupal, even among red headed stepchildren. There are many reasons for that. Mostly it boils down to:

1) Most of Drupal expects to be running in an installed state, and so we have to hack around that for a special case.
2) Core only supports database-based sessions, so we cannot use a session to store data. That means all sorts of grotesque contortions to pass data along a multi-step form without using any sort of data storage mechanism.
3) It was implemented before any good client-side storage mechanisms existed.
4) Let's be honest, given all of the above, no one has really tried to make the installer a *good* system, just a *working* system. That was hard enough.

Proposed resolution

However!

1) We now have this great new kernel, router, and http library in core courtesy of Symfony.

2) That includes a new session implementation that includes a PHP-native backend, which we can use at all times, even in an uninstalled state. (See #335411: Switch to Symfony2-based session handling for where we're trying to use the new session code for core, too.)

3) That includes the ability to define "routes" (paths and controllers) without using the database.

4) All of our supported browsers for Drupal 8 support real client-side functionality, and arguably we can rely on Javascript, you know, existing.

That means... we can rewrite the installer to be its own Symfony-based micro-application. And in the process, greatly simplify and modernize the code.

The basic idea is this:

1) Implement a new kernel class specific to the installer, using all of the default Symfony components. No custom implementations necessary the way core will need.
2) Give the installer kernel a hard-coded set of routes. There's probably like a half-dozen here.
3) Implement each "step" in the installer as a separate controller at its own path, rather than chaining GET parameters out for a few miles. As a bonus, that makes it possible to actually test each step individually(!)
4) Use a PHP-native session or client-side sessionStorage or whatever to store data rather than throwing crap into the GET string.
5) Clean up a crapload of stuff along the way.
6) Profit!!1!

Note that we will almost certainly run into places where things are still ugly and cannot be made non-ugly just be working around them. That's fine. Anywhere that we find the installer cannot be done without ugliness is a clear sign that we need to refactor something. In a sense, we're using the kernel as a canary in the coal mine to help flush out the sort of refactoring and pulling-apart-of-things-that-are-wrongly-coupled we're going to have to do anyway.

And getting a much better and more maintainable installer out of it is good, too.

Remaining tasks

I have a preliminary stab at this in the kernel-installer branch of the WSCCI sandbox. It's barely started, but it starts to lay out the basic idea. Someone not named Crell needs to pick this up and run with it. :-) Who wants to be the hero of Drupal and make the installer not suck? (Contact me for access to the sandbox if you want.)

Once the installer is done, the same thing can and should be done to both cron.php and update.php. (Actually cron.php may not be necessary anymore, but definitely update.php should also become its own little micro-app.)

User interface changes

The installer's pseudo-paths should turn into real paths. Otherwise there should be no significant UI changes.

API changes

This *should* be possible to do without changing the API for install profiles, but that will be determined by implementation. (Although we may want to adjust the install profile API as well in light of the new installer in a follow-up patch.)

Who wants it???

Problem/Motivation

In #3079680: [META] Requirements for tagging Drupal 9.0.0-beta1, we define must-haves and should-haves for tagging beta1. Some should-haves may cause Drupal 9.0.0-beta1 to be deferred to one of the predefined fallback windows, but we may allow some to be completed during the beta and release candidate phases.

Proposed resolution

This is a stub issue for tracking critical beta target tasks that should happen during the Drupal 9.0 beta phase following 9.0.0-beta1. At a minimum, it will include any should-haves from #3079680: [META] Requirements for tagging Drupal 9.0.0-beta1 not completed by 9.0.0-beta1.

It may include other tasks for core, Drupal.org, documentation, ecosystem tools, etc.

Beta-sensitive bugs

Critical regressions due to recent commits, bugs affecting the upgrade and migration paths to 8.9 and 9.0

1. #3120910: Sites with missing schema information can't update to 8.8.3+ - attempts to run all historical updates
2. #3100712: Drupal 8.7.10 to 8.8.0 update fails if views have invalid configuration
3. #3118625: Some older revisions do not get revision_translation_affected marked by migration when Workbench Moderation is used
4. #3126658: Support enclosing reserved words with brackets.

Must-have (*)

(*) We won't actually delay the scheduled release once we've locked in a beta scenario, but we might delay 9.0.0-rc1 for them.

1. DONE: Email contributed project authors asking them to test the beta and port their modules.
2. DONE: Launch beta testing program:
   #3118372: [meta] 8.9.0 beta testing and #3118366: [meta] 9.0.0 beta testing
3. In-core update/upgrade documentation:
   #3090183: UPGRADE.txt only mentions migrating from Drupal 6 and 7, UPDATE.txt only mentions 8-8 updates
4. Upgrade path regressions:
   • DONE: #3120910: Sites with missing schema information can't update to 8.8.3+ - attempts to run all historical updates
   • #3134606: [backport] PHP Fatal error in 8.9.x / 9.0.x upgrade path
   • #3134648: [backport, needs scheduling] Don't pin the composer/installers version in drupal/core-recommended
   • #3135034: 8.9.x-dev tarball INCLUDES CODER AS A MODULE (!) because Composer packages.drupal.org definition incorrect for Coder 8.3.9
5. DONE: Extension validation regression:
   #3123537: /admin/reports/status should not WSOD if it finds an extension missing core_version_requirement in its info.yml file
6. Dependency support:
   • DONE: #3127674: Update dependencies for Drupal 9.0
   • DONE: #3107918: Require Node.js 12
   • DONE: #3118726: Upgrade to js.cookie 3
   • #3126566: Allow Drupal to work with Composer 2
   • #3122112: Update dependencies for Drupal 8.9

Should-have

1. More contrib -> core migration paths:
   • #2456259: [META] Drupal 7 to Drupal 8 Migration path
   • #2208401: [META] Remaining multilingual migation paths
   • #3076447: Migrate D7 entity translation revision translations
2. Dev dependency updates:
   • #3107926: Update stylelint to ^13.0.0
   • Other dependency updates following Node and Stylelint updates
3. Other upgrade path criticals:
   • #3100712: Drupal 8.7.10 to 8.8.0 update fails if views have invalid configuration
   • #3118625: Some older revisions do not get revision_translation_affected marked by migration when Workbench Moderation is used
   • #3136668: Invalid system.schema key_value entry causes fatal on updating to 8.8.5
4. Usability issue for the installer: #3120731: Incorrect "Drupal already installed" if any database settings are wrong or unsatisfactory
5. Forward compatibility shims for third-party libraries:
   • #3126695: [D8 only] Add forwards-compatibility shim for assertEqualsCanonicalizing() in phpunit 6&7
   • #3126787: [D8 only] Add forwards-compatibility shim for assertInternalType() replacements in phpunit 6&7
6. DB driver versions not checked on update: #3135629: Minimum MySQL version requirement is not confirmed when upgrading existing sites from Drupal 8 to Drupal 9
7. Consider downgrading SQLite requirement: #3107155: Discuss lowering SQLite version requirement from 3.26 to 3.22 in Drupal 9

Could-have

Needs triage

• Beta target issue queue
• #3131950: UX review of the finished, semver-compliant update status report for how it presents the Drupal 8.9 and 9.0 updates for users on various versions
• Other tasks TBD.

Problem

1. install_begin_request() contains arbitrary bootstrap and state checking logic.
2. install_tasks() contains arbitrary bootstrap and state checking logic.
3. Every install task needs to check on its own whether it is available.
4. Every install task needs to check on its own whether it is required.
5. Every install task needs to check on its own whether it can run.
6. Every install task needs to account separately for the non-interactive vs. interactive installer.
7. Various install tasks have inter-dependencies to/from other install tasks.
8. Less than a handful of people understand how the installer works.

Proposed solution

1. Introduce a Graph-based install task/step manager:

   install.php
   ∟ DrupalKernel
     ∟ InstallerServiceProvider
       ∟ InstallerTaskManager ← Graph
         ∟ InstallTask (already installed?)
         ∟ InstallTask (distribution profile)
         ∟ InstallTask (language)
         ∟ InstallTask (translation download)
         ∟ InstallTask (profile)
         ∟ InstallTask (database settings)
         ∟ InstallTask (filesystem settings)
         ∟ InstallTask (core base system installation)
         ∟ InstallTask (kernel reboot/rebuild into production environment)
         ∟ InstallTask (module installation)
         ∟ InstallTask (theme installation)
         ∟ InstallTask (extension translation download + import)
         ∟ InstallTask (profile task X)
         ∟ InstallTask (final installer cleanup)
   

2. All available install tasks are instantiated immediately, in order to

   1. Resolve dependencies
   2. Check (task) availability
   3. Check requirements
   4. Auto-resolve task parameters from current Request and/or current State
   5. Resolve the next task to be executed

   Install tasks no longer have a hard-coded order. Dependencies define execution order.

   Plugins?

3. global $install_state→ \Drupal::state()->get('installer')

   As soon as available, the current installer state is loaded from persistent state storage instead of being rebuilt from scratch on every request.

Notes

1. This probably can and should be abstracted for re-use (e.g., update.php, same drama), but intentionally ignoring that topic for now.

Problem/Motivation

Refactor install_verify_database_settings(), install_verify_database_ready(), install_database_errors() into an Install helper class. Adding new methods piecemeal is our we're ending up with a disjointed API where we want the same method to do different things. We'll probably be able to make SiteSettingsForm use this too for added consistency and less code duplication.

Also possibly we want to look at how we validate database settings in migrate_drupal too.

This came up in #3120731: Incorrect "Drupal already installed" if any database settings are wrong or unsatisfactory

Proposed resolution

Remaining tasks

• Design the API
• Look for use cases in core

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Composer 2 is on its way, and may provide benefits to Drupal sites. It should be possible to use Composer 2 to run commands such as require, update and install on Drupal sites.

https://github.com/composer/composer/blob/master/CHANGELOG.md#200--2020-

Proposed resolution

• Declare that our plugins work with the ^2 Composer API
• Implement the new methods of the Composer 2.x plugin interface
• Upgrade to composer/installers ^1.9 (earlier versions are not compatible with the Composer 2 plugin API)
• Remove wikimedia/composer-merge plugin
• Call OperationInterface:: getOperationType() instead of OperationInterface::getJobType() (renamed in Compsoer 2)
• Skip tests that will not work with Composer 2 until there is a stable release of our Composer plugins that are compatible with Composer 2.

Note that Drupal also has Composer dependencies internally, including composer/composer (require-dev only) and composer/semver (required in drupal/core). Updating these components cannot be done until there is a stable release available; therefore, updating these components is out of scope for this issue. See below.

Remaining tasks

• Change log
• Create follow-on issue to enable the scaffold upgrade test for Composer 2 once there is a stable (tagged) release of drupal/core-composer-scaffold that can be installed with Composer 2.#3128641: Enable scaffold upgrade test for Composer 2
• Create follow-on issue to upgrade internal Composer components used by Drupal, composer/composer and composer/semver, to ^2 once stable versions are available. Also re-enable the scaffold upgrade test for Composer 2 once this is done.#3128631: Update dependencies composer/composer and composer/semver to ^2
• Follow-on issue for drupa/coder issue#2851279: Update version requirements for drupal/coder to best practices
• Determine how to detect newly-installed packages after composer require in Composer 2.
• Roll back the upgrade of composer/composer and composer/semver (and additional upgrades from --with-dependencies), and keep them what they were prior to this patch. Retain upgrade of composer/installers, though.
• Release notes snippet

User interface changes

None

API changes

Drupal must react to some Composer API changes, as mentioned above; however, no APIs defined by Drupal change.

Data model changes

None

Release notes snippet

The Composer plugins provided by Drupal -- the scaffold plugin, the vendor hardening plugin, and the project message plugin -- are now compatible with Composer 2.

Problem/Motivation

We should ship Drupal 9.0 with the latest versions of our dependencies.

Proposed resolution

Update all dependencies.

Remaining tasks

Patch, test, fix any fallout, commit.

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Drupal 9 ships with the latest versions of all of its dependencies.

We're having problem with a combination of the core language modules and the Content view using DISTINCT. Here are steps to reproduce it in a minimal 8.3.5 site installation. It must be using MySQL 5.7+ with ONLY_FULL_GROUP_BY enabled.

Enable the Multilingual modules:

Configuration Translation config_translation
Content Translation content_translation
Interface Translation locale
Language language

Navigate to /admin/config/regional/language/detection and deselect URL

Navigate to /admin/config/regional/language and Add Language. Select Danish and wait for the translation files to download

Navigate to /admin/config/regional/language/detection/selected and set the default language to Danish

Navigate to /admin/structure/views/view/content and select Distinct in the query settings (Indstillinger for forespørgsel:Indstillinger / Særskilt)

Select Content (Indhold)

Drupal\Core\Database\DatabaseExceptionWrapper: Exception in Indhold[content]: SQLSTATE[HY000]: General error: 3065 Expression #1 of ORDER BY clause is not in SELECT list, references column 'drupal8.node_field_data.changed' which is not in SELECT list; this is incompatible with DISTINCT: SELECT DISTINCT node_field_data.langcode AS node_field_data_langcode, users_field_data_node_field_data.langcode AS users_field_data_node_field_data_langcode, node_field_data.nid AS nid, users_field_data_node_field_data.uid AS users_field_data_node_field_data_uid FROM {node_field_data} node_field_data INNER JOIN {users_field_data} users_field_data_node_field_data ON node_field_data.uid = users_field_data_node_field_data.uid WHERE (node_field_data.status = 1 OR (node_field_data.uid = 1 AND 1 <> 0 AND 1 = 1) OR 1 = 1) ORDER BY node_field_data.changed DESC LIMIT 50 OFFSET 0; Array ( ) i Drupal\views\Plugin\views\query\Sql->execute() (linje 1488 af /home/ubuntu/deleteme/drupal83/drupal/web/core/modules/views/src/Plugin/views/query/Sql.php).

The issue is related to the use of DISTINCT with ONLY_FULL_GROUP_BY in MySQL 5.7, and the fact that the ORDER BY column is not in the select.

This was performed on Ubuntu 16.04 with the following

Drupal 8.3.5
PHP 7.0.19-1+deb.sury.org~xenial+2
MySQL 5.7.18-0ubuntu0.16.04.1
nginx/1.10.0

Problem/Motivation

If you add a menu link to the Administration menu, and that menu link has an unrouted URI, when the toolbar is oriented vertically, there is a Javascript error which prevents the buttons for child menus from appearing.

Steps to reproduce:

1. Add menu link to administration menu at /admin/structure/menu/manage/admin/add
2. Set menu link title to anything.
3. Set link to any URL that is not routed in Drupal: (use https://www.google.com, for example)
4. Set parent link to <Administration>
5. Save
6. If toolbar is vertical, click the arrow to change it to vertical
7. Observe that buttons for child menus do not appear.
8. Observe that error is logged in browser console.

Uncaught Error: Syntax error, unrecognized expression: #toolbar-link-https://www-google-com
    at Function.se.error (jquery.min.js?v=3.4.1:2)
    at se.tokenize (jquery.min.js?v=3.4.1:2)
    at se.select (jquery.min.js?v=3.4.1:2)
    at Function.se [as find] (jquery.min.js?v=3.4.1:2)
    at k.fn.init.find (jquery.min.js?v=3.4.1:2)
    at MenuVisualView.js?v=8.8.5:19
    at Array.forEach (<anonymous>)
    at n.render (MenuVisualView.js?v=8.8.5:18)
    at _ (backbone.js:371)
    at m (backbone.js:356)

Proposed resolution

Issue appears to be in \Drupal\toolbar\Controller\ToolbarController::preRenderGetRenderedSubtrees(), where in this line:

$id = str_replace(['.', '<', '>'], ['-', '', ''], $url->isRouted() ? $url->getRouteName() : $url->getUri());

$url->getUri() contain unsafe characters for DOM IDs.

In toolbar_menu_navigation_links(), unrouted URIs are hashed like so:

$id = substr(Crypt::hashBase64($url->getUri()), 0, 16);

It seems to make sense to use that in the Controller pre-render method as well.

$id = str_replace(['.', '<', '>'], ['-', '', ''], $url->isRouted() ? $url->getRouteName() : substr(Crypt::hashBase64($url->getUri()), 0, 16));

Remaining tasks

Needs reviews and tests

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

(Major and critical issues should have a snippet that can be pulled into the release notes when a release is created that includes the fix)

There's still some docs use hook_field_schema() but there's no such hook