Problem/Motivation

#2241655: EntityStorageInterface::create() should always create a "new" entity revealed some places where we have very interesting legacy code (and one new one!)

Part of this code can be found in file_copy() and file_save_data(), where a file or entity would always be created created even it already exists.

Proposed resolution

Stop doing that, in any way possible.

Remaining tasks

Find a way

User interface changes

API changes

Drupal adds tokens to forms for cross-site request forgery protection, but unconditionally skips doing so for anonymous users.

In most cases this does not matter (because if an anonymous user can submit a form, a potential attacker can just submit it themselves anyway), but in some cases where sites are displaying pages differently to different anonymous users (based on IP address or session information), it can matter, and it would be useful to have the option to add a form token in those cases.

This issue was discussed internally in the Drupal Security Team first, and we felt it could be a public issue due to its unusual nature and limited impact.

As for possible solutions, Heine, for example (who originally reported the issue related to this) suggested that if caching is disabled, that would be one case where we could easily add the token even if the form is being viewed by an anonymous user.

Problem/Motivation

The ::toUrl() method of any content entity seems to incorrectly fall back to the default language of the entity instead of falling back to the language provided by the Language Negotiation API.

In a default scenario (aka when enabling multiple languages on a vanilla Drupal installation) the Language Negotiation API would fall back to the user's current language, which would be reflected by the URL of the page the user is visiting (language domain or prefix).

Currently however, the Entity API is falling back to the default language of the entity, without consulting the Language Negotiation API, resulting in unexpected (and faulty IMHO) behaviour that any URL provided by ::toUrl() will have the language prefix removed (in the default scenario). Clicking on any link generated by ::toUrl() would undesirably change the user's current language. This problem was reported in the following issues:

• #2645922: Image field generates only default language URL when linking to corresponding entity.
• #2648288: StringFormatter generates links in wrong language when linking to entity
• #2798977: Wrong language handling in ImageFormatter when linking to entity
• #2883450: Missing url prefix on language neutral content
• #2889892: Responsive image field formatter links to the wrong entity translation
• #2961404: Wrong language handling in MediaThumbnailFormatter when linking

Proposed resolution

I think this should be solved by changing the way the language of the entity is resolved in the ContentEntityBase::toUrl() method. Instead of defaulting to the entities' default language, it should use Language Negotiation to see what it needs to do.

Remaining tasks

Write tests for all 'child' issues?

Problem/Motivation

"Assigned contexts were not satisfied" (error message) after deleting field used in layout

To replicate.

1. Add a field to a content type, text field will do.
2. Add a node of that type with a value in the added field.
3. Edit layout for said content type.
4. Display the new field.
5. Edit content type and delete field.
6. Edit layout, error thrown: "Assigned contexts were not satisfied"
7. Apply code change work around, see Proposed resolution below
8. Now edit the layout.. the block will be marked as "this block is no longer available".
9. Delete the block.
10. Save the layout.
11. Undo the workaround: Uncomment the code we commented out.

Proposed resolution

Workaround: edit core/lib/Drupal/Core/Plugin/Context/ContextHandler.php and comment out the line:
throw new ContextException('Assigned contexts were not satisfied: ' . implode(',', array_keys($mappings)));

Remaining tasks

TBC

User interface changes

n/a

API changes

n/a

Data model changes

n/a

Release notes snippet

TBC

Problem/Motivation

When adding new field in view, the notification message misses left-padding

Steps to reproduce:

1. Set Claro as default admin theme
2. Add a new view. Choose display Fields
3. Add a new field - a new notice message added in the popup "Selected: field name"

This also happens when hit "Add" buttons in any categories of the Views form, and ticking any checkbox on the pop-up.
Tested on both Drupal 8.8.2 and 8.9, Chrome, Firefox and IE on Windows.

Proposed resolution

Add left padding to the left of the notice message

Remaining tasks

Needs review, and align with the related issues #3066006

User interface changes

Yes. Minor interface changes - Add padding to notice as screenshot below

API changes

NA

Problem/Motivation

Drupal 8.8.x is not passing tests on PHP 7.4. PHP 7.4 released on November 28, 2019, a week before Drupal 8.8.0.

Proposed resolution

Fix code to not trigger errors in PHP 7.4 maintaining the same behaviour as PHP 7.0 to 7.3.

There is no release of easyrdf/easyrdf that supports PHP 7.4 in order to work around this we've done #3090017: Isolate test dependency on easyrdf/easyrdf to a single trait and then in this patch we provide a test only version of \EasyRdf_ParsedUri that is PHP 7.4 compatible. This code is only loaded and available at test time. Hopefully a release of easyrdf will happen sometime but it's not as important because it is now a test only dependency in Drupal 9.

Follow-up issues

• #3110815: \Drupal\hal\Normalizer\EntityReferenceItemNormalizer::normalize() tries to normalize entities that don't exist
• #3110839: Use of \Drupal\Core\Database\Install\Tasks::getFormOptions() in \Drupal\migrate_drupal_ui\Form\CredentialForm::buildForm() results in confusing description for prefix form element
• #3110972: Update easyrdf library or change \Drupal\Tests\rdf\Traits\RdfParsingTrait to not rely on it

Done:

• #3090145: Ensure that mixing array and Attribute objects in theme rendering is managed properly
• #3104420: PHP 7.4 Deprecated curly brace syntax for accessing array elements
• #3104421: PHP 7.4 deprecated reverse order of glue and pieces in implode
• #3095895: FieldTypePluginManager::getPluginClass() should throw an exception when called for a field type that doesn't exist
• #2830631: Remove code that tries to use _raw_variables for route argument resolution as it does not work
• #3089764: Updating translations does not clear the JS asset cache so new translations are not loaded
• Get a new release of composer/composer including https://github.com/composer/composer/pull/8296, see comment #33. #3075785: Update composer/composer to ^1.9.1
• Update to release 1.6.8 of mikey179/vfsstream, see comment #31. mikey179/vfsstream 2.0.x-dev requires PHP 7.2, so D8.8. cannot upgrade to it. #3091225: Require-dev mikey179/vfsstream ^1.6.8 in order to support PHP 7.4
• Get a new release of symfony/validator, including https://github.com/symfony/symfony/pull/34097:#3092112: Update symfony packages to 3.4.33 before 8.8.x beta
• #3089530: Tests of copied Doctrine code are not testing what we want them to test
• New release of Typo3's phar stream wrapper and of PEAR's Archive Tar #3088853: Require typo3/phar-stream-wrapper ^3.1.3 and pear/archive_tar ^1.4.8 in order to support PHP 7.4
• PHPunit 6 does not run on PHP 7.4 so we need to upgrade it - #2950132: Support PHPUnit 7 optionally in Drupal 8, while keeping support for ^6.5 - unfortunately PHP 7.0 (still supported in 8.8.0) does not run PHPUnit 7.
• egulias/email-validator - access array on null. Solvable updating to latest version. #3039611: Update core PHP dependencies for 8.8.x
• mikey179/vfsstream - use of deprecated curly brackets for array access. Solvable updating to latest version.
  #3039611: Update core PHP dependencies for 8.8.x

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Drupal [insert version] is now compatible with PHP 7.4 and testing on PHP 7.4 is part of the regular automated test suite.

Problem/Motivation

Layout plugins are great, but they don't have the ability to interact with the context API

E.g. a layout plugin might define one set of regions for a given node, but different regions for another node based on some conditions.

Proposed resolution

Add support for context-aware layout plugins

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

When I add a numeric contextual filter in Views there is an option to Allow Multiple Values with the description 'If selected, users can enter multiple values in the form of 1+2+3 (for OR) or 1,2,3 (for AND).'

However, regardless of whether I use ',' or '+' I get the same result (OR).

Taking a look at NumericArgument.php:

public function query($group_by = FALSE) {
    $this->ensureMyTable();

    if (!empty($this->options['break_phrase'])) {
      $break = static::breakString($this->argument, FALSE);
      $this->value = $break->value;
      $this->operator = $break->operator;
    }
    else {
      $this->value = [$this->argument];
    }

    $placeholder = $this->placeholder();
    $null_check = empty($this->options['not']) ? '' : " OR $this->tableAlias.$this->realField IS NULL";

    if (count($this->value) > 1) {
      $operator = empty($this->options['not']) ? 'IN' : 'NOT IN';
      $placeholder .= '[]';
      $this->query->addWhereExpression(0, "$this->tableAlias.$this->realField $operator($placeholder)" . $null_check, [$placeholder => $this->value]);
    }

I see that we check for the 'break string' and set $this->operator correctly to 'and' or 'or'. But then we never again do anything with $this->operator. We just set the $operator to either IN or NOT IN, ignoring the break string.

Follow-up to #2225775: Migrate Drupal 6 core node translation to Drupal 8

Problem/Motivation

In D8, a node revision has data for all languages. In D6 and D7, each node revision has data for just one language. This means currently D6 -> D8 and D7 -> D8 migrations yield a revision history where each node revision has only one language present, even if previous revisions had translations. This is strange and likely to confuse users.

Priority is given to the D7 migration because the D6 one might be effected by the term node migrations.

This is for migrating core translation revisions, migrating revisions for entity translation is now being done in #3076447: Migrate D7 entity translation revision translations to D8. It is intended that this issue is completed first and then the approach used here is also used for entity translations.

The following notes use the term 'master' which was the original term what is now the 'complete' node migration.

Meeting notes

Things to consider, taken from notes of meeting with alexpott, Gábor Hojtsy, heddn, mikelutz and quiteone

1. Migration dependencies
   • Possible: easy to do
   • BC concerns: none
   • BC what about contrib? Commerce / metatag
   • Possible incompatible
2. How do we figure out you need the new complex master migration?
   • Possible: moderate to do
   • BC concerns: none
   • Don’t effect expose new d*_node_master unless explicitly enabled to existing sites
   • This handles incremental, no UI option available to enable
   • For new installs, give an option to upgraders to enable disable the new d*_node_master migration and use the old method.
3. What about migration lookups on dn_node etc.
   • Possible: easy to do
   • BC concerns: none
4. What about incremental migrations that have already begun
   • Not allowed. You can only use the new approach on a site that has not run migrations. So we need some of flag where existing installs use the old migrations.
5. Contrib/Custom
6. Does it make sense to use d*_node_master instead of d*_node migrations?

Proposed resolution

The current focus is to get the D7 version working and then move those changes to D6.

Using the existing method where the final revision is migrated first doesn't work instead the revisions need to be migrated in order. The first proof of concept patch to show this is in #121, thanks to mikelutz. This new approach is called the Complete node migration and the migrations and files use that name.

"Removing it [the classic node migrations] will break the whole ecosystem. Deprecating it means that it’s not used anymore which in and of itself will break the eco system, and for what benefit? To remove it in Drupal 10, a year after D7 is EOL? At that point we are looking at deprecating the entire D7 upgrade path anyway (Probably for removal in 11, not 10) We really don’t want to break the migration ecosystem right now at this critical time when we are trying to get everyone off of D7 in the next 18-20 months". by mikelutz in #migration on Drupal Slack). See #3109819: [PP-2] Deprecate classic node migration plugin in Drupal 9 for removal in Drupal 10 for discussion of when deprecation of classic node migrations would happen.

Run Complete or classic node migrations
However, the Complete approach doesn't integrate with the current migrations, now being called Classic, that is the one either runs the existing node migrations or the new complete one, not both. Choosing between the two methods is done at run time by checking the node migration map tables in MigrationConfigurationTrait() and migrate_drupal_migration_plugins_alter(). In the trait the classic method is selected if any of the classic node migrate_map tables has data (using processedCount) and in the plugins_alter it is selected if any classic node migrate_map exists and there are no complete node migrate_maps.

The selection of node migration method also allows tests to decide which method to use. The test does this by adding either 'node_migrate_classic' or 'node_migrate_complete' to $modules.

Altered migrations
There are several migrations that use migration_lookup on the node migration. The processes and dependencies for these are altered when the complete node migration is being run. The changes include new processes to convert the 3 destination IDs returned by complete node to the correct destination ID expected when using the classic migration.
The migrations altered are: d6_term_node, d6_term_node_revision, d6_term_node_translation, d6_comment, d6_url_alias,d7_comment, d7_url_alias, statistics_node_counter, node_translation_menu_links.

Incremental migrations
For the core UI, if map tables for the classic mode migrations exist and at least one has a row then the classic migrations will run and not the complete node migrations. This is determined at run time. Therefor, existing incremental migration should continue to function.

From the original IS
D6 and D7 node revisions do not directly indicate which other translated node revisions they are associated with. But we can attempt to guess this, based on the order of revisions.

Remaining tasks

Fix tests, add comments
Review

For Reviewers

• All level of code reviews welcome.
• There are BC issues raised in meeting notes, above

For Testers

1. Use the lastest patch patch in this issue.
2. There are instructions in the Issue summary of the META issue #2208401: [META] Stabilise Migrate Drupal Multilingual module

From #55

For developers

1. Make this work with a multilingual source and a non multilingual source
2. Discuss and document implications for drush, especially drush migrate-upgrade --all
3. Make sure the d6 and d7 tests includes testing a fields on each revision
4. Handle the case where the vid of the first revision is higher the vid of a later revision. This is true for both d6 and d7.
5. Make sure that the use of migration_tag 'translation' is documented. It is used in
   • d6_node_translation.yml
   • d7_node_entity_translation.yml
   • d7_node_translation.yml
   • d7_node_revision_translation.yml
   • d7_user_entity_translation.yml
   • d7_taxonomy_term_entity_translation.yml/li>
   • d7_comment_entity_translation.yml
   • d6_node_revision_translation.yml
6. Make sure that the source plugin 'translation' property is documented
7. Make sure that the destination plugin 'translations' property is documented

• What are the steps required to reproduce the bug?

  Upgrade to drupal/core:8.8.2 using composer and try to access the site

• What behavior were you expecting?

  Site works correctly

• What happened instead?

  I get a WSOD and the following error in the watchdog:

  drupal-watchdog staging-27666 Feb 17 22:13:07 staging-27666 nscportaldev[10552]: http://nscportaldev.prod.acquia-sites.com|1581977587|php|189.4.82.42|http://nscportaldev.prod.acquia-sites.com/user/login||0||Error: Class 'StreamWrapperInterface' not found in file_create_url() (line 258 of /mnt/www/html/nscportaldev/docroot/core/includes/file.inc) #0 /mnt/www/html/nscportaldev/docroot/core/lib/Drupal/Core/Asset/JsCollectionRenderer.php(77): file_create_url('public://langua...') #1 /mnt/www/html/nscportaldev/docroot/core/lib/Drupal/Core/Render/HtmlResponseAttachmentsProcessor.php(324): Drupal\Core\Asset\JsCollectionRenderer->render(Array) #2 /mnt/www/html/nscportaldev/docroot/core/lib/Drupal/Core/Render/HtmlResponseAttachmentsProcessor.php(161): Drupal\Core\Render\HtmlResponseAttachmentsProcessor->processAssetLibraries(Object(Drupal\Core\Asset\AttachedAssets), Array) #3 /mnt/www/html/nscportaldev/docroot/core/lib/Drupal/Core/EventSubscriber/HtmlResponseSubscriber.php(45): Drupal\Core\Render\HtmlResponseAttachmentsProcessor->processAttachments(Object(Drupal\Core\Render\HtmlResponse)) #4 [internal function]: Drupal\Core\EventSubscriber\HtmlResponseSubscriber->onRespond(Object(Symfony\Component\HttpKernel\Event\FilterResponseEvent), 'kernel.response', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher)) #5 /mnt/www/html/nscportaldev/docroot/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\FilterResponseEvent), 'kernel.response', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher)) #6 /mnt/www/html/nscportaldev/vendor/symfony/http-kernel/HttpKernel.php(191): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.response', Object(Symfony\Component\HttpKernel\Event\FilterResponseEvent)) #7 /mnt/www/html/nscportaldev/vendor/symfony/http-kernel/HttpKernel.php(173): Symfony\Component\HttpKernel\HttpKernel->filterResponse(Object(Drupal\Core\Render\HtmlResponse), Object(Symfony\Component\HttpFoundation\Request), 1) #8 /mnt/www/html/nscportaldev/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1) #9 /mnt/www/html/nscportaldev/docroot/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #10 /mnt/www/html/nscportaldev/docroot/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #11 /mnt/www/html/nscportaldev/vendor/asm89/stack-cors/src/Asm89/Stack/Cors.php(49): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #12 /mnt/www/html/nscportaldev/docroot/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Asm89\Stack\Cors->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #13 /mnt/www/html/nscportaldev/docroot/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #14 /mnt/www/html/nscportaldev/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #15 /mnt/www/html/nscportaldev/docroot/core/lib/Drupal/Core/DrupalKernel.php(694): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #16 /mnt/www/html/nscportaldev/docroot/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #17 {main}. request_id="v-ad0b5bfe-51d2-11ea-9b48-8347ca62cc1f"

The batch API should be a pluggable service so it could be swapped out or mocked for testing.

The following will need to be completed:

• #2959723: Create an interface and initial class for the batch processor service
• Migrate the existing functionality into the new service class. This will be a few different tickets.
• Change the code in core to use the service instead of calling the current functions. This will be a few different tickets.

#1797526: Make batch a wrapper around the queue system

Done:

• #2401797: Introduce a batch builder class to make the batch API easier to use

Problem/Motivation

When you install the Umami profile, the Layout Builder and Layout Discovery modules are enabled by default. However, currently only the recipes content type is using layout builder. This means that there's some disparity on how we expect users to make changes to the page layout of recipes versus articles and basic page.

Proposed resolution

Enable layout builder by default on all content types to make it easier for users to modify the layout of these pages. This ensures that new-to-Drupal users have a good experience and see how powerful Drupal is.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

When cancelling a user account, an administrator has the option to require email confirmation to cancel the account. This can be optionally checked.

The user in question receives a unique link to then cancel their account. This does not work correctly for said user if they are logged out of the CMS, instead they see a 403 page. However, when logged into the CMS as the user in question the link works correctly and their account is disabled.

Proposed resolution

Remaining tasks

#3025642: do something with the exception caught in DateTimeComputed::getValue() revealed this bug.

If a date field is empty, trying to get the date computed property on it causes DateTimeComputed to try to create a date object, which causes DrupalDateTime to throw an exception. Currently that exception is caught, but the patch at #3025642: do something with the exception caught in DateTimeComputed::getValue() re-throws it.

It doesn't make sense to attempt to create a date if we know there's no source value anyway, so DateTimeComputed should return early in that case.

Updated: Comment #1

Problem/Motivation

Routes now uses $module.foo as the route names, so to be more consistent use the same kind of pattern for local actions.

Proposed resolution

use the route name + ".action" as each ID. Keeping the ID distinct from the route name will help avoid mistaken assumptions (especially in tests).

Before

custom_block_type_add:
   route_name: custom_block.type_add
   title: 'Add custom block type'
   appears_on:
     - custom_block.type_list

After 1 (the one in the last patch)

custom_block.type_add.action:
   route_name: custom_block.type_add
   title: 'Add custom block type'
   appears_on:
     - custom_block.type_list

After 2

custom_block.type_add:
   route_name: custom_block.type_add
   title: 'Add custom block type'
   appears_on:
     - custom_block.type_list

After 3

-
   plugin_id: custom_block.type_add
   route_name: custom_block.type_add
   title: 'Add custom block type'
   appears_on:
     - custom_block.type_list

Remaining tasks

User interface changes

API changes

Related Issues

#2095613: Convert all plugin IDs in local_tasks.yml to 'module_name.foo_bar' naming convention to match routing convention

Unused variable $user in RegisterForm.php
Unused variable $key. ProfileFieldOptionTranslation.php

The page that looks visually closer to /admin/reports is /admin/structure which has menu items alphabetically sorted.

However, /admin/reports order is not making sense (at least to my eyes).

Maybe this is by design?