Hello all, it’s time for the weekly migration subsystem meeting. The meeting will take place in slack in various threads
This meeting:
➤ Is for core migrate maintainers and developers and anybody else in the community with an interest in migrations
➤ Usually happens every Thursday and alternates between 1400 and 2100 UTC.
➤ Is done on the #migration channel in Drupal Slack (see www.drupal.org/slack for information).
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to. See the parent issue for an idea of the typical agenda.
➤*Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.

Core migration issues

• RTBC
• NR
• all open
• Statistics, Google spreadsheet

Next video meeting TBD 2100Z

The hope is that most or all of the maintainers will attend. We will try to focus on longer-term goals than in the weekly meeting.

0️⃣ Who is here today?

1️⃣ What should we talk about today? Suggest topics here and I will add threads. I will also check for comments on the issue for today’s meeting.

2️⃣ Action items. To be added later.

3️⃣ Statistics

4️⃣ Comment in this thread if you are looking for ways to help. Give us some idea of what you would like to do: documentation, code review, testing, project management, ...

5️⃣ Previous minutes.

6️⃣ Announcements

7️⃣ Generic Skip plugins

8️⃣ Deprecate Migration::set()

9️⃣ Only migrate role permissions that exist on the destination

🔟 Wrap-up

Problem/Motivation

When setting cardinality unlimited on a file field, a description 'Unlimited number of files can be uploaded to this field.' is shown on the upload field.
However, there are max_file_uploads restrictions (default value is max 20 files) that should be respected.

Steps to reproduce

• Set max_file_uploads on 2 in PHP config.
• Create a content type with a file field which is set as 'Allowed number of values' = unlimited
• Upload more than 2 files in the field

Only 2 images are uploaded into the field without warning or information for the content editor.
When uploading 25 images on a 20 limit, the content editor doesn't know that 5 images are not handled by the file field.

Proposed resolution

• Change the 'Unlimited number of files can be uploaded to this field.' message according to the PHP's max_file_uploads setting.
• Add validation when more than allowed max_file_uploads files are uploaded.

Remaining tasks

• Handle messaging based on PHP's max_file_uploads
• Handle validation based on PHP's max_file_uploads

I have a "feature request" I'd like to suggest. I recognize that it's minor, in the grand scheme of things, but as the old saying goes, "a closed mouth doesn't get fed."

I have noticed for a long while, (probably as long as I've been working with Drupal, so back to D7 somewhere) in the /ADMIN/STRUCTURE/BLOCK/DEMO/[THEMENAME] screen, the "Exit Block Region Demonstration" button is ALWAYS sitting right over at least one of the region tags, making it unreadable. Yes, sure, you can look at the available regions, and based on what you CAN see, you can usually figure out what it is, but I was wondering if it would be possible to move that "Exit Block Region Demonstration" button somewhere else? Ideally, perhaps onto one of the Admin Toolbars? Or maybe make it a Modal, where it can be moved to an out-of-the-way place, with enough of a border to be dragged around without unintentionally hitting the button and closing the screen?

Problem/Motivation

The file usage information view displays an empty page for non-existing files. A 404 response code is expected.

Steps to reproduce

In a fresh 9.4.x standard Drupal installation, open /admin/content/files/usage/1234 as admin. You will get:

Proposed resolution

Add entity:file argument validation to views.view.files

Remaining tasks

Review.

User interface changes

None.

API changes

N/A

Data model changes

N/A

Release notes snippet

TBD.

Problem/Motivation

This is issue is spun off from UX team feedback on #2831944-203: Implement media source plugin for remote video via oEmbed.

For security reasons, the oEmbed system uses an iframe to serve content from a third-party oEmbed provider. By default. the iframe is served from the same domain as the main Drupal site, but this is not secure. Therefore, Media introduced a setting, exposed in a configuration form, which allows site builders/admins to set up an alternate domain from which to serve the iframe.

In order to serve oEmbed content more securely, the iFrame domain needs to point to the Drupal site. This is explained on the form, but not validated in any way.

Proposed resolution

It would be nice to add some sort of validation to ensure that the iFrame domain is actually pointing to the Drupal site, because if it isn't, then almost all oEmbed content on the site will break (404 errors or worse), which scare the pants off of our users.

Remaining tasks

1. Discuss if we should even do this, and if so, how to do it in a way that will please the security team.
2. Write a patch
3. Review it until we're all sick of looking at it
4. Commit it

User interface changes

TBD, but probably none.

API changes

TBD, but probably minimal or none.

Data model changes

None anticipated.

Problem/Motivation

The content authoring page has a series of fields (title, summary, etc.) that I think might be more usable if heading tags were used.

In a recent web aim survey, 86% of screen reader respondents found headings somewhat (33% somewhat useful or very useful (53%)

Steps to reproduce

1. Login to:
2. Go to author an article (e.g. node/add/article)
3. Notice the field labels (e.g., title, summary)

Proposed resolution

Wrap the field labels in Heading tags

Remaining tasks

User interface changes

The heading tags will provide features for navigating, commonly used by blind screen reader users.

API changes

Data model changes

Release notes snippet

Problem/Motivation

Since upgrading form Drupal 9.2.11 to 9.3.2 (also 9.3.3) we've noticed that the field theme suggestions isn't picking up an existing override field template (field--field-publications.html.twig), and instead chooses our base field (field.html.twig) from my themes field twig templates.

9.2.11

HOOK: Field
FILE NAME SUGGESTIONS:
* field--node.html.twig
* field--node--field-publications--publication-listing.html.twig
* field--node--field-publications.html.twig
* field--node--publication-listing.html.twig
x field--field-publications.html.twig
* field--entity-reference.html.twig
* field.html.twig
OUTPUT FROM:
BEGIN OUTPUT from 'themes/custom/THEMENAME/templates/field/field--field-publications.html.twig'

9.3.2

HOOK: Field
FILE NAME SUGGESTIONS:
* field--node.html.twig
* field--node--field-publications--publication-listing.html.twig
* field--node--field-publications.html.twig
* field--node--publication-listing.html.twig
* field--field-publications.html.twig
* field--entity-reference.html.twig
x field.html.twig
OUTPUT FROM:
BEGIN OUTPUT from 'themes/custom/THEMENAME/templates/field/field.html.twig'

Steps to reproduce

Start with DRUPAL 9.2.11
Have at least two field twig templates defined in your
themes/custom/THEMENAME/templates/fields folder
e.g. field--field-publications.html.twig
and also a generic field.html.twig file

Test to see if the targeted template is working

Upgrade to Drupal 9.3.3

Test to see if the specific template is being called or the generic field template is being called.

Update: Other Theme hooks seem to be honouring the suggestions system, it's just the Field suggestion hook that looks like its changed.

Problem/Motivation

See #3222852-17: <dl> <dt> <dd> by introducing "Manually editable HTML tags" configuration on Source Editing.

There's currently a lack of clarity in the half a dozen methods on HTMLRestrictionsUtilities. \Drupal\ckeditor5\Plugin\CKEditor5PluginManager::getReadableElements() and \Drupal\ckeditor5\Plugin\CKEditor5PluginManager::getBlockElementList() should also be refactored out of there.

IMHO by far the clearest solution here is to stop treating this specially structured as an array. We already started doing that by introducing that utility class in the first place in #3216015: Generate CKEditor 5 configuration based on pre-existing text format configuration, where we added \Drupal\ckeditor5\HTMLRestrictionsUtilities::diffAllowedElements(). #3222852: <dl> <dt> <dd> by introducing "Manually editable HTML tags" configuration on Source Editing made it grow a lot, and just made it clear we really need better developer ergonomics around this — the risk of bugs is otherwise very high.

Therefore I think introducing a HTMLRestrictions value object would make this a lot less brittle, and far simpler to test:

final class HTMLRestrictions {

  public static function create(string $string): HTMLRestrictions;

  public function diff(HTMLRestrictions $other): HTMLRestrictions;

  public function intersect(HTMLRestrictions $other): HTMLRestrictions;

  public function toCKEditor5ElementsArray(): string[];

  public function toFilterHtmlAllowedTagsArray(): string[];

  public function toGeneralHtmlSupportConfig(): string[];

}

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

From my latest run of the simpletest test suite here are the tests that are failing on PostgreSQL:

Drupal test run
---------------

All tests will run.

Test run started: Friday, February 5, 2010 - 10:14

Test summary:
-------------

Anonymous comments 127 passes, 12 fails, and 4 exceptions
Comment blocks 93 passes, 16 fails, and 7 exceptions
Comment Rebuild 29 passes, 1 fail, and 1 exception
Comment approval 104 passes, 0 fails, and 2 exceptions
Comment interface 198 passes, 7 fails, and 6 exceptions
Comment preview 73 passes, 0 fails, and 1 exception
Comment RSS 22 passes, 2 fails, and 1 exception
Comment paging settings 206 passes, 0 fails, and 11 exceptions
Field CRUD tests 47 passes, 0 fails, and 1 exception
Field attach tests (storage-related) 91 passes, 0 fails, and 1 exception
List field 11 passes, 0 fails, and 1 exception
Field UI tests 102 passes, 2 fails, and 1 exception
File field validation tests 91 passes, 0 fails, and 1 exception
Forum functionality 527 passes, 1 fail, and 1 exception
RDFa comment markup 133 passes, 8 fails, and 4 exceptions
RDF tracker page mapping 38 passes, 4 fails, and 2 exceptions
Comment Search tests 54 passes, 0 fails, and 1 exception
Search engine ranking 30 passes, 0 fails, and 1 exception
Session https handling 52 passes, 1 fail, and 1 exception
Tracker 206 passes, 1 fail, and 5 exceptions
Trigger other actions 71 passes, 0 fails, and 1 exception
Cancel account 237 passes, 0 fails, and 1 exception
Schema API 13 passes, 5 fails, and 0 exceptions
Forum functionality 527 passes, 1 fail, and 1 exception
String translate, search and validate 240 passes, 2 fails, and 0 exceptions
Session https handling 52 passes, 1 fail, and 1 exception
Flood control mechanism 5 passes, 1 fail, and 0 exceptions
Tracker 206 passes, 1 fail, and 5 exceptions
Update contrib functionality 78 passes, 31 fails, and 0 exceptions
Update core functionality 129 passes, 18 fails, and 0 exceptions

Test run duration: 5 hours 37 min

Thats right! it took me over 5 hours to run the test suite in concurrency (4 concurrent processes)

Anyway, the idea of this issue is to be a parent issue for all of these failed tests which we can then fork off to there own issue as each issue is found.

Problem/Motivation

CKEditor 4 enables image resizing when width and height attributes are allowed by the HTML filter.

Proposed resolution

Similar to this, we should allow enabling image resizing in the UI. Instead of using the HTML filter as the trigger, we could provide checkbox in the plugin configuration form.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

When an user account is removed, its assigned shortcut set remains mapped at the shortcut_set_users table.

Steps to reproduce

In a fresh standard D9.4 installation:

1. Create a new user account, their expected UID is 2
2. Explicitly assign the default shortcut set at /user/2/shortcuts
3. Remove the user account

The shortcut assignment will remain at the shortcut_set_users table:

> SELECT * FROM shortcut_set_users;
+-----+----------+
| uid | set_name |
+-----+----------+
|   2 | default  |
+-----+----------+

Proposed resolution

Clean up assigned shortcut set when a user is deleted.

Remaining tasks

Patch, test, review.

User interface changes

None.

API changes

N/A

Data model changes

N/A

Release notes snippet

Not required.

Problem/Motivation

It's not possible for code that works with references to discover reference fields in an extensible fashion.

Code has to hardcode the name of reference field types, e.g. 'entity_reference' (in core), 'entity_reference_revisions', 'dynamic_entity_reference' (in contrib).

#3057545: ResourceTypeRepository wrongly assumes that all entity reference fields have the setting "target_type" adds an EntityReferenceItemInterface which would allow calling a field to get the referenceable types instead of hacking into field settings.

But it would also be useful to add an annotation property to field types so field type plugins can declare themselves as a reference field.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Reset to alphabetical button is visible if users have access to edit all terms in a vocabulary, however reset route access is determined by whether the user has administer taxonomy.

This means users without administer taxonomy can see the button, but they receive access denied when clicked.

Problem (cause)

• Reset route uses administer taxonomy permission. (See \Drupal\taxonomy\Entity\Routing\VocabularyRouteProvider::getResetPageRoute)
• Button visibility on is determined by checking $term->access('update') on all terms. (See $change_weight_access)

Proposed solution

1. Create a reset-all-weights operation for vocabularies.
2. Check administer taxonomy before checking all terms.
3. Move all existing $change_weight_access logic to operation access
4. Change reset route permission to use _entity_access: 'vocabulary.reset-all-weights'
5. Check vocabulary access before showing button.

Related concerns were raised in #1848686: Add a dedicated permission to access the term overview page (without 'administer taxonomy' permission)

Problem/Motivation

Any route using the _csrf_token requirement doesn't work for users without session because the CSRF checker fails as the CSRF seed is not stored anywhere.

Proposed resolution

Only add a CSRF token if a session is started.

Remaining tasks

User interface changes

Flag supports anonymous users (and there was much rejoicing).

API changes

CsrfAccessCheck constructor requires a new argument but it's a service so noone should be constructing it anyways.

Data model changes

None.

Problem/Motivation

See discussion from #3223443-24: [policy, no patch] Process for dealing with EOL PHP versions during the Drupal 10 and future release cycles on.

Proposed resolution

• Deprecate \Drupal::MINIMUM_SUPPORTED_PHP in favor of a methods that returns our best estimate for the given date, based on our release schedule and PHP's known (and predicted) release cycles.
• Hardcode safe estimates in 10.0.0, and patch the methods in each minor with updated estimates.

Note that this approach only makes sense if we issue a warning on installation (rather than an error) as discussed in #2917655: Deprecate or drop PHP 7.3 support in Drupal 9.4.

Remaining tasks

TBD

User interface changes

Users on old PHP versions automatically begin seeing new informational messages or warnings on a given date, even if they are not running the latest Drupal minor.

API changes

\Drupal::MINIMUM_SUPPORTED_PHP is deprecated in favor of \Drupal\Core\PhpRequirements::minimumSupportedPhp().

Data model changes

Probably none?

Release notes snippet

Needed.

Problem/Motivation

The file_managed.filesize column could be null, if the file size couldn't be determined. So we need to check that the file size is not null before passing to format_size(), which expects an integer.

The PHP 8.1 error messages are: Deprecated function: abs(): Passing null to parameter #1 ($num) of type int|float is deprecated in format_size() (line 138 of core/includes/common.inc) and Deprecated function: htmlspecialchars(): Passing null to parameter #1 ($string) of type string is deprecated in Drupal\Component\Utility\Html::escape() (line 424 of core/lib/Drupal/Component/Utility/Html.php) - there are two deprecations because the null size is also passed thru htmlspecialchars() as the @count placeholder. (Hmm, having strict type checking someday in format_size() would prevent the need to pass the number thru htmlspecialchars() :)

Steps to reproduce

Create a File entity with null size (e.g. file doesn't exist or can't be statted), and use it with the table of files field formatter.

Please ignore this issue. It is only for testing.

Problem/Motivation

In Drupal\migrate\Plugin\Migration, the variable $migration_dependencies is an array with two keys: 'required' and 'optional'. Each of $migration_dependencies['required'] and $migration_dependencies['optional'] is an indexed array (list) of migration IDs.

Sometimes, but not always, each of the two lists is "expanded" so that it includes all derivatives of any migration on the list.

When a migration is created by Drupal\migrate\Plugin\MigrationPluginManager::createInstances(), each of the two lists is expanded. When a migration is altered by Drupal\migrate\Plugin\Migration::set('migration_dependencies', ...), the lists are not expanded. The calling function can set $migration_dependencies to any value.

Proposed resolution

Choose one of the following strategies:

1. Expand the lists whenever they are set.
2. Expand the lists whenever they are accessed.

The first option will mean expanding the lists in Migration::set(). The second option will mean expanding the lists in Migration::getMigrationDependencies().

There is no way to ensure backwards compatibility with the first strategy. Using the second strategy, we could deprecate Migration::getMigrationDependencies() and add a new method that does the expansion.

Remaining tasks

User interface changes

None

API changes

Possible deprecation and API addition to Drupal\migrate\Plugin\Migration: TBD.

Problem/Motivation

Return type of \Drupal\Core\Entity\EntityChangedTrait::getChangedTime is annotated as string.
However, content entities (ie. obtained via Node::load($id)) have value of "changed" as string.

Steps to reproduce

    $node = Node::load(1);
    $time = $node->getChangedTime();
    assert(is_int($time));

Proposed resolution

Cast string value to int.

However, there is a generally broader issue behind this problem, as all implementations of getChangedTime and getCreatedTime are affected.
The former is limited to 1 line of code, thanks to EntityChangedTrait.
The latter however would require several changes (Media, Node, User, ...)

Remaining tasks

Test patch.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Problem

This issue covers multiple problems relating to the function EntityViewController->buildTitle(). This issue blocks #2353867: [META] Expose Title and other base fields in Manage Display and has adverse consequences in current vanilla core.

1 Malformed HTML output

In certain scenarios the page title region contains a div or h2 element inside h1, which is invalid markup.

Example scenario:

• Enable the media module.
• Create a media type and manage display to enable the name field
• Create a media entity, and view it at /media/1.
• Actual result: invalid markup div inside h1.
• Expected result: valid markup.

Cause is that buildTitle inserts the rendered output of a field into $page['#title']. In vanilla core:

• the field output comes from field.html.twig and contains a div
• the formatter may add further tags such as h2
• the page title output comes page-title.html.twig and wraps the title in h1

This bug does not affect user entity (no label) or node entity (specific workaround by means of field--node--title.html.twig - but that workaround causes problem 4).

2 Prevents manage display of label field

On the entity own page (such as /media/XX) the settings of manage display are ignored. The label field is missing from the main content, even if the title block is hidden.

This has been split off to a separate issue, #3043592: Allow entity to display label field as normal.

3 Inconsistent, only works selectively

The buildTitle function does not get called if the label field has been disabled by means of manage display. Hence the UX of the title block varies depending on a manage display setting (even though that setting potentially has no effect due to 2).

I analysed the tests that failed when removing buildTitle and discovered that we are relying on it for two unexpected things.

1. HTML tags in page title: buildTitle escapes them, but template_preprocess_html strips them.
2. Wrapper: for nodes field--node--title.html.twig is used and by default it wraps the page header title in a span

However both of these stop happening if the label field is disabled - inconsistency which is confusing and undesirable. For example it means that #2930788: Do not show name by default in media displays has surprising consequences.

4 Node titles missing label

If the site owner has hooked the node title to setDisplayConfigurable, then the title field display is incorrect, for example the label is missing.

Cause is the workaround code added for 1. The template field--node--title.html.twig overrides the normal field template with special case handling applicable if the display is not configurable. However the template gets used for configurable display too.

Overall effect

For any entity (such as core Media Entity) that allows manage display of the label, there is no safe option.

• If display is enabled, then get bad markup from 1).
• If display is disabled, then get potentially missing markup from 3).

There are contrib modules and core patches to extend manage display of label to more entities.

FYI Comment incorrect

The comment in buildTitle claims that the purpose is

allows attributes set on the field to propagate correctly (e.g. RDFa, in-place editing).

However RDFa works handles the title field in rdf_preprocess_node in a way that does not rely on buildTitle.

Proposed Solution

Enhance EntityViewController->buildTitle() to switch between two alternatives.
1) "Legacy" = as existing code: set page title to the rendered title field formatter instead of the default plain text title. This is the default in Drupal 8, but is deprecated and will be removed before Drupal 9. This method has bugs if a module makes the field's display configurable via the field UI by means of of BaseFieldDefinition::setDisplayConfigurable().

2) "Template". Set page title to the output from the entity_page_title template; modules can use hook_preprocess_entity_page_title() to add attributes. Disable output of the label field in the main content. This will be the default in Drupal 9. It's not the default in Drupal 8, because it is not fully back-compatible with modules that rely on hook_preprocess_field() to set attributes on the page title.

Use the new "Template" if the label

• a module makes the field's display configurable via the field UI by means of BaseFieldDefinition::setDisplayConfigurable()
• AND the additional entity type property 'enable_page_title_template' has been set using hook_entity_type_build().

Rejected solution

Continue putting field into page title and fix all the bugs.

Downsides

1. The code for putting field into page title is already somewhat complex and mysterious.
2. We need to add more complex and mysterious code (see patch #26): pass a flag "is page title" into EntityViewController and EntityViewBuilder. That code doesn't really belong as those classes shouldn't care about page titles.
3. We need to add more complex and mysterious code to make an inline field template (see patches in #2993647: Correctly determine when to display fields as inline). This likely forces all theme developers to alter their field template.
4. Even after all this, there is a bug with quickedit. Patch #26 doesn't cover the case when the title is edited, and redrawn. To fix that we would need to make quickedit add an attribute to indicate a page title, and pass that information back on the AJAX request. So more complex and mysterious code.

The sole benefit of putting field into page title is to allow modules to write a preprocess function for all fields, and it 'magically' also works on the page title. However this is a dubious assumption - what works for a normal field isn't necessarily right for a page title - and has zero uses in core. (We will have to fix quickedit_preprocess_field to handle the page title case specially anyway.)