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 2022-07-07 2100Z (tentative)

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? Should we add DrupalCon Global to the annual schedule?

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️⃣ Migrate non-existing permissions to temporary migrate permissions

8️⃣ Add content in tests only when needed

9️⃣ Wrap up

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 2022-07-07 2100Z (tentative)

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️⃣ trackLastImported YAML key to enable tracking the last import date of a row is undocumented and confusing.

   if ($this->migration->getTrackLastImported()) {
      $fields['last_imported'] = time();
    }

8️⃣ Deprecate migrate_lookup and replace with cleaner process plugin

/**   * Find migration dependencies from migration_lookup and sub_process plugins.
   *
   * @param array $process
   *   A process configuration array.
   *   * @return array
   *   The migration dependencies.
   */  protected function findMigrationDependencies($process) { 

9️⃣ Wrap up

Thanks to @merlinofchaos in #1963124-7: Resolve WCAG2 accessibility errors on main settings page I learned that the #states mechanism uses CSS display:none; to hide content.

Unfortunately, this means that for screen reader users, nothing gets presented to the user. For a keyboard only user this isn't a problem because when they select a checkbox new ones appear, but screen reader users need to either have access to all of the checkboxes or be alerted that there is a change to the page.

I think the best approach is to simply mimic what we did with element-hidden & element-invisible and make a:

.js .js-hide {
 display: none;
}
.js .js-invisible {
  position: absolute !important;
  clip: rect(1px, 1px, 1px, 1px);
  overflow: hidden;
  height: 1px;
  width: 1px;
  word-wrap: normal;
}

I think that would address the problem, but it ties into core/misc/states.js

Any thoughts on this would be appreciated.

Problem/Motivation

Since terms are now fieldable just like nodes, it would be useful to have vertical tabs here to hide the non-essential elements on the form. For example, the pathauto module provides fields for both the node form and the term form, but where the URL alias field can be nicely tucked away on the node form in vertical tabs, there's no similar interface pattern for terms.

Proposed resolution

- Implement vertical tabs to the taxonomy term edit form.

Remaining tasks

- Implement vertical tabs to the taxonomy term edit form.

User interface changes

- Vertical tabs on the term edit page

Before, including contrib tabs:

After, including contrib tabs:

API changes

- (?)

I have the realname module installed on my site to display authors by their realname instead of username. But this is not working for the feed I created in views. The XML generated has the username for the creator for each article. For example:
<dc:creator>daviser</dc:creator>

The creator is set in modules/node/views_plugin_row_node_rss.inc
I found that if I change this

'key' => 'dc:creator',
        'value' => $node->name,

to

'key' => 'dc:creator',
        'value' => format_username($node),

then the realname is used for the creator.

<dc:creator>Ellen Davis</dc:creator>

Hello all, it’s time for the fortnightly coding standards meeting. The meeting will take place in slack in various threads
This meeting:
➤ Is for anyone interested in the Drupal coding standards.
➤ Usually happens every Tuesday and alternates between NNNN and NNNN UTC. The meeting open for 24 hours to allow for all timezones.
➤ Is done on the #coding standards 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.
➤A transcript will be made using drupal-meeting-parser 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.

Standing items

• Who is here?
• 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.
• Action Items
• Approve previous minutes
• Wrap up

Project issues

Core Coding Standards issues
Coding Standards project issue
Coder project issues

Problem/Motivation

Symfony allows you to specify _defaults key in your services.yml file. This allows you to specify defaults for all of your services. See https://symfony.com/doc/current/service_container.html

In Symfony it often looks like

# config/services.yaml
services:
    # default configuration for services in *this* file
    _defaults:
        autowire: true      # Automatically injects dependencies in your services.
        autoconfigure: true # Automatically registers your services as commands, event subscribers, etc.
        public: false       # Allows optimizing the container by removing unused services; this also means
                            # fetching services directly from the container via $container->get() won't work.
                            # The best practice is to be explicit about your dependencies anyway.

    # makes classes in src/ available to be used as services
    # this creates a service per class whose id is the fully-qualified class name
    App\:
        resource: '../src/*'
        exclude: '../src/{Entity,Migrations,Tests,Kernel.php}'

    # ...

Whilst autoconfigure is not relevant yet it would be nice for a module to be able to declare all of its services as public: false (if for example it wants to prevent the service locator pattern - yes this is hard is Drupal because plugin managers and events don't work with them but maybe in the future) and autowire will be supported by #3021803: Document and add tests for service autowiring.

Proposed resolution

Implement this by copying code from YamlFileLoader once #3021803: Document and add tests for service autowiring has landed.

Remaining tasks

User interface changes

None

API changes

@todo

Data model changes

None

Release notes snippet

@todo

Hello all, it’s time for the fortnightly coding standards meeting. The meeting will take place in slack in various threads
This meeting:
➤ Is for anyone interested in the Drupal coding standards.
➤ Usually happens fortnightly on Tuesday 2100 UTC. The meeting open for 24 hours to allow for all timezones.
➤ Is done on the #coding standards 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.
➤A transcript will be made using drupal-meeting-parser 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.

Standing items

• Who is here?
• 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.
• Action Items
• Approve previous minutes
• Wrap up

Project issues

Core Coding Standards issues
Coding Standards project issue
Coder project issues

0️⃣ Who is here today? Comment in the thread to introduce yourself. We’ll keep the meeting open for 24 hours to allow for all timezones.

0️⃣.5️⃣ What do you do to relax?

1️⃣ Do you have suggested topics you are looking to discuss? Post in this thread and we’ll open threads for them as appropriate.

2️⃣ how do we want to organize ourselves and the work? To make progress on core issue and coding standard issues?

3️⃣ How long should the meeting run, 30 minutes or 1 hour?

4️⃣ Who would like an alternate meeting start time to suit other timezones?

5️⃣ Proposal: Have this ready 9.5 beta #3264947: [Sep 12, 2022] Add missing docblocks for test methods ::setUp() and ::tearDown()

6️⃣ What can we do to move #1539712: [policy, no patch] Coding standards for breaking function calls, function declarations, and language constructs across lines forward in the absence of any formal governance authority?

While checking the migrate core module, I noticed that in the core/modules/migrate/tests/src/Kernel/MigrateSqlSourceTestBase.php file the word "the" is repeated (100:17).

Changing this will have no effect on any code, just a simple typo in a development comment.

API page: http://api.drupal.org/api/drupal/modules--field--modules--text--text.mod...

Describe the problem you have found:
The text_summary function has an early exit, if a <!--break--> tag will be found in the content. Sadly i discovered a problem if the author of the html body content didn't placed it correctly:

My body <div>is fine<!--break--></div>

This causes an shortened teaser e.g.:
My body <div>is fine
..and break up the div-structure of the surrounding page.

Not only the author of this body can make this mistake, also the ckeditor / wysiwyg didn't care about.

So i have to handle this issue on the theming layer, but i would prefer a central solution in the text.module.

Here is my patch:

Index: text.module
===================================================================
--- text.module (Revision 121)
+++ text.module (Arbeitskopie)
@@ -361,15 +361,19 @@
   }   
 
   // If a valid delimiter has been specified, use it to chop off the summary.
+  $filters = filter_list_format($format);
   if ($delimiter !== FALSE) {
-    return substr($text, 0, $delimiter);
+    $summary =  substr($text, 0, $delimiter);
+    if (isset($filters['filter_htmlcorrector'])) {
+      $summary = _filter_htmlcorrector($summary);
+    }
+    return $summary;
   }   
 
   // We check for the presence of the PHP evaluator filter in the current
   // format. If the body contains PHP code, we do not split it up to prevent
   // parse errors.
   if (isset($format)) {
-    $filters = filter_list_format($format);
     if (isset($filters['php_code']) && $filters['php_code']->status && strpos($text, '<?') !== FALSE) {
       return $text;
     }   

Problem/Motivation

If during config import one module has to be replaced with another and the one to be installed has a conflict with the other one, then the import will fail.

Steps to reproduce

1. Install Drupal with the mailsystem enabled.
2. Change core.extension.yml, remove mailsystem and add symfony_mailer and symfony_mailer_bc
3. Observe the following error:

TypeError: call_user_func_array(): Argument #1 ($callback) must be a valid callback, class Drupal\symfony_mailer_bc\MailManagerReplacement does not have a method "setThemeManager" in call_user_func_array() (line 279 of /var/www/html/web/core/lib/Drupal/Component/DependencyInjection/Container.php).
 [warning] Drush command terminated abnormally.

The error is caused simply because symfony_mailer_bc has to be installed only after the mailsystem has been uninstalled.

Proposed resolution

First uninstall modules and then install modules during configuration import.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

It would be nice to halve the right margin of the secondary menu.

The Logo at :

padding-left: 2.25rem;

The secondary menu should have :

padding-right: 2.25rem;

and no right margin.

Problem/Motivation

We are using PHP_CodeSniffer for PHP coding standards, ESLint for JavaScript and Stylelint for CSS, but we have nothing for Twig templates.

Steps to reproduce

Proposed resolution

Adopt https://github.com/friendsoftwig/twigcs for ensuring Twig templates match coding standards.

Remaining tasks

• Add TwigCS to composer.json and commit-code-check.sh
• Configure it to pass without any violations for now
• Raise child issues to fix individual violations

User interface changes

API changes

Data model changes

Release notes snippet

Html::escape() and FormattableMarkup::placeholderEscape() needs a type declaration to prevent it from passing invalid values to htmlspecialchars(). This can only be done in Drupal 10 since it requires union types which are only support in PHP 8.1.

Original report:

Problem/Motivation

I had contrib functional tests failing with

htmlspecialchars(): Passing null to parameter #1 ($string) of type string is deprecated.

This is due to FormattableMarkup replacements being null - those go straight as nulls down to Html::escape() and hence to htmlspecialchars(), where PHP 8.1 complains.

This is not happening in core so no core tests were complaining.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Drupal 8/9 ship with CKEditor 4's StylesCombo plugin/feature: https://ckeditor.com/docs/ckeditor4/latest/features/styles.html

This shipped with the original CKEditor 4 issue: #1890502: WYSIWYG: Add CKEditor module to core. It provides a configuration UI:

When talking to the CKEditor developers:

We didn’t work on a replacement yet. We’re not even sure whether it’s needed and what’d be the use cases.
There’s a very old ticket: https://github.com/ckeditor/ckeditor5/issues/648 where we started some discussion. There’s also https://github.com/ckeditor/ckeditor5/issues/5700. But in general it’s unclear for us what would this feature be for.

What use cases do you see for it?

My response:

Well … how do we provide an automatic upgrade path in Drupal? 🤔

StylesCombo in CKE4 can only be mapped to heading.Heading in CKE5 as long as it’s only touching <h*>— but StylesCombo allowed much more. How do we automatically take any arbitrary StylesCombo configuration and make it work in CKE5?

It’s fine if it maps to multiple plugins but we do need to provide an upgrade path.

To which they responded:

Yeah, from the upgrade path perspective, there’s certainly a clear reason to do something on our side. What was blocking us so far is that we don’t want to create again a feature that duplicates a big part of the headings dropdown functionality. Thus, product-wise, it’s tricky.

Proposed resolution

Wait for https://github.com/ckeditor/ckeditor5/pull/11349 to ship with the April 6 release of CKEditor 5.

It shipped: #19. 👍

Remaining tasks

• ✅ add @ckeditor/ckeditor5-style package
• ✅ basic functionality
• ✅ TEST: unit
• ✅ TEST: kernel: SmartDefaultSettingsTest expectations should be updated
• ✅ TEST: functional JS for plugin settings
• ✅ TEST: functional JS for using the plugin
• ✅ Upgrade path
• ✅ Additional validation constraints to ensure config always is valid
• ✅ TEST: kernel: new test cases in ValidatorsTest:
  Validator test coverage, which conveys just how precise validation is, which is extra important because as described in #46, the CKEditor 5 Style plugin itself does not do any validation:
  1. INVALID: Style plugin with no styles→ when no styles are configured, having the toolbar item enabled is pointless (this is the only one already passing because it's the only one already implemented)
  2. INVALID: Style plugin configured to add class to unsupported tag→ it does not make sense to allow adding a class to a tag that cannot actually be generated!
  3. INVALID: Style plugin configured to add class that is supported by a disabled plugin→ it does not make sense to allow adding specific classes through a Style that can be supported by enabling a disabled plugin (for example "Alignment")
  4. INVALID: Style plugin configured to add class that is supported by an enabled plugin→ it does not make sense to allow adding specific classes through a Style that are already supported by another plugin (for example "Alignment")
  5. INVALID: Style plugin has multiple styles with same label→ without unique labels, it'd have terrible usability and accessibility
  6. INVALID: Style plugin has styles with invalid elements→ not possible to configure this through the UI, but … it is possible if you modify the configuration directly.
  7. VALID: Style plugin has multiple styles with different labels→ the sole example of a sane configuration, and hence the only not resulting in a validation error

User interface changes

New plugin settings form.

API changes

None.

Data model changes

None.

Release notes

The CKEditor 5 successor of CKEditor 4's StylesCombo functionality has been added. This was the last remaining widely adopted functionality of CKEditor 4 that did not yet have an equivalent!

Problem/Motivation

After we install any module, changes in configuration is getting lost and it is reverting to old state (existing in custom module)

Steps to reproduce

1. Install drupal core 8.8.10
2. Install languages and all language related modules like interface translation, etc.
3. Install metatags module.
4. Create a custom module and add metatag.metatag_defaults.node__article.yml in config/install -

langcode: en
status: true
dependencies: {  }
id: node__article
label: 'Content: Article'
tags:
  title: '[node:title] | health test arabic info & tips | [site:name]'
  description: '[node:title] | health info & tips | [site:name] description'

5. Enable the custom module.
6. Now, change configuration of metatag manually from admin page - admin/config/search/metatag/node__article
7. Set interface translation to English.
\Drupal::configFactory()->getEditable('locale.settings')->set('translate_english', 1)->save();
8. Enable any module for example- devel and we find that change made in step 6 is lost and we see the old state which got added from custom module in step 4.

Looks like the issue seems to happen in locale_config_batch_refresh_name function where we call updateConfigTranslations() which checks if locale_is_translatable($langcode), then merges old config with new config changes and eventually remove the new changes.

Problem/Motivation

After the upgrade to 9.2.x two of my sites began to WSoD with uncaught exceptions when they send emails:

Symfony\Component\Mime\Exception\RfcComplianceException: Email ""Foo" does not comply with addr-spec of RFC 2822. in Symfony\Component\Mime\Address->__construct() (line 56 of \path\to\drupal\vendor\symfony\mime\Address.php).

These two sites have names that contain commas. I tested the issue on a vanilla install of 9.3.x-dev and gave the site the name "Foo, Bar, and Baz". The above exception was produced by testing the issue with that site. The exception was thrown because Symfony's MIME component attempted to validate the From address for an email up to the first comma, not the entire address.

I backtraced the issue to a commit made two months ago for #84883: Unicode::mimeHeaderEncode() doesn't correctly follow RFC 2047. In comments #202 and #203 of that issue code was added to the patch that explodes multiple From addresses using commas as a delimiter. See the following snippet from core/lib/Drupal/Core/Mail/Plugin/Mail/PhpMail.php lines 87-92:

    $headers = new Headers();
    foreach ($message['headers'] as $name => $value) {
      if (in_array(strtolower($name), self::MAILBOX_LIST_HEADERS, TRUE)) {
        $value = explode(',', $value);
      }
      $headers->addHeader($name, $value);
    }

Unfortunately, it does not account for commas in the name part of addresses and explodes them too. Thus, I assume this issue would occur for any names that include commas, not only site names.

I attempted to write a failing test for this issue - which I will upload - and wasn't successful. I don't know why, but the test passes with the From address being generated correctly. That's despite the fact that this issue is really easy to reproduce with a vanilla D9 install. But this might explain why this issue wasn't caught before now. There is a test for special characters in email From fields, including commas. It could be that the email test is flawed in a way that causes this problem to not be caught.

This issue is major because it is preventing the site from carrying out normal operations that require sending emails. In my case, I discovered it when attempting to send password reset emails.

Steps to reproduce

1. Create a vanilla install of Drupal 9.
2. Set the site name to one that contains commas, e.g. "Foo, Bar, and Baz".
3. Log out (this might not be necessary, but I did it every time I tested).
4. Visit /user/password and attempt to send yourself a password reset email.

Expected behavior:
The front page should load with a message saying that a password reset email has been sent.

Actual behavior:
After submitting the password reset form the site gives you a WSoD with the above uncaught exception.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Steps to reproduce

• Fresh install (in english)
• Enable the locale and language modules.
• Add a language (dutch in my case)
• Make the newly added language standard language
• Enable a module which provides default config (book module for example)

Note that this bug only occurs if the default language or the fallback language is not English.

Result

In the UI, you will see some English instead of Dutch on various pages that load configuration.

In the database:
- The base config items in the config table now have a langcode element in them, telling Drupal they are in Dutch not English.
- So when you try to load config, the base config thinks it is Dutch (even though the text is English), and the config overrides (which are still in the config database) are not being loaded to translate the English into Dutch.

Expected result

The English configuration is interpreted as english config, not Dutch, and the config translation overrides are used when viewing the site in Dutch.

Related issues

An issue which does a great job of explaining the issue, including a reference to core issue this was introduced. It also provides proposals: #3150540: Configuration langcode is forced to site default language

This issue seems fairly similar to #2468767: English config source strings are saved as custom translations in locale in foreign install .

Also, UI text gets overridden when modules are installed. This issue is about config being mangled; the UI text problem is a separate issue: #2806009: Installing a module causes translations to be overwritten.

Proposed resolution

There was some debugging done; probably the cause is described in #6 / #11 / #14

There was a test-only patch in #5 but it's really for the related UI text issue, not the config text issue.

Remaining tasks

Make a patch, including a test.

User interface changes

Configuration language will not be changed to an inappropriate language.

API changes

None.

Data model changes

None.

Problem/Motivation

CKEditor 5 uses tooltips named balloons to provide the configurable functionalities integrated with the editorial experience. For instance with adding a link, a sort of popup named balloon appear to let you configure the link.

This feature though is added of "canvas" in a div with the class ck-body-wrapper:

That result in the tooltip being missdisplayed (not visible at all) in CKEditor 5 within modals. Hence, the functionality not usable at all. This one, and all relying on those tooltips.

This is true for :
- CKEditor 5 used in textarea configured on views since views uses modals #2741187: Allow usage of WYSIWYG in views text area fields
- for people using Layout Paragraphs to build content
- for any textarea field in a form opened in modal mode
- for any other contrib or core module that would use textareas in modal and that I am not currently aware of

Steps to reproduce

You could apply / try patch here for instance, or use the layout paragraph module.

Proposed resolution

The modal is opened with a given z-index. For example in Seven it is z-index: 1260.
I suggest to apply the following CSS to the .ck-body-wrapper class :

position: fixed;
z-index: 1300;

However, with this trick, the input field still do not get the focus, which I don't know how to handle at the moment.

Problem/Motivation

We are now able to create inline blocks from the Layout Builder but they are always set to non-reusable. It would be nice to have a checkbox to decide of the block should be reusable or not, similar to functionality in FPP for Drupal 7. This would allow editors to create reusable blocks while editing layouts for individual pieces of content, rather than having to jump to the "Block layout" section.

Proposed resolution

• Add a "Reusable" checkbox to inline_block plugins in Layout Builder
• If checked, it'll expose an "Admin title" field for naming the reusable block
• Once saved, it'll convert the underlying content block entity to reusable, and convert the inline_block plugin on the Section to a block_content plugin
• Allow editing the content block referenced by block_content plugins, and include a warning that let's editors know that their changes will be reflected globally

Remaining tasks

• Determine if this is something we should tackle in core
• Write tests
• Conduct usability review

User interface changes

• Adds checkbox and admin title field when editing inline_block in Layout Builder:
  
• Adds content block fields and warning when editing block_content in Layout Builder:
  

API changes

None.

Data model changes

None.

Release notes snippet

TODO