Problem/Motivation

I was reviewing the code of SystemController.php and noticed that there was a procedural t() function instead of $this->t() which is not a best practice to use inside a controller.

$admin_theme_options[$theme->getName()] = $theme->info['name'] . ($theme->isExperimental() ? ' (' . t('Experimental') . ')' : '');

Steps to reproduce

1. Git checkout the Drupal 9.5.x version.
2. Go to the location of the file: /core/modules/system/src/Controller/SystemController.php.

Proposed resolution

I have replaced from t() to $this->() function.
And working fine if using any experimental theme.

In Drupal 7, it was possible to override breadcrumb by a contextual filter. That feature is missing in Drupal 8. Maybe in Drupal 9 too, but I am yet to try Drupal 9.

Not sure any resolution happened already on it. I did not get any result so far.

It would be good if we get that feature back.

Problem/Motivation

It's impossible to enter edit mode with really small viewport width (below 16.5em) because the altered contextual toolbar tab item is unclickable (floats below the first toolbar tab).

Proposed resolution

Float the item only if the toolbar is oriented OR when another toolbar tabs are floated as well.

Remaining tasks

Patch.

User interface changes

Contextual toolbar tab will be similar to other tabs if viewport width is less than 16.5em.

API changes

Nothing.

Data model changes

Nothing.

API page: https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Form!FormBuilder....

      // If $form_state->isRebuilding() has been set and input has been
      // processed without validation errors, we are in a multi-step workflow
      // that is not yet complete. A new $form needs to be constructed based on
      // the changes made to $form_state during this request. Normally, a submit
      // handler sets $form_state->isRebuilding() if a fully executed form
      // requires another step. However, for forms that have not been fully
      // executed (e.g., Ajax submissions triggered by non-buttons), there is no
      // submit handler to set $form_state->isRebuilding(). It would not make
      // sense to redisplay the identical form without an error for the user to
      // correct, so we also rebuild error-free non-executed forms, regardless
      // of $form_state->isRebuilding().

You can't set isRebuilding(). It's a getter method with no parameters. You set setRebuild(). So the first 3 mentions of this should be changed to setRebuild().

Problem/Motivation

Database drivers that extend another database driver have to add the line with something like: include_once dirname(__DIR__, 8) . '/mysql/src/Driver/Database/mysql/Connection.php';. When this line is not added, the database driver will fail the installation proces. The extending database driver is then using a class that is not autoloaded and therefor does not exist.
The include_once only works when the module with the extending database driver is in the same level in the directory structure. This is not very practical for sitebuilders. It is also not to the standard Drupal Core would like its code to be.
Example database drivers that extend another database driver are: https://www.drupal.org/project/mysql56 and https://www.drupal.org/project/pgsql_fallback.

Proposed resolution

Improve the autoloading for the parent database driver during installation.

Remaining tasks

TBD

User interface changes

None

API changes

The method Drupal\Core\Database\Database::findDriverAutoloadDirectory() has been deprecated are will be removed in Drupal 11. The method has been replaced by Drupal\Core\Database\Database::getDriverAutoloading().

The method Drupal\Core\Database\Database::determineDriversAutoloading() has been added and it returns autoload data for all available database drivers.

Data model changes

None

Release notes snippet

TBD

Enable images to be added to the body field via text formats.
goto the body field.
select an image
hist save.
You get a white screen and the error:

Error: Call to undefined method Drupal\\Core\\Image\\Image::setAttribute() in drupal-8.5.3/html/core/modules/filter/filter.module on line 843

#0 drupal-8.5.3/html/core/lib/Drupal/Core/Extension/ModuleHandler.php(539): filter_filter_secure_image_alter(Object(Drupal\\Core\\Image\\Image), NULL, NULL)\

I downloaded a brand new drupal-8.5.3 to test.
cd drupal-8.5.3/core/modules/image
grep -in setAttributes -d recurse *

There is no setAttributes.

In the api there is no reference to setAttributes
https://api.drupal.org/api/drupal/core%21modules%21image%21src%21Plugin%...

However I do see it defined for resonsive_image and media.

What happened?

Currently the content moderation and workflow modules allow site builder to apply a workflow to block types. But there is no moderated view to view those blocks in the workflow

Testing Steps

1. Enable content moderation and workflow
2. Configure workflow to work on any block type
3. Go to custom block library
4. Verify Moderated blocks tab
5. Create a block leaving in draft
6. Go to Moderated blocks page
7. Verify you see the block

Original Post

Similar to #2902187: Provide a way for users to moderate content, we need to allow users to moderate block_content entities after #2820848: Make BlockContent entities publishable.

This is currently postponed on:
#2862041: Provide useful Views filters for Content Moderation State fields
#2902187: Provide a way for users to moderate content
#2820848: Make BlockContent entities publishable

Here's how the UI looks:

Problem/Motivation

It's impossible to enter edit mode with really small viewport width (below 16.5em) because the contextual toolbar tab item is unclickable (floats below an another toolbar tab)

Proposed resolution

Float the item only if the toolbar is oriented.

Remaining tasks

Reroll the patch
Add the corresponding changes to stable9 theme.
See if similar changes are needed for olivero and claro

User interface changes

Contextual toolbar tab will be similar to other tabs if viewport width is less than 16.5em.

API changes

Nothing.

Data model changes

Nothing.

Problem/Motivation

Having a really long HTML tag (e.g. < img > with src:data/image...) makes preg_split fail and return false. On PHP 7.4 this throws a warning ("Warning: count(): Parameter must be an array or an object that implements Countable in _filter_url() (line 535 of core/modules/filter/filter.module).") and makes the field render empty, on PHP 8.0 this throws a fatal error.

Steps to reproduce

1) Have a node with content like this: https://gist.github.com/kporras07/618b3bf4cd77ff57fcd5034262220e99
2) Visit the node
3) You will get the warning and empty node or the fatal error depending on your PHP version

Proposed resolution

Wrap the for inside an if to avoid triggering this error.

Remaining tasks

1) Provide a patch
2) Review the patch
3) Commit :)

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Probably not needed

Problem/Motivation

Spin off from #3268932-49: Add methods to assert status messages to WebAssert

From https://phpunit.readthedocs.io/en/9.5/textui.html:

For each test run, the PHPUnit command-line tool prints one character to indicate progress:

. Printed when the test succeeds.

F Printed when an assertion fails while running the test method.

E Printed when an error occurs while running the test method.

and

PHPUnit distinguishes between failures and errors. A failure is a violated PHPUnit assertion such as a failing assertSame() call. An error is an unexpected exception or a PHP error. Sometimes this distinction proves useful since errors tend to be easier to fix than failures. If you have a big list of problems, it is best to tackle the errors first and see if you have any failures left when they are all fixed.

In current Drupal, WebAssert methods, in case of failure, throw a Mink exception which in PHPUnit are reported as errors and not failures. This is a bit confusing when looking at test run reports because the assertion in these cases are actually checking a condition.

Proposed resolution

Catch Mink's ExpectationException in BrowserTestBase and re-throw a PHPUnit AssertionFailedError instead, ensuring the stack trace remains intact as this is critical to debugging test failures.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Found this pre-existing issue while testing #3254202: Remove IE11 Support from Claro

"Spinner" loading icon not vertically aligned properly

In #3312481: Update core's browserlist we updated the browserlist database which determines what CSS properties PostCSS will transpile. With this update, Drupal core is not transpiling any logical properties.

However, there are certain properties which our supported browsers do not support, including flow relative properties such as `float: inline-end`, and `clear: inline-start`. You can see current browser support for these properties at https://caniuse.com/mdn-css_properties_clear_flow_relative_values.

The Chromium issue to implement this is at https://bugs.chromium.org/p/chromium/issues/detail?id=850004. I can’t find the webkit issue.

I created an upstream bug for PostCSS Logical at https://github.com/csstools/postcss-plugins/issues/632

Task

It'd be nice if either 1) this could be fixed upstream or 2) we could set PostCSS Logical to always transpile these values. But, for now, I think we need to change the float values to use non-logical CSS properties. This should be an easy task, as they're only used in a few places within Olivero.

Problem/Motivation

Config entities seem to not mirror the behaviour enforced by underlying configuration API.

The underlying configuration API behaviour is described as:

• Normally you would get the configuration as "immutable", so it can not saved & in fact will even throw an exception when you still try it (But it will contain corresponding config overrides if any are specified)
• If you want to change the configuration you need to get it as "editable", so you can save it(But it will not contain any overrides)

Configuration API

But for config entities this is not described as clearly. The only information you get is that for "admin"- routes (/admin/*) if config entities are used as route parameters, their values are ensured to be not-overriden (like e.g. routes that use an entity form); but only on those routes.

Config enties actually do not distinguish between a "immutable"& "editable" variants.
This allows for the following two code flows:
a) Loading an not-overriden version of the config entity, change it, save it:

• load/change: the entity contains not-overriden, possibly changed, values
• preSave: the not-overriden values can be compared agains the "original" version (the "original" does contain overriden values)
• save: the not-overriden values may be cast to match the configuration schema & are stored as configuration
• postSave: the not-overriden values (which may have been cast to match the schema) can be compared agains the "original" version (the "original" does contain overriden values)

b) Loading an overriden version of the config entity, change it, save it

• load/change: the entity contains overriden (possibly changed) values (the changed values might be the ones that were actually overriden or not)
• preSave: the overriden values can be compared agains the "original" version (the "original" does contain overriden values)
• save: the overriden values may be cast to match the configuration schema & are stored as configuration (At this point overriden values might be stored although they were not actively modified)
• postSave: the overriden values (which may have been cast to match the schema) can be compared agains the "original" version (the "original" does contain overriden values)

This shows on one hand that as @druken monkey described above the code in the preSave/postSave hooks/entity methods may be called with overriden or not overriden values. On the other hand it shows a bug that allows overriden values to accidentaly be leaked into the actual "editable" configuration.

Proposed resolution

• Introduce a flag to config entities like: isEditable / isImmutable / mayContainOverrides
• Per default load config entities as: !isEditable / isImmutable / mayContainOverrides
• Disallow saving entities in the ConfigEntity storage (by throwing an exception) which are: !isEditable / isImmutable / mayContainOverrides
• Maybe add a method on config entities / simply use the ConfigEntityStorage::loadOverrideFree to get instances that are flagged as: isEditable / !isImmutable / !mayContainOverrides
• Since all config saved would now be ensured as not-overriden, preSave hooks/entity methods should get an not-overriden original
• postSave hooks/entity methods would also get a not-overriden original
• If someone needs an overriden original in preSave, they could simply load an overriden version (as the changes are not yet persisted)
• If someone needs an overriden original in a postSave hook / method, they could could theoretically set it as a seperate Field like maybe 'overridenOriginal' in a corresponding preSave hook/ method so they cant it get's passed along to postSave hook/ method
• A generic 'overrideOriginal' solution would also be possible but would need to be implemented at the storage level (the "original" should be unset at the end, but because entity->postSave ist called before the entity hooks this could not be done in the config entity class)

This way the beghaviour would be more in line with the underlying configuration API & And preSave/postSave hooks/entity methods work with a more predictable context.

Remaining tasks

• Introduce a new base class, interface & storage
• Decide what to do with the existing config entity related classes (merge changes into them, deprecate them, change them to not allow config overrides ...)

API changes

• Introduces new Classes & an Interface / expands the existing ones (OverrideSupportingConfigEntityInterface, OverrideSupportingConfigEntityBase& OverrideSupportingConfigEntityStorage)/li>

Data model changes

No changes, the overriden data only resides in the class and is not persisted.

Original report by drunken monkey

In the Search API (#2682369: Fix problems with overridden config entities) we've discovered problems when using config overrides with config entities, which I think could affect other modules as well, and might therefore be better solved in Core than in each of them separately.

The root cause of the problem is basically that an entity update will mix non-overridden and overridden entities in non-obvious ways.
Specifically, config entities are by default not overridden when loaded for admin routes, where most of the changes probably occur. But when saving such an entity, the original that is loaded is loaded with overrides, so when any pre-/post-save code tries to assess the changes done to the entity, it will inevitably end up with wrong results when comparing overridden properties.

Ideally, I think, both the "current" and the "original" entity used would show all the overridden values, so that really only those properties that effectively changed their value are actually detected as changes.
However, especially for the pre-save code, this is probably not that easy to do, and doing it just for post-save might just add more confusion.

So, this is more meant as the start of a discussion, or a request for other solutions.
Do you even agree that this is a problem? And, if so, how can we solve it?

Problem/Motivation

The "views-view-field.html.twig" template has the following comment:
"When fetching output from the row this construct should be used:
data = row[field.field_alias]"
The above will guarantee that you'll always get the correct data, regardless
of any changes in the aliasing that might happen if the view is modified.

but this is not possible, because the row is the object of the Drupal\views\ResultRow class.

Steps to reproduce

Try to get and render a field value in the suggested way:
{{ row[field.field_alias] }}

Proposed resolution

Remove this comment or replace it with another, for example, with this one:
"You can fetch values of other fields like this:
data = view.field.field_myfield.original_value
data = row._entity.title.value
data = row._entity.field_myfield[0].value"

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Motivation

Creating a site's primary navigation is one of the most time-consuming parts of creating a Drupal site. The primary nav needs to function both in desktop and mobile mode.

Tasks

Bring Olivero's basic menu into starterkit theme.

To decide

Should this be behind a theme setting?
If so, should it be enabled by default?

I enabled the update feature that emails me whenever the site has an update available. I noticed that the time the email gets sent is always incremented by one cron run. For example, I have cron running hourly, so if there are updates needed it will email me at 8am, the next day at 9am, the next day at 10am, etc. But, based on the math, whatever interval cron runs at the email will likely always be one run later.

In hook_cron, the if statement requires the current time to be greater than interval (in my case, 24hrs). If it is exactly 24hrs, it will not pass.

function update_cron() {
  $frequency = variable_get('update_check_frequency', 1);
  $interval = 60 * 60 * 24 * $frequency;
  // Cron should check for updates if there is no update data cached or if the
  // configured update interval has elapsed.
  if (!_update_cache_get('update_available_releases') || ((time() - variable_get('update_last_check', 0)) > $interval)) {
    update_refresh();
    _update_cron_notify();
  }
}

Also, 'update_last_check' is set in _update_refresh(), after some work is done. You only need enough time between a cron run and the setting of 'update_last_check' for a second to turn over to guarantee this not running at the same time.

In my install, I moved the variable_set for 'update_last_check' from _update_refresh() to the first thing inside this if, and change the operator to >= (as the difference more often ends up exactly zero). It has been working for several days, sending the update email at the same time.

(On a side note, it would be nice if there was a setting to say exactly when to send email updates.)

Problem/Motivation

In the documentation for EntityStorageBase::create it is written:
array $values: (optional) An array of values to set, keyed by property name. If the entity type has bundles, the bundle key has to be specified.

However there is no guidance on how to set the bundle key.

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21EntityStorageBase.php/function/EntityStorageBase%3A%3Acreate/9.1.x#comment-65782

Steps to reproduce

Proposed resolution

To set the bundle key, it seems like you have to use the 'type' key in the array. This should be specified to make the documentation less ambiguous.

Remaining tasks

Review patch / give feedback

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Problem/Motivation

This is a follow on from #2923701: Mechanism to disable preprocessing of node base fields so they can be configured via the field UI. If the mechanism from that issue is in use then the title appears twice on the page /book/export/{type}/{node}.

NB If the mechanism from #2923701 is not in use, then the book export is also wrong - this is #3090234: Broken node theming for book export

Steps to reproduce

1. Follow the steps in the change record
2. Enable the book module
3. Create a node and make it part of a book
4. View the printer-friendly version

Proposed resolution

The book module should respect the entity type property enable_base_field_custom_preprocess_skipping.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

None

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet