When performing a fresh install of Drupal, the main heading states "Welcome to < site name >" where the site name can be anything from "Bobs Burgers" to "Drush Site Install". This seems kind of clunky and awkward to me, because the text below talks about Drupal (as opposed to the site).

I propose to change it to simply "Welcome!"

Problem/Motivation

Usecase:
There are three nodes with the following titles: foo, bar, drupal. Requirement: Create a view that lists nodes that does not have title foo or bar.

Using views string filter you can't create a SQL expression like "some_field NOT IN ('foo', 'bar')", as a workaround when searching a multiple value string in a string Regular Expression operation can be chosen but it's hard to implement a reverse search for regex because the regex is done on SQL level which is limited according to https://dev.mysql.com/doc/refman/5.7/en/regexp.html

POSIX regexes don't support using the question mark ? as a non-greedy (lazy) modifier to the star and plus quantifiers like PCRE (Perl Compatible Regular Expressions). This means you can't use +? and *?

http://stackoverflow.com/questions/18317183/1139-got-error-repetition-op...

Proposed resolution

Implement negation for REGEXP operation, it can be found in documentation as NOT REGEXP.

NOT REGEXP Negation of REGEXP

https://dev.mysql.com/doc/refman/5.7/en/regexp.html

Remaining tasks

1. Requeue tests for 8.8.x branch and more DBs.
2. Final review / RTBC
3. Commit

User interface changes

Adds a new "Negated Regular expression" option to the choices for the operation to use for Views string and integer filters.

API changes

None.

Data model changes

None.

Problem/Motivation

When migrating a Link the field can be empty. And it will return a warning about the array key that cannot be access.

[warning] Trying to access array offset on value of type null FieldLink.php:129
 [warning] Trying to access array offset on value of type null FieldLink.php:142
 [warning] Trying to access array offset on value of type null FieldLink.php:144

Proposed resolution

Craete a patch that will add a check if the $value variable was not NULL and proceed with transforming the $value variable.

Hi Team,

I am not sure if this bug is because of Views or because of Block module, but here is the issue I am facing.

What are the steps required to reproduce the bug?
- Create a new view, say a content view and a page display.
- Add filters and expose them (I also exposed sort).
- Enable "Exposed form in block" to Yes
- Enable AJAX.
- Go to blocks page, and then place the block in 2 regions, or any multiple regions.
- Go to the new view and try applying filters.
- Make sure to open the debug tools, to capture the AJAX hits.

What behavior were you expecting?
- There should be one AJAX hit, and the throbber should go.

What happened instead?
- There were multiple AJAX hits, as many number of exposed forms, that many ajax hits. 2 forms, 2 ajax hits.
- The throbber doesn't go, as it adds multiple throbbers, but remove only one.

I have tried this on a vanilla install, also this is happening on one of my projects I am working on.

Happy to provide any further information and help.

Thanks.

Problem/Motivation

#3222797: Upgrade path from CKEditor 4's StylesCombo to CKEditor 5's Style added the @ckeditor5/ckeditor5-style plugin.

But its plugin definition had its drupal.elements restricted to just HTML5 elements:

    elements:
      - <$any-html5-element class>

(And it has corresponding validation logic in StyleSensibleElementConstraintValidator— see \Drupal\ckeditor5\Plugin\Validation\Constraint\StyleSensibleElementConstraint::$nonHtml5TagMessage.)

Why?

1. Drupal's CKEditor 4 integration (StylesCombo) never supported setting styles on e.g. <drupal-media>— heck, not even on <code><img>!
2. In the CKEditor 5 equivalent (Style), images and Drupal media are impossible to support today, because they're implemented as "widgets", and I quote: Widget styling is out of the picture for now.— source: issue 5700. This is fine because this didn't work in Drupal 8 either — see #2642808: [upstream] CKEditor Style for <img> not working because it is an "image" widget + #3117172: Allow CKEditor styles for <drupal-media>.
   For images this is arguably bad, but for Drupal media this is arguably fine: because those allow choosing a view mode already: #3074608: Optionally allow choosing a view mode for embedded media in EditorMediaDialog.
   Combine this with the fact that the Drupal ecosystem is moving from "plain images" to "image media"— especially post-migration from Drupal 7 thanks to migration modules like https://www.drupal.org/project/media_migration, the value of making this work for plain images (<img>) is diminishing.
3. In the CKEditor 5 equivalent (Style), integration with GHS is incomplete, which means that some elements may not be able to use Style yet.
   Since CKEditor 5's official plugins only support official HTML5 elements, the obvious thing to do is to restrict the allowed HTML elements to configure Style for to just … HTML5 elements. Hence the validation logic mentioned above!

Steps to reproduce

N/A

Proposed resolution

Wait for Style to stabilize further, and in particular for it to gain full GHS support. Then we can consider allowing configuring styles for non-HTML5 tags.

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Release notes snippet

TBD

Problem/Motivation

There is an unmet need to flag entities as "syncing" when doing migration updates, so that they can be handled differently from ordinary updates.

For example, updating an entity sets the entity's changed time to the current time. This creates an issue when doing migration updates, which update entities on the destination that have been changed on the source since the last migration.

In an initial migration, the entity's changed time is set to match the changed time in the data source. For example, if a node of the page content type has a "changed" timestamp 1651775012 in the source, the node will also have a "changed" timestamp 1651775012 in the destination, regardless of how much time has actually elapsed since then.

This behavior should be the same when the initial migration is updated (via e.g. "drush mim upgrade_d7_node_page --update"). But it's not. Rather, the "changed" timestamp on the destination entity is set to the current time, instead of the value of the "changed" timestamp on the source node. As a result, the migrated data on the destination does not faithfully mirror the source.

Among other side effects, views that include a sort on the entity's changed time may not work correctly on the destination after a migration update.

An additional example of the need for a "syncing" flag can be seen in issue #2803717, concerning updates in content moderation.

Proposed resolution

Multiple patches are involved. This one simply flags an entity as "syncing" during a migration.

The following pending patch looks for the "syncing" flag and skips updating the changed time for entities with that flag:

#2329253: Allow the ChangedItem to skip updating the entity's "changed" timestamp when synchronizing (f.e. when migrating)

This fixed issue uses a "syncing" flag to solve a similar problem in content moderation migrations:

#2803717: Allow 'syncing' content to be updated in content moderation without forcing the creation of a new revision

Blocked on:

None. This patch simply sets the "syncing" flag that can be used to alter the behavior of an entity migration. It is blocking #2329253 and would provide a simpler method to implement #2803717.

Remaining tasks

None

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

