Problem/Motivation

Core option fields don't allow using predefined select list. One can use https://github.com/Realityloop/list_predefined_options to add the functionality which is an unoffical port of http://drupal.org/project/list_predefined_options.

It is a very generic functionality i.e. country list, states lists, timezones and language list.

Proposed resolution

Move https://github.com/Realityloop/list_predefined_options functionality to the core. It shouldn't have to be an experimental module.

Remaining tasks

• Create Patch (WIP)
• Update the docs with the new plugin type

User interface changes

None

API changes

The 'allowed_values_function' will be deprecated since its functionality is covered by the new plugin type.

We've run into an issue where we are getting an error on a link field:

Error: Unsupported operand types in /core/modules/link/src/Plugin/Field/FieldFormatter/LinkFormatter.php on line 245

I don't know if it's possible to reproduce this error with just core. The error seems to be coming from a translation issue in Paragraphs where the "options" property isn't getting set right. This patch is a work-around to that but it's just checking that $options is an array and making it one if it's not so it won't hurt anything to have it in there as a failsafe.

Problem/Motivation

Currently the VendorHarderingPlugin is only able to process packages installed in the vendor directory. That very strongly limits it's usage. It would be nice if it could harden Composer packages in any directories. For instance Drupal core ships with 4 MB demo_umami installation profile. Given it's a demo profile why should any Drupal site have it on production?

Proposed resolution

Process all packages regardless of their location.

$composer = $event->getComposer();
$installation_manager = $composer->getInstallationManager();
$package_path = $installation_manager->getInstallPath($package);

Problem/Motivation

There are four deprecated services in core.services.yml scheduled for removal in Drupal 9.

Proposed resolution

Remove the services.

Remaining tasks

Patch, test, commit.

User interface changes

None

API changes

Deprecated services will no longer be available.

Data model changes

None

Release notes snippet

Problem/Motivation

DRUPAL_PHP_FUNCTION_PATTERN was deprecated in Drupal 8.8.0. It is a single constant with no remaining uses in core.

Proposed resolution

Remove it from Drupal 9.

Remaining tasks

Patch, test, commit.

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Acc to https://www.drupal.org/node/2000204 .Dependencies should be namespaced in the format: {project}:{module} in .info.yml file.

Problem/Motivation

Now that Symfony sessions are in place and available from $request->getSession(), core should be updated that it uses that instead of accessing $_SESSION directly. Benefits for doing that is a) code depending on the session will get easier to test b)Session::get()/Session::set() takes care of starting the session automatically. That way we can eliminate direct access to the session_manager in most places.

Proposed resolution

Fix any occurence of the $_SESSION superglobal. Except in the following cases:

No change (legacy code):

core/lib/Drupal/Core/Messenger/LegacyMessenger.php
core/modules/simpletest/src/TestBase.php

LegacyMessenger will be removed in #2928994: Remove \Drupal\Core\Messenger\LegacyMessenger

No change (SessionManager and compatibility tests for $_SESSION superglobal):

core/lib/Drupal/Core/Session/SessionManager.php
core/modules/system/tests/modules/session_test/src/Controller/SessionTestController.php
core/modules/system/tests/modules/session_test/src/EventSubscriber/SessionTestSubscriber.php
core/modules/system/tests/src/Functional/Session/SessionTest.php

Other issue: #3109970: Convert uses of $_SESSION in forms and batch

core/includes/batch.inc
core/includes/form.inc
core/lib/Drupal/Core/Form/FormBuilder.php

Other issue: #3109042: Convert uses of $_SESSION in update module and authorize subsystem

core/authorize.php
core/lib/Drupal/Core/FileTransfer/Form/FileTransferAuthorizeForm.php
core/modules/system/system.module
core/modules/system/tests/src/Functional/System/SystemAuthorizeTest.php
core/modules/update/src/Form/UpdateReady.php
core/modules/update/update.authorize.inc
core/modules/update/update.manager.inc

Other issue: #3109600: Convert uses of $_SESSION in language module

core/modules/language/src/Plugin/LanguageNegotiation/LanguageNegotiationSession.php

Other issue: #3109971: Convert uses of $_SESSION in ViewsExecutable

core/modules/views/src/ViewExecutable.php

Remaining tasks

• Scope
• Patch
• Review
• Commit

User interface changes

API changes

