Problem/Motivation

drupal_check_module() is procedural code that relies on a number of external services. We should convert this to a service to make it more testable and maintainable.

Steps to reproduce

Proposed resolution

Deprecate drupal_check_module() and replace with \Drupal\Core\Extension\RequirementsChecker::checkModuleRequirements()

Remaining tasks

User interface changes

API changes

drupal_check_module() is deprecated and replaced with \Drupal\Core\Extension\RequirementsChecker::checkModuleRequirements()

Data model changes

Release notes snippet

Problem/Motivation

In IRC the other day I was chatting with @realityloop who was getting some notices on admin pages because a module installed on his site was incorrectly returning from hook_requirements.
The module didn't provide a title in the return, and this was causing a large number of warnings, because by default we assume this is present in a uasort call.

Proposed resolution

Replace the return value of hook_requirements with value objects. This will enforce the structure of the return in a way that an array cannot.
Implement \ArrayAccess for BC sake

Remaining tasks

Remaining tasks:

• Decide if we should just enforce required properties by using constructor args
• Ensure sorting works
• Replace usages of requirements arrays

User interface changes

API changes

Addition of a new value object

Data model changes

Problem/Motivation

Vertical tabs are not working optimally in forced colors mode. See videos for reference: https://youtu.be/6j0Z62R2bEA and https://youtu.be/VtWjPn5p5-w.

Steps to reproduce

1. Begin by identifying the specific issues with vertical tabs in forced colors mode.
2. Ensure that your testing covers a variety of browsers and devices to identify potential cross-browser or cross-platform issues.
3. Work with the development team to create prototype solutions for the identified issues.
4. Perform thorough accessibility testing to ensure that the improved vertical tabs meet the needs of users relying on forced colors mode.
5. Based on user feedback, make necessary adjustments to the prototype solutions. This may involve refining design elements, improving navigation, or addressing any unforeseen issues.

User interface changes

-Allow users to adjust font sizes within vertical tabs to accommodate varying visual preferences.
-Provide users with the option to customize the color schemes of vertical tabs, allowing them to choose colors that suit their preferences and improve visual clarity.
-Optimize spacing and padding around tab elements to improve touch interaction and ensure that users can easily interact with tabs using both mouse and touch input.

This was discovered by @bnjmnm while working on #3080100: Assess accessibility of Claro in High Contrast AKA forced colors mode

Problem/Motivation

As part of #3221796: [META] Modernise file upload logic we identified that file locking occurs in 3 places:

• \Drupal\jsonapi\Controller\TemporaryJsonapiFileFieldUploader
• \Drupal\file\Plugin\rest\resource\FileUploadResource
• \Drupal\ckeditor5\Controller\CKEditor5ImageController

However, it doesn't occur in file_save_upload() which is currently the only code using FileUploadHandler.

Steps to reproduce

Proposed resolution

Add lock support to FileUploadHandler to make migrating those other services over easier.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Split out from #2909472: Add value objects to represent the return of hook_requirements we should create enums for RequirementSeverity and RequirementPhase as a first step.

Steps to reproduce

Proposed resolution

Create enums for RequirementSeverity and RequirementPhase.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

CKEditor breaks when "Source"/Source editing button is added and "Manually editable HTML tags" are specified

Steps to reproduce

1. Define text format
2. Enable some of the buttons / features
3. Enable "Source" button
4. Save text profile and it works
5. Now edit again and add some "Manually editable HTML tags" in the "Source editing" plugin settings
6. One can't save profile settings with error "The current CKEditor 5 build requires the following elements and attributes: LIST OF SOME TAGS The following elements are missing: LIST OF SOME OTHER TAGS"

Additionally, this happens if such text format was specified in 10.1.x, where this worked perfectly, but once updated to 10.2.x, pages using text format using source button with manually editable HTML tags will break with tags listed under LIST OF SOME OTHER TAGS" will not render and the pages look broken

In the docs for drupal_attach_tabledrag() it mentions

In a more complex case where there are several groups in one column (such as the block regions on the admin/structure/block page), a separate subgroup class must also be added to differentiate the groups.

I've been trying to get that working with minimal additional JS and I think I might've uncovered some bugs in tabledrag. When trying to use subgroups I was finding that dragging a row from one group into the other didn't seem to copy the subgroup class across correctly.

In #2489826: tabledrag is broken (dcf9ab4) some changes were made to some tabledrag jQuery selectors. I think the changes were meant to be functionally equivelent, just a little more efficient, eg:

-    var $indentationLast = $item.find('td').eq(0).find('.js-indentation').eq(-1);
+    var $indentationLast = $item.find('td:first-of-type').find('.js-indentation').eq(-1);

IIUC the starts of both of those lines basically do the same thing - grab the first td. But there are some other situations where I think the behaviour changed, and I wonder if that was unintentional.

1. --- a/core/misc/tabledrag.js
   +++ b/core/misc/tabledrag.js
   @@ -718,7 +718,7 @@
            // take into account hidden rows. Skip backwards until we find a draggable
            // row.
            while ($row.is(':hidden') && $row.prev('tr').is(':hidden')) {
   -          $row = $row.prev('tr').eq(0);
   +          $row = $row.prev('tr:first-of-type');
              row = $row.get(0);
            }
            return row;
   

   In this case $row.prev('tr:first-of-type') will only return a value if the previous row is also the first row in the table, rather than iterating each previous row. I've reverted that in the patch, but I wonder if the whole while block is redundant: $row is set from $(this.table.tBodies[0].rows).not(':hidden') at the start of findDropTargetRow(). Should it just be removed?