This patch marks entities as "syncing" during migrations, so that other code (including issues #2329253 and #2803717) can alter the handing of migrating changes to entities.

Problem/Motivation

@larowlan reported a crash in #3222797-52: Upgrade path from CKEditor 4's StylesCombo to CKEditor 5's Style, which I could not reproduce by just creating a simple test case. It took many hours of trial and error and debugging.

Eventually, the root cause became clear: only if somewhere along the way while various things are computed and data is transformed, certain arrays have an array state where the "next" array key by appending to the array (so $array[] = 'something';) would not be zero (i.e. $array[0] once existed and was since deleted), then \Drupal\ckeditor5\HTMLRestrictions::merge() computes an invalid result.

But … the root cause is not the logic in HtmlRestrictions::merge(). It's in PHP's own array_merge_recursive()! https://php.net/manual/en/function.array-merge-recursive.php does not document this behavior. The consequence is that two ostensibly identical arrays can yield different merge results!🤯

$a = ['foo' => ['bar' => TRUE]];
$b = ['foo' => 'baz'];

$m1 = array_merge_recursive($a, $b);

$a['foo'][] = 'proof is in the pudding';
unset($a['foo'][0]);

$m2 = array_merge_recursive($a, $b);

var_dump($m1 == $m2);

👆 This prints bool(false)! 🤯🤯🤯

Steps to reproduce

See https://3v4l.org/fXXsn, where I came up with a way to demonstrate the problem and show that there's only once possible solution:

<?php

$a = ['p' => ['id' => TRUE]];
$b = ['p' => FALSE];

print "Behaves as expected.\n";
var_dump(array_merge_recursive($a, $b));

print "\n\nOMG internal array pointer shenanigans can affect the results of array_merge_recursive()!\n";
$a['p'][0] = 'SOMETHING, anything!';
unset($a['p'][0]);
var_dump(array_merge_recursive($a, $b));

print "\n\nThis keeps happening…\n";
var_dump(array_merge_recursive($a, $b));

print "\n\n… not even resetting the internal array pointer helps …\n";
reset($a['p']);
var_dump(array_merge_recursive($a, $b));

print "\n\n… nor casting to object, cloning, then back to array …\n";
$a['p'] = (array) clone (object) $a['p'];
var_dump(array_merge_recursive($a, $b));


print "\n\n… only forcefully recreating a copy-by-value of the array by using array_slice().\n";
$a['p'] = array_slice($a['p'], 0);
var_dump(array_merge_recursive($a, $b));

outputs:

Behaves as expected.
array(1) {
  ["p"]=>
  array(2) {
    ["id"]=>
    bool(true)
    [0]=>
    bool(false)
  }
}


OMG internal array pointer shenanigans can affect the results of array_merge_recursive()!
array(1) {
  ["p"]=>
  array(2) {
    ["id"]=>
    bool(true)
    [1]=>
    bool(false)
  }
}


This keeps happening…
array(1) {
  ["p"]=>
  array(2) {
    ["id"]=>
    bool(true)
    [1]=>
    bool(false)
  }
}


… not even resetting the internal array pointer helps …
array(1) {
  ["p"]=>
  array(2) {
    ["id"]=>
    bool(true)
    [1]=>
    bool(false)
  }
}


… nor casting to object, cloning, then back to array …
array(1) {
  ["p"]=>
  array(2) {
    ["id"]=>
    bool(true)
    [1]=>
    bool(false)
  }
}


… only forcefully recreating a copy-by-value of the array by using array_slice().
array(1) {
  ["p"]=>
  array(2) {
    ["id"]=>
    bool(true)
    [0]=>
    bool(false)
  }
}

Proposed resolution

Work around this weakness in array_merge_recursive() by ensuring that the "next" array key of every nested array is always zero.

Remaining tasks

1. Tests
2. Fix
3. Reviews

User interface changes

None.=

API changes

None.

Data model changes

None.

Release notes snippet

None.

At the moment we statically cache the result of listing config by prefix in CachedStorage::listAll(). We store this by prefix looked for. This patch takes a different approach to save database queries - it statically caches the entire list of config and then filters. In the standard profile this saves a query on every page due to blocks and tours.

Problem/Motivation

Especially for migrate it would be really useful to be able to copy the old changed time, for example from a note.

After #2428795: Translatable entity 'changed' timestamps are not working at all we have a solution for new entities, but we still need a solution for existing entities e.g. currently you can't resave an entity with changes without updating the changed timestamp.

Proposed resolution

Skip the automatic updating when synchronizing entities. Ever since #2985297: Generalize the concept of entity synchronization, all entities are synchronizable. And it already provides the exact semantics that we need. Quoting \Drupal\Core\Entity\SynchronizableInterface::isSyncing():

  /**
   * Returns whether this entity is being changed as part of a synchronization.
   *
   * If you are writing code that responds to a change in this entity (insert,
   * update, delete, presave, etc.), and your code would result in a change to
   * this entity itself, a configuration change (whether related to this entity,
   * another entity, or non-entity configuration), you need to check and see if
   * this entity change is part of a synchronization process, and skip executing
   * your code if that is the case.
   *
   * For example, \Drupal\node\Entity\NodeType::postSave() adds the default body
   * field to newly created node type configuration entities, which is a
   * configuration change. You would not want this code to run during an import,
   * because imported entities were already given the body field when they were
   * originally created, and the imported configuration includes all of their
   * currently-configured fields. On the other hand,
   * \Drupal\field\Entity\FieldStorageConfig::preSave() and the methods it calls
   * make sure that the storage tables are created or updated for the field
   * storage configuration entity, which is not a configuration change, and it
   * must be done whether due to an import or not. So, the first method should
   * check $entity->isSyncing() and skip executing if it returns TRUE, and the
   * second should not perform this check.
   *
   * @return bool
   *   TRUE if the configuration entity is being created, updated, or deleted
   *   through a synchronization process.
   */
  public function isSyncing();

Remaining tasks

None.

User interface changes

None.

API changes

None.

Problem/Motivation

SA-CORE-2019-010 fixed an issue in core where file_save_upload didn't trim . from filenames like D7
The trim works for leading and trailing, but no tests were added for the trailing period.

We should also move the test out of FileManagedFileElementTest into SaveUploadTest since the code we're testing is in _file_save_upload_single().

Proposed resolution

Move the test to SaveUploadTest.
Add coverage of trim() for trailing dots.

Remaining tasks

1. Move / fix tests.
2. Review.
3. RTBC.
4. Commit.

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.

Problem/Motivation

The whole error:

ENTITY/FIELD DEFINITIONS Mismatched entity and/or field definitions
The following changes were detected in the entity type and field definitions.
File
The URL alias field needs to be installed.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Quick summary: When using content moderation + workflows on a site with 4 languages or more, the interaction between the translations leads to some of them disappearing from the site.

Explanation:
(Hello everyone, thank you for taking some time to check this out)

- You need a multilingual site with at least 4 languages to test this
- You need to enable content moderation (use default editorial workflow states, draft, published, archived), languages (remember, at least 4) and revisions.

Steps:

1) Create a content in any language, doesn't matter if published or in draft state
2) Create a default translation in language B: can either be published or archived
3) Create a draft translation in language C: at this point you should be able to see 3 versions of your content in the node/nid/translations page
4) Create a default translation in language D: can be archived or published, doesn't matter. At this point you can see the issue.

This is a screenshot of the translations UI at step (3)

This is a screenshot of the table content_moderation_state at step (3)

And these are the same screenshots after step (4)

The line where content_entity_revision_id = 20 and langcode = es is no longer on the second screenshot, and also the actual translation disappeared from the UI and from the site.

Here is a video I made with all these steps (index in description of the video):

youtube video

Notice that the actual revision is still in the database, in the end of the video I get it back by adding it again and reverting to the previous revision. This is a workaround and does not fix the issue.

So far our actual workaround has been to force the first state of every translation to be in draft using the patch from this issue:
When adding a new translation the entity should start from the draft state

Drupal Decimal Field should support 'unsigned' setting.

See patch.

Problem/Motivation

Hi guys,
I found a bug when we enable Content Moderation and content translation modules.
I tried to create a content and translate it in different languages in publish state first.
After adding some translations in different languages via the translation form of Drupal, I decided to add a new draft version to one of my translation.
When I add a new published translation, some of my previous translation disappeared in the node translation dashboard (node/{nid}/translation). In the database, I can see all my previous revisions but not in the UI.

Steps to reproduce:

1. Create a publish content in EN (for example)
2. Translate this content in DE language and publish it.
3. Translate this content in IT language and publish it.
4. Create a new draft version for IT version
5. Add a new ES translation

Proposed resolution

The entity load in the ContentTranslationController is not the right one. Instead of using `getLatestTranslationAffectedRevisionId` to get the correct revision, use the `getActive` method from the Entity Repository.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In the Gin theme we want to add consiste checkered background to images appearing in media library views #3278033: Add color pattern behind transparent images in Media Library, however, we don't have a clean way to apply them on the "media_page_list" view display, due to the missing classes.

There are two views that basically display the same media items in a table format:

• views.view.media_library (used for modal table and grid list).
• views.view.media (an optional view used for the table list on admin page /admin/content/media)

However only the media_library has the media-library-item media-library-item--table classes applied to it.

The following code only works in the modal table, but not on /admin/content/media table list:

.media-library-item img {
  background:  red /* special checkered color pattern here */;
}

Steps to reproduce

Inspect table row classes on Media Library modal view, vs Media page list view. Note that only the former view has the row classes applied:

<tr class="media-library-item media-library-item--table js-media-library-item js-click-to-select"></tr>

Proposed resolution

Update the media_library.module to add the classes, and attach media_library/view to the media view.

Remaining tasks

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

Problem/Motivation

Currently we only run phpstan on changed files. This was decided because it saves on costs one DrupalCI (adding the full analysis takes 1,5 minutes).
However failing early also saves costs, and we saw issues in deprecating modules where we would benefit from this.
Also there are some recent improvements in test runs, saving time in test run.

It However it is adviced to always run this on the entire project.
https://phpstan.org/blog/why-you-should-always-analyse-whole-project

Running the full analysis when not on DrupalCi requires some larger resources (or time, can take up to 10-15 minutes). Which makes this inpractical for core committers. Therefore it was agreed that when not on drupalCI we keep only the partial analysis.

Proposed resolution

Adjust script, to run full analysis on CI

Remaining tasks

Script adjusted.

Problem/Motivation

Noticed as I was working on #3278163: yarn upgrade for latest security vulnerabilities that shepherd.js, sortablejs, and tabbable have shipped new minor releases.

Proposed resolution

After #3278163: yarn upgrade for latest security vulnerabilities, update shepherd.js, sortablejs, and tabbable to latest minors for 9.4.x and upwards.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Our dev dependency on phpstan is not up to date.

phpstan/phpstan 1.4.0 1.6.7 PHPStan - PHP Static Analysis Tool

Updating those provides us with the latest improvements.
For the phpstan updates this might give us performance improvements. (which might help with #3259355: Always do a full phpstan analysis on DrupalCI)
https://phpstan.org/blog/phpstan-1-6-0-with-conditional-return-types

Proposed resolution

Remaining tasks

Updating mglaman/phpstan-drupal was split of to #3279840: Update mglaman/phpstan-drupal

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Is there any reason why development.services.yml does not disable TWIG cache by default? Every core update overrides this file with the default one. Themers routinely set those 3 lines, but this is a repetitive task. And the file loads only when settings.local.php is included, so it will not cause any problems on production sites.

Proposed resolution

1. Create a file at sites/theme-development.services.yml containing the twig.config related lines under the parameters: key:
   

     twig.config:
       debug: true
       auto_reload: null
       cache: true
   

2. Reference this new services file in sites/example.settings.local.php, below the line of code where development.services.yml is referenced. Leave the reference commented out with a note explaining the potential dangers and implications of enabling theme debugging.
   

   /**
    * Enable theme development services.
    *
    * Note: theme debugging can break parts of Drupal. Not recommended in
    * production environments. See https://www.drupal.org/i/2914733
    */
   # $settings['container_yamls'][] = DRUPAL_ROOT . '/sites/theme-development.services.yml';
   

   For the website themer, this code is more or less analogous to adding $config['theme_debug'] = TRUE; option in Drupal 7 settings.php file. Optionally, a CR could be added to describe this difference between D7 / D8.