+++ b/core/modules/dblog/src/Controller/DbLogController.php
@@ -122,9 +126,9 @@ public static function getLogLevelClassMap() {
-  public function overview() {
+  public function overview(Request $request) {

@@ -306,12 +310,16 @@ public function eventDetails($event_id) {
-  protected function buildFilterQuery() {
+  protected function buildFilterQuery(Request $request) {

+++ b/core/modules/migrate_drupal_ui/src/Controller/MigrateController.php
@@ -12,12 +13,14 @@ class MigrateController extends ControllerBase {
-  public function showLog() {
+  public function showLog(Request $request) {

+++ b/core/modules/user/src/Controller/UserController.php
@@ -223,7 +225,7 @@ public function getResetPassForm(Request $request, $uid) {
-  public function resetPassLogin($uid, $timestamp, $hash) {
+  public function resetPassLogin($uid, $timestamp, $hash, Request $request) {

A colleague of mine - @ricksta (https://www.drupal.org/u/ricksta) - pointed out that when creating a "Custom block" via Layout Builder, the title confusingly reads "Add a new Inline block", which of course is the original name for what are now considered "Custom blocks", at least in the UI sense.

Steps to recreate:
- Install standard profile
- Add at least one additional custom block type besides the "Basic block"
- Enable Layout Builder
- Enable Layout Builder for Article Content type
- Go to edit layout
- Click "Add block"
- Click the "Create custom block" button
- The title of the tray reads 'Add a new Inline Block'

It appears to us we should have consistency here, in that the user has clicked "Create custom block", and the title reads "Add a new custom block"

Problem/Motivation

Views allows rendering a block in the View header or footer using the 'Global: Rendered entity - Block'

Problem 1: Bad UX

What value to enter in the field 'Block ID'. After a bit of trial and error, I managed to get this working by adding a block to a region, editing the block and getting the ID from the URL.

Problem 2: Dependency on block in region

I've "created" a block ID by placing a blok in a region. But the block ID only exists as long a the the block is configured to be visible in a region. When the block is deleted from the region, the View breaks.

Proposed resolution

• Make a block selectable via the interface, similar to the selection following 'Place block' on /admin/structure/block.
• Make rendering a block in the view independent of the block being placed in a region.

Remaining tasks

• Make a patch
• Write test

User interface changes

Improved UX by making a block selectable.

API changes

Data model changes

Problem/Motivation

I imagine it is a fairly common wish to create a new route or local task that is only applicable to a certain bundle or bundles.

At the moment that requires some custom access code.

Proposed resolution

And an _entity_bundles access checker.

Routes wishing to use this just get an extra requirement specifying the entity type and bundles that needs to match:

example.route:
  path: foo/{example_entity_type}/{other_parameter}
  requirements:
    _entity_bundles: 'example_entity_type:example_bundle|other_example_bundle'

Remaining tasks

User interface changes

API changes

Only additions to routing.yml

Data model changes

None

Release notes snippet

An entity bundles access check has been added to make it easier for custom code to define bundle-specific routes.

Currently the MySQL temporary table code explicitly specifies that the storage engine should be MEMORY. While this may commonly be the case, there are some reasons to use other storage engines instead (for example: TEXT/BLOB support; more efficient usage by providing true variable length storage).

From MySQL 5.6, it is also possible to change what temporary tables are created as:
http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysv...

Problem/Motivation

system_update_8804() fails if any path alias is saved before running it.

There are several ways this can happen:

1. A hook_modules_installed() (triggered by the enabling of path_alias module in system_update_8003()) results in the saving of a path alias.

2. The site is not put into maintenance mode while running updates

3. Another update saves a path alias in-between system_update_8803() and system_update_8804() (not confirmed but theoretically possible).

Proposed resolution

In path alias presave (probably system_path_alias_presave()) throw an exception if the schema version of system module is < 8804.

This will not allow the update to continue, but it should leave the site in a recoverable state, or at least inform the site admin why the update won't complete with a useful error message rather than a database error.

It was also 'save' a site that's not in maintenance mode, allowing the update to complete if non-update code is trying to save an alias.

Add a system.path_alias_schema_check PHP setting to allow to disable the schema check, if needed.

Remaining tasks

None

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

To avoid introducing data integrity issues and to provide meaningful information, an explicit schema check has been added before a path alias is saved making the save operation abort is the check fails.

Original report

In summary, system_update_8804() fails if any entity is saved before running it. See #15.

Hitting this error [error] SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '7142' for key 'PRIMARY': INSERT INTO {path_alias} when running updb after updating to 8.8.0.

I've updated path auto to 1.6-beta and didn't have any issues until running db updates.

I've trimmed the output as it was extremely long but this is the gist:

>  [error]  SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '7142' for key 'PRIMARY': INSERT INTO {path_alias} (id, revision_id, uuid, path, alias, langcode, status) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6), (:db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13), (:db_insert_placeholder_14, :db_insert_placeholder_15, :db_insert_placeholder_16, :db_insert_placeholder_17, :db_insert_placeholder_18, :db_insert_placeholder_19, :db_insert_placeholder_20), (:db_insert_placeholder_21, :db_insert_placeholder_22, :db_insert_placeholder_23, :db_insert_placeholder_24, :db_insert_placeholder_25, :db_insert_placeholder_26, :db_insert_placeholder_27), (:db_insert_placeholder_28, :db_insert_placeholder_29, :db_insert_placeholder_30, :db_insert_placeholder_31, :db_insert_placeholder_32, :db_insert_placeholder_33, :db_insert_placeholder_34), (:db_insert_placeholder_35, :db_insert_placeholder_36, :db_insert_placeholder_37, :db_insert_placeholder_38, :db_insert_placeholder_39, :db_insert_placeholder_40, :db_insert_placeholder_41), (:db_insert_placeholder_42, :db_insert_placeholder_43, :db_insert_placeholder_44, :db_insert_placeholder_45, :db_insert_placeholder_46, :db_insert_placeholder_47, :db_insert_placeholder_48), (:db_insert_placeholder_49, :db_insert_placeholder_50, :db_insert_placeholder_51, :db_insert_placeholder_52, :db_insert_placeholder_53, :db_insert_placeholder_54, :db_insert_placeholder_55), (:db_insert_placeholder_56, :db_insert_placeholder_57, :db_insert_placeholder_58, :db_insert_placeholder_59, :db_insert_placeholder_60, :db_insert_placeholder_61, :db_insert_placeholder_62), (:db_insert_placeholder_63, :db_insert_placeholder_64, :db_insert_placeholder_65, :db_insert_placeholder_66, :db_insert_placeholder_67, :db_insert_placeholder_68, :db_insert_placeholder_69), (:db_insert_placeholder_70, :db_insert_placeholder_71, :db_insert_placeholder_72, :db_insert_placeholder_73, :db_insert_placeholder_74, :db_insert_placeholder_75, :db_insert_placeholder_76), (:db_insert_placeholder_77, :db_insert_placeholder_78, :db_insert_placeholder_79, :db_insert_placeholder_80, :db_insert_placeholder_81, :db_insert_placeholder_82, :db_insert_placeholder_83), (:db_insert_placeholder_84, :db_insert_placeholder_85, :db_insert_placeholder_86, :db_insert_placeholder_87, :db_insert_placeholder_88, :db_insert_placeholder_89, :db_insert_placeholder_90), (:db_insert_placeholder_91, :db_insert_placeholder_92, :db_insert_placeholder_93, :db_insert_placeholder_94, :db_insert_placeholder_95, :db_insert_placeholder_96, :db_insert_placeholder_97); Array
> (
>     [:db_insert_placeholder_0] => 7142
>     [:db_insert_placeholder_1] => 7142
>     [:db_insert_placeholder_2] => 1a46dedc-e83e-4f5e-a7a4-8487c545985f
>     [:db_insert_placeholder_3] => /node/7
>     [:db_insert_placeholder_4] => /blog
>     [:db_insert_placeholder_5] => en
>     [:db_insert_placeholder_6] => 1
>     [:db_insert_placeholder_7] => 7143
>     [:db_insert_placeholder_8] => 7143
>     [:db_insert_placeholder_9] => 71daf56d-5afe-4fd5-a5de-27761591b517
>     [:db_insert_placeholder_10] => /node/2550
>     [:db_insert_placeholder_11] => /reports-resources/good-practice-guide/cost-value-tool
>     [:db_insert_placeholder_12] => en
>     [:db_insert_placeholder_13] => 1
>     [:db_insert_placeholder_14] => 7144
>     [:db_insert_placeholder_15] => 7144
>     [:db_insert_placeholder_16] => 5ce0ac09-fe56-4ccb-818f-8cf22f2b8570
>     [:db_insert_placeholder_17] => /node/2430
>     [:db_insert_placeholder_18] => /reports-resources/reports-parliament
>     [:db_insert_placeholder_19] => en
>     [:db_insert_placeholder_20] => 1
>     [:db_insert_placeholder_21] => 7145
>     [:db_insert_placeholder_22] => 7145
>     [:db_insert_placeholder_23] => 762dff5a-e605-4389-b138-5ca568688615
>     [:db_insert_placeholder_24] => /node/2441
>     [:db_insert_placeholder_25] => /reports-resources/fact-sheets
>     [:db_insert_placeholder_26] => en
>     [:db_insert_placeholder_27] => 1
>     [:db_insert_placeholder_28] => 7146
>     [:db_insert_placeholder_29] => 7146
>     [:db_insert_placeholder_30] => 66454aea-a7e8-4b39-8b6f-257b6a252004
>     [:db_insert_placeholder_31] => /node/2437
>     [:db_insert_placeholder_32] => /reports-resources
>     [:db_insert_placeholder_33] => en
>     [:db_insert_placeholder_34] => 1
>     [:db_insert_placeholder_35] => 7148
>     [:db_insert_placeholder_36] => 7148
>     [:db_insert_placeholder_37] => b18078bd-c2cf-4999-a528-b1bea3d3b6f4
>     [:db_insert_placeholder_38] => /node/2552
>     [:db_insert_placeholder_39] => /reports-resources/fact-sheet/strategic-audit-planning
>     [:db_insert_placeholder_40] => en
>     [:db_insert_placeholder_41] => 1
>     [:db_insert_placeholder_42] => 7149
>     [:db_insert_placeholder_43] => 7149
>     [:db_insert_placeholder_44] => acaddb8c-b4e0-4dc3-bd42-2dec2478784c
>     [:db_insert_placeholder_45] => /node/2553
>     [:db_insert_placeholder_46] => /reports-resources/fact-sheet/allocating-corporate-overhead-costs-services
>     [:db_insert_placeholder_47] => en
>     [:db_insert_placeholder_48] => 1
>     [:db_insert_placeholder_49] => 7150
>     [:db_insert_placeholder_50] => 7150
>     [:db_insert_placeholder_51] => 5f5e0bd8-7fe2-45a7-a84c-f07d513122d4
>     [:db_insert_placeholder_52] => /node/2554
>     [:db_insert_placeholder_53] => /reports-resources/fact-sheet/measuring-service-performance
>     [:db_insert_placeholder_54] => en
>     [:db_insert_placeholder_55] => 1
>     [:db_insert_placeholder_56] => 7151
>     [:db_insert_placeholder_57] => 7151
>     [:db_insert_placeholder_58] => 7cf642f4-404d-42da-a19d-6a3883b1e625
>     [:db_insert_placeholder_59] => /node/2432
>     [:db_insert_placeholder_60] => /about-us
>     [:db_insert_placeholder_61] => en
>     [:db_insert_placeholder_62] => 1
>     [:db_insert_placeholder_63] => 7152
>     [:db_insert_placeholder_64] => 7152
>     [:db_insert_placeholder_65] => a8b656f4-7c09-497e-b2ce-e15db378688c
>     [:db_insert_placeholder_66] => /node/2448
>     [:db_insert_placeholder_67] => /about-us/our-role
>     [:db_insert_placeholder_68] => en
>     [:db_insert_placeholder_69] => 1
>     [:db_insert_placeholder_70] => 7153
>     [:db_insert_placeholder_71] => 7153
>     [:db_insert_placeholder_72] => f58a7130-7b5b-44da-9ba5-2de5380846b0
>     [:db_insert_placeholder_73] => /node/2433
>     [:db_insert_placeholder_74] => /about-us/our-strategic-plan
>     [:db_insert_placeholder_75] => en
>     [:db_insert_placeholder_76] => 1
>     [:db_insert_placeholder_77] => 7154
>     [:db_insert_placeholder_78] => 7154
>     [:db_insert_placeholder_79] => f34b425d-db1e-453d-9186-b92b187c487a
>     [:db_insert_placeholder_80] => /node/2435
>     [:db_insert_placeholder_81] => /about-us/our-people
>     [:db_insert_placeholder_82] => en
>     [:db_insert_placeholder_83] => 1
>     [:db_insert_placeholder_84] => 7155
>     [:db_insert_placeholder_85] => 7155
>     [:db_insert_placeholder_86] => bcea73ee-947c-48c2-bfbd-db9bb3d20911
>     [:db_insert_placeholder_87] => /node/2454
>     [:db_insert_placeholder_88] => /about-us/our-values
>     [:db_insert_placeholder_89] => en
>     [:db_insert_placeholder_90] => 1
>     [:db_insert_placeholder_91] => 7156
>     [:db_insert_placeholder_92] => 7156
>     [:db_insert_placeholder_93] => 06a64279-b54b-42d7-ab50-6ba223a66cb1
>     [:db_insert_placeholder_94] => /node/2449
>     [:db_insert_placeholder_95] => /about-us/our-history
>     [:db_insert_placeholder_96] => en
>     [:db_insert_placeholder_97] => 1
> )
>  
>  [error]  Update failed: system_update_8804

Problem/Motivation

I am migrating wimleers.com from D7 to D8. It contains comments from the D5/D6 days. It looks like this:

Note that the language column is empty ('') for the upper half of the rows displayed, but set to the unspecified language code ('und') for the bottom half. The upper half are comments upgraded from D5/D6. The bottom half are comments created in D7.

When migrating comments with entity validation turned on (see #2745797: Add option to content entity destinations for validation and #3095456: [Plan] Discuss strategy for long term use of entity validation in the migration system), this causes lots of validation errors:

Also there's cases when comments become "orphaned" and sometimes they using language which disabled or deleted, so this cases also needs "fallback" to some undefined language - ref #3044158: Orphaned comments Error: Call to a member function getOwner()

Proposed resolution

Detect this edge case in \Drupal\comment\Plugin\migrate\source\d7\Comment and automatically fix it.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

TBD

Problem/Motivation

It seems like core/themes/bartik/templates/node.html.twig is referencing a Claro library instead of a Bartik library.

Proposed resolution

Reference a Bartik template instead of Claro.

Remaining tasks

Problem/Motivation

Classy will be moved to contrib during Drupal 9. After we have ensured that core themes (Bartik, Claro, Seven, Umami) are not using Classy templates or libraries, we can remove Classy as a base theme of these themes.

Proposed resolution

Change base theme from Classy to Stable. These themes will be made not dependent on Stable in a follow-up #3110855: Plan for removing dependency to Stable in Bartik/Seven/Claro/Umami.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Similarly to #3063887: Support PHPUnit 8 in Drupal 9, drop support for PHPUnit 7, this issue is about enabling testing with PHPUnit 9 in Drupal 9.

PHPUnit 7 support ended on February 7, 2020
PHPUnit 8 support ends on February 5, 2021
PHPUnit 9 support ends on February 4, 2022
PHPUnit 10 will be released in February, 2021.

In PHPUnit8 several assertions methods are deprecated for removal in PHPUnit9, for example:

• Using assertContains() with string haystacks is deprecated and will not be supported in PHPUnit 9. Refactor your test to use assertStringContainsString() or assertStringContainsStringIgnoringCase() instead.
• The @expectedException, @expectedExceptionCode, @expectedExceptionMessage, and @expectedExceptionMessageRegExp annotations are deprecated. They will be removed in PHPUnit 9. Refactor your test to use expectException(), expectExceptionCode(), expectExceptionMessage(), or expectExceptionMessageRegExp() instead.
• assertInternalType() is deprecated and will be removed in PHPUnit 9. Refactor your test to use assertIsArray(), assertIsBool(), assertIsFloat(), assertIsInt(), assertIsNumeric(), assertIsObject(), assertIsResource(), assertIsString(), assertIsScalar(), assertIsCallable(), or assertIsIterable() instead.
• assertArraySubset() is deprecated and will be removed in PHPUnit 9.
• getObjectAttribute() is deprecated and will be removed in PHPUnit 9.
• readAttribute() is deprecated and will be removed in PHPUnit 9.

Spun off issues

• #3108006: Replace assertInternalType() calls with dedicated methods
• #3113077: Replace assertContains() on strings with assertStringContainsString() or assertStringContainsStringIgnoringCase()
• #3113509: Replace @expectedException* annotations with dedicated methods

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Noticed by @webchick when on 9.0.x

This is because there is no new release newer than the dev release the user is currently on. At the time this was found there was no 9.x releases at all except dev snapshots. In this case the dev snapshot should not have been recommended because it is not in a supported branch.

Proposed resolution

Never recommend a release, dev snapshot or others, that is not in a recommend branch.

This will stop 9.1.x-dev snapshot from being recommended. It does not mean that a dev snapshot will never be recommended if it is in a supported branch and there are no other releases to recommend. This much more likely to happen contrib than it is in core.

This solution is the not the full solution to #3100115: The update module should recommend updates based on supported_branches rather than major versions majors because the user would still be shown and recommend the most recent full release in major and not a support branch.

Remaining tasks

None

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

None

Hi,

In my project, I have a view with an exposed form style : value required.
When I load the view page, there are not result, it's ok.
But, if I submit it with empty values, there are results.

I will upload a path soon.

Thanks for your responses.