2. @@ -766,9 +766,9 @@
        }
        // Siblings are easy, check previous and next rows.
        else if (rowSettings.relationship === 'sibling') {
   -      $previousRow = $changedRow.prev('tr').eq(0);
   +      $previousRow = $changedRow.prev('tr:first-of-type');
          previousRow = $previousRow.get(0);
   -      var $nextRow = $changedRow.next('tr').eq(0);
   +      var $nextRow = $changedRow.next('tr:first-of-type');
          var nextRow = $nextRow.get(0);
          sourceRow = changedRow;
          if ($previousRow.is('.draggable') && $previousRow.find('.' + group).length) {
   

   This is what caused the original problem and prevented the weight subgroup class being copied over when moving a row into a different group. As before it's looking for the previous row using first-of-type and in this case it means the source row for sibling relationships isn't correctly set. The patch should fix and test this.

3. @@ -811,7 +811,7 @@
            // Use the first row in the table as source, because it's guaranteed to
            // be at the root level. Find the first item, then compare this row
            // against it as a sibling.
   -        sourceRow = $(this.table).find('tr.draggable').eq(0).get(0);
   +        sourceRow = $(this.table).find('tr.draggable:first-of-type').get(0);
            if (sourceRow === this.rowObject.element) {
              sourceRow = $(this.rowObject.group[this.rowObject.group.length - 1]).next('tr.draggable').get(0);
            }
   

   The original line found the first row with the draggable class but the modified version looks for a row which is both the first and has the draggble class. This causes an issue with field_group on a table with a non-draggable first row: #3085858: Drag and drop acts weird, sometimes not resetting the parent, or even clearing the region value. The patch should fix and test this.
   

This is my first time touching tabledrag so careful review welcome :p

Also it's quite an old commit that introduced this, I know tabledrag is used in lots of places, so I'm not sure if I'm just missing something obvious... (:

Remaining tasks

• Decide whether the first JS block above should be removed entirely.
• Should this be split up into multiple tickets with more meaningful names?

Problem/Motivation

After upgrading to 10.2.0-beta1 from the latest 10.1.6, we're encountering the following error on any page load:

Uncaught PHP Exception TypeError: "Drupal\\Core\\Menu\\MenuActiveTrail::__construct(): Argument #1 ($menu_link_manager) must be of type Drupal\\Core\\Menu\\MenuLinkManagerInterface, Drupal\\Core\\DependencyInjection\\Container given, called in /core/lib/Drupal/Component/DependencyInjection/Container.php on line 259" at /core/lib/Drupal/Core/Menu/MenuActiveTrail.php line 44

This does not occur on 10.2.0-alpha1.

Steps to reproduce

Upgrade to 10.2.0-beta1, attempt to access any page.

Proposed resolution

The change made in #3397173: Convert both BookNavigationCacheContext and MenuActiveTrailsCacheContext to use lazy services appears to have caused this, removing lazy: true from menu.active_trail resolves the issue, but defeats the purpose of the change.

Problem/Motivation

In #2336597: Convert path aliases to full featured entities we added a BC layer to kernel tests that removes path_processor_inbound and path_processor_outbound tags from the path_alias.path_processor definition. This is a great source of confusion when writing kernel tests that rely on path aliases.

Steps to reproduce

Write a kernel test as per the MR that boils down to this:

EntityTest::create(['id' => 1])->save();
$this->createPathAlias('/entity_test/1', '/entity-alias');
$entity = EntityTest::load(1);
$this->assertSame('/entity-alias', $entity->toUrl()->toString());

Watch it fail.

Remove this from KernelTestBase::register

if ($container->hasDefinition('path_alias.path_processor')) {
  // The alias-based processor requires the path_alias entity schema to be
  // installed, so we prevent it from being registered to the path processor
  // manager. We do this by removing the tags that the compiler pass looks
  // for. This means that the URL generator can safely be used within tests.
  $container->getDefinition('path_alias.path_processor')
    ->clearTag('path_processor_inbound')
    ->clearTag('path_processor_outbound');
}

Watch it pass.

Proposed resolution

Remove code that disabled path processing, ensure tests that use path alias install its schema.

See #10 for the history.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Updated: Comment #122
See details about the Usability Study at http://groups.drupal.org/node/163894

This issue contains suggestions and attempts to modify the display of these to fields to make it clear to the user how to 'update' the account password.

Problem/Motivation

During a usability test, users logged into Drupal could not determine how to update their account password. Users did not understand that the existing 'password' and 'confirm password' fields on the user/edit page served the purpose of a password update.

Proposed resolution

Proposed resolution from #176 and #177:
It might be simpler and lead to better user experience if we create a separate form for changing the password and e-mail address.
Now we have 3 different forms instead of one single form doing a lot of stuff at one single place.

Edit Profile form:-

Change password form:-

Change email form:-

Previous/alternative proposal summary

1. Change the name of the field to "New Password"
Suggested in #11
2. Move password fields to the end of the form
3. (rejected) Move password fields into a fieldset
See #19. Concern is that users do not put in the old password when changing a password, so they have to fill out the form again.
4. (rejected) Move password fields into a collapsed fieldset
Same concerns as for fieldset.
5. Move everything but password, email, and username fields to their own tab
See #9
6. Modal: On submit, if either the email or password field has changed, a modal appears prompting the user to fill in the previous password field.
See #70

Remaining tasks

Review patch in #170, decide if this solution works. If not asses other solutions, e.g. #70.

Problem/Motivation

If a module logs an error and one of the context are not convertible into a string, dblog the page crashes with an exception. To recover from this issue I have first truncated the dblog table and than cleared all caches as the truncate was not enough.

Proposed resolution

LogMessageParser::parseMessagePlaceholders(), which is called by the dblog and syslog loggers, should exclude any non-stringable placeholders, as the PSR-3 logging standard states that "the array can contain anything. Implementors MUST ensure they treat context data with as much lenience as possible. A given value in the context MUST NOT throw an exception nor raise any php error, warning or notice."

Proposed in #21 raise an exception when trying to write a log with placeholders that cannot converted into strings. Also, if possible, try to indicate where this error was produced as part of the raised exception. #52

Remaining tasks

None

User interface changes

None

API changes

None

Copied from https://security.drupal.org/node/166626 which was reviewed and determined it was OK to make it public as the impact is minimal. The reporter was via email and did not provide details on their d.o account to be able to give them credit.

Problem/Motivation

The "initial login link" that a user gets in their email when registering for an account on a site that allows anonymous registration without approval has a few interesting elements:

1. It never expires - while the password reset link expires in 24 hours.
2. The default robots.txt allows crawling these links

That combination means that if the url gets "leaked" somehow it is very easy to use a search engine to find unused login links.

Note that this issue seems to primarily affect accounts created using disposable email services where the inbox contents become crawlable on the internet.

Proposed resolution

A simple change is to update robots.txt to disallow crawling of /user/reset/*

A behavior breaking change that is worthwhile would be to validate the initial login link is being used within a certain period of time, perhaps 2 days. (The current patch makes it have the same value as the 'password_reset_timeout' configuration value, which currently is 24 hours and has no UI in Core. Is there ar reason to differentiate them?)

Remaining tasks

Lots.

User interface changes

robots.txt disallows access to password reset links.
(maybe) the initial login link verifies a timestamp.

API changes

$expiration_date for UserPasswordResetForm is now effectively mandatory. (Is this an API change? I'm not sure. --roderik)

Data model changes

None.

Release notes snippet

Links in e-mails sent out to newly created users are now valid for a limited time only, like links in "password reset" e-mails already are.

Problem/Motivation

This issue originally surfaced in Entity Browser where, in certain configurations used with Inline Entity Form or Layout Builder, there can be unexpected results:

#2764889: Entity Browser widget loses selected images in inline entity form
#3046416: Remove button conflict wrong triggering element
#3104901: Entity Browser used in a entity referenced field of a layout builder custom block is not working

But it seems the underlying issue may actually be a core FormBuilder bug.

Comment #7 in #2764889: Entity Browser widget loses selected images in inline entity form documents what's happening:

I have investigated further what makes inconsistent form state -> and I have ended in IEF module.

So what is going on (in "short"): for example when remove button is pressed without IEF

1. in processing of action (FormBuilder::processForm()), rebuild is triggered -> FormBuilder::rebuildForm() and then FormBuilder::retrieveForm() -> that will execute EntityReferenceBrowserWidget::formElement()
2. setting of new state is done in EntityReferenceBrowserWidget::formElement()
3. and after FormBuilder::retrieveForm() in FormBuilder::rebuildForm() form state will be saved (cached)
4. so we end with correct form state (when I say form state I mean form state relevant for Entity Browser)

Other case: for example when remove button is pressed within IEF

1. in processing of action (FormBuilder::processForm()), rebuild is triggered -> FormBuilder::rebuildForm() and then FormBuilder::retrieveForm() -> that will execute creating of IEF form and -> it will generate #process callback for inner form
2. and after FormBuilder::retrieveForm() in FormBuilder::rebuildForm() form state will be saved (cached)
3. after saving of form state inside FormBuilder::rebuildForm() -> FormBuilder::doBuildForm() will be triggered. That will pick up all defined #process callbacks and execute them
4. execution of defined #process callback will execute EntityReferenceBrowserWidget::formElement() and new form state will be set
5. But!!! Problem is that form state is already saved (cached) and form state set during execution of #process callback will not be saved and actions after that will have wrong form state

Inline block forms in Layout Builder work similarly to IEF, in that the entity form is built in a #process callback (see \Drupal\layout_builder\Plugin\Block\InlineBlock::blockForm()

The root issue seems to be that in \Drupal\Core\Form\FormBuilder::rebuildForm(), the form and form state is cached before the call to doBuildForm, where the #process callbacks are run. If we compare how the form cache is set in rebuildform() to processForm, we can see that in the latter method, caching is done after the doBuildForm() call, using a copy of the form array created before the doBuildForm().

While the identified issues are specific to Entity Browser, this could affect any code where form state storage is updated in #process callbacks.

Steps to reproduce

For an example with Entity Browser and Layout Builder, see #3104901: Entity Browser used in a entity referenced field of a layout builder custom block is not working

Steps to reproduce:

1. Create a custom block type with two referenced entity fields and select an entity browser to select the referenced entities for each field
2. Create a content with layout builder manage display
3. In the layout view of the content, add a custom block of the previous custom block type, select entities with the entity browser modal display for the two fields and save de block
4. Edit the custom block and try to remove the selected entites of the two fields and select new entities
5. At some point it is not possible to add or remove entities and the entity browser modal display is not showing any more

Proposed resolution

Use similar form caching code in rebuildForm() to what is done in processForm():

1. Save a copy of the form array before doBuildForm() call
2. Call doBuildForm()
3. Cache if necessary with unprocessed copy of form array saved before doBuildForm()
4. return built and processed form array

Remaining tasks

Write patch and tests.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

When an internal URL that contains an array query parameter is entered into a core Link field, those query parameters are duplicated when rendered. For example an entered value of /search?f[0]=test:facet would be rendered as /search?f[0]=test:facet&f[1]=test:facet (the characters are decoded for readability).

The value of the URL does not change. This only affects the rendered HTML.

This issue does not seem to affect external URLs.

Steps to reproduce

Here are the steps to reproduce this issue on the vanilla standard profile:

1. Add a link field to the Article content type.
2. Create a new Article node. In the article's link field enter a value with an internal URL like /?a[0]=test.
3. View the new article node.

Expected result: The rendered link will have an href attribute containing the URL /?a[0]=test.
Actual result: The rendered link has an href attribute containing the URL /?a[0]=test&a[1]=test.

Of course, the actual URLs will have encoded query strings. Note that if you do not enter a value for the link field's title, then the title will be the correct URL, but the href will be incorrect.

MRs

MR 5333 is for 11.x
MR 798 can be closed

Proposed resolution

Unset the query key from the URL options array before rendering.

Remaining tasks

1. Verify the number of test permutations as mentioned in comment 13.5.
2. Review

User interface changes

API changes

Data model changes

Original report

Checking D7 Link #2333119: Output broken when using array parameters in query on D8 there are some issues with array query parameters.

- '?a[]=0&b[]=0&b[]=1'
- '?a[0]=0&b[0]=0&b[1]=1',

their link when viewing are rendered (URL encoding removed for readability) with duplicated content.

a[0]=0&a[1]=0&b[0]=0&b[1]=1&b[2]=0&b[3]=1

The title rendering is unreadable including for other tests (which is probably a different issue?)

- '?filter[a][b]=c',
- '?a[b[c]]=d',

Problem/Motivation

Unexpected duplicate selector ".dropbutton-wrapper.open .dropbutton__toggle::before" and double "margin-top" with different values, first used at line 234.

Line: 234
  .dropbutton-wrapper.open .dropbutton__toggle::before {
    margin-top: calc(0.5625rem / (2 * 1.41429));
    transform: translate(50%, -50%) rotate(315deg);
  }
...
Line: 251
  .dropbutton-wrapper.open .dropbutton__toggle::before {
    margin-top: calc(0.4375rem / (2 * 1.41429));
  }

Steps to reproduce

File: core/themes/claro/css/components/dropbutton.css

Proposed resolution

Line: 234
  .dropbutton-wrapper.open .dropbutton__toggle::before {
    margin-top: calc(0.4375rem / (2 * 1.41429));
    transform: translate(50%, -50%) rotate(315deg);
  }

Remaining tasks

no

User interface changes

no

API changes

no

Data model changes

no

Release notes snippet

Problem/Motivation

In #3313355: Allow the database query log to be dispatched as log events we added events to trace the start of a statement execution and it successful end, but did not cover the case of statement execution failure.

At the moment, a failed statement execution results in no end events being dispatched.

Proposed resolution

Either add another event for execution failure, or change the statement execution end event to also carry the result of the execution.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

As mentioned in the parent issue #3238306: [META] Where possible, refactor existing jQuery uses to vanillaJS to reduce jQuery footprint, we are working towards reducing our jQuery footprint. One of the ways to accomplish this is to reduce the number of jQuery features used in Drupal core. We have added eslint rules that identify specific features and fail tests when those features are in use.

There are (or will be) individual issues for each jQuery-use eslint rule. This one is specific to jquery/no-each, which targets the jQuery each function.

Steps to reproduce

Proposed resolution

Remaining tasks

• In core/.eslintrc.jquery.json Change "jquery/no-each": 0, to "jquery/no-each": 2, to enable eslint checks for uses of jQuery .each(). With this change, you'll be able to see uses of the undesirable jQuery feature by running yarn lint:core-js-passing from the core directory
• Add the following lines to core/scripts/dev/commit-code-check.sh so the DrupalCI testing script can catch this jQuery usage on all files, not just those which have changed
  

  # @todo Remove the next chunk of lines before committing. This script only lints
  #  JavaScript files that have changed, so we add this to check all files for
  #  jQuery-specific lint errors.
  cd "$TOP_LEVEL/core"
  node ./node_modules/eslint/bin/eslint.js --quiet --config=.eslintrc.passing.json .
  
  CORRECTJQS=$?
  if [ "$CORRECTJQS" -ne "0" ]; then
    # No need to write any output the node command will do this for us.
    printf "${red}FAILURE ${reset}: unsupported jQuery usage. See errors above."
    STATUS=1
    FINAL_STATUS=1
  fi
  cd $TOP_LEVEL
  # @todo end lines to remove

  Add the block about 10 lines before the end of the file, just before if [[ "$FINAL_STATUS" == "1" ]] && [[ "$DRUPALCI" == "1" ]]; then, then remove it once all the jQuery uses have been refactored.

• If it's determined to be feasible, refactor those uses of jQuery .each() to use Vanilla (native) JavaScript instead.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

MySQL 8 has a sql_generate_invisible_primary_key (GIPK) mode which, if enabled, creates an invisible primary key for tables that do not have one. If a Drupal module later calls the addField() method to add a primary key to a table that was created in GIPK mode, the MySQL driver will need to drop the invisible column in the same statement. There is already a clause that drops any already-existing primary key, but that's not quite enough in this mode.

Steps to reproduce

1. Use a recent version of MySQL 8
2. Set sql_generate_invisible_primary_key=ON either globally or in the session (requires permission to do so)
3. Run:
   

   Drupal::database()->schema()->createTable('deleteme', ['fields' => ['foo' => ['type' => 'int']]]);
   Drupal::database()->schema()->addField('deleteme', 'id', ['type' => 'serial', 'not null' => TRUE], ['primary key' => ['id']]); 

This should throw Drupal\Core\Database\DatabaseExceptionWrapper SQLSTATE[HY000]: General error: 4111 Please drop primary key column to be able to drop generated invisible primary key.: ALTER TABLE "deleteme" ADD "id" INT NOT NULL auto_increment, DROP PRIMARY KEY, ADD PRIMARY KEY ("id");

Proposed resolution

Perhaps addField() could catch this exception and add a clause to the statement that drops the invisible column?

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Stylelint updated to 15 #3344087: Update Stylelint and Prettier for Drupal 10.1 and use Prettier for formatting PostCSS

But seems we ignore its `Significant changes`:

https://stylelint.io/migration-guide/to-15#significant-changes

Now stylelint only cares about `Code-quality rules` and never cares about `Formatting rules`

That formatting rules removed from our base config
`Removed: 64 rules deprecated in stylelint@15.0.0. For details, see the migration guide.`
https://github.com/stylelint/stylelint-config-standard/blob/main/CHANGEL...

More info: https://prettier.io/docs/en/comparison

Steps to reproduce

Put any bad formatted postcss into any core pipeline and it pass all checkings

Proposed resolution

Use https://github.com/prettier/stylelint-prettier

3 MRs here

1. `proof-of-failures ` explains that after upgrade we don't have formatting errors reported. I downgraded stylelint and got pipeline reports about formatting errors which younger than 14-15 stylelint upgrade (UPD + new max-line-length recently removed)

2. `success-on-anything` explains why this ticket is major. Right now any unformatted postcss can appears in core without pipeline reports

3. `3409048-postcss-file-formatting` Fix MR. With stylelint-prettier. We need to add result of command `yarn lint:css --fix` here and commit.

Problem/Motivation

Several process plugins contain lookups against hardcoded migration ids. These ids can change in contrib, or custom migrations with different ids should be able to work with the process plugins.

A scenario where this is a problem is exampled in issue summary of the duplicate.

Process plugins:
[x] BlockPluginId.php used in d6_block.yml and d7_block.
[X] BlockVisibility.php used in d6_block.yml and d7_block.
[x] d7/FieldBundle.php used in d7_field_instance.yml
[X] d6/FieldFile.php OK. This is added to the migration by defineValueProcessPipeline so it is installed in the yaml as a process.
[X] d6/FilterFormatPermission.php used in d6_user_role.yml
[(x)] MenuLinkParent.phpdoes a self lookup, so no change needed

Furthermore there are migrateLookup->lookup() calls in

• MigrateLookupTest
• MigrateStubTest
• MenuLinkParentTest
• MigrationLookupTest

unsure if these also have to be adjusted.

Proposed resolution

Move migration_lookups from the following plugin to the migration yml so that migrate_upgrade can find it.

• BlockPluginId.php
• BlockVisibility.php
• d7/FieldBundle.php
• d6/FilterFormatPermission.php

Add new process plugins to do the lookups given the migration ID supplied by the yml.

• block/src/Plugin/migrate/process/RolesLookup.php
• user/src/Plugin/migrate/process/d6/FilterFormatLookup.php

Remaining tasks

Review

User interface changes

API changes

Data model changes

Release notes snippet