Problem/Motivation

A custom form previously used an entity_autocomplete field with the views selection handler. Upon upgrading to 9.3.0, the handler settings produce the following error:

AssertionError: Cannot load the "view" entity with NULL ID. in assert() (line 295 of /core/lib/Drupal/Core/Entity/EntityStorageBase.php).

The custom field's code is:

    $form['node_id'] = [
      '#type' => 'entity_autocomplete',
      '#title' => $this->t('Node Selection'),
      '#target_type' => 'node',
      '#required' => true,
      '#selection_handler' => 'views',
      '#handler_settings' => [
        'handler_settings' => [
          'view' => [
            'view_name' => 'entity_references',
            'display_name' => 'entity_reference_9', 
            'arguments' => []
          ]
        ]
      ]
    ];

Problem/Motivation

I have updated my site completely to the newest 9.3 version. In this I have a node with paragraphs as my theme homepage. And theme homepage gives WSOD with the following error on latest 9.3:

The website encountered an unexpected error. Please try again later.
TypeError: Argument 1 passed to Drupal\Core\File\FileUrlGenerator::generateString() must be of the type string, null given, called in httpdocs/web/sites/default/files/php/twig/61b7c1cc12197_paragraph--view_referance_kTM91Di4YhANCpjtiZ2FlHIET/OWkkQEG98F61u897Zzc3agnP4Cd1gZmHLd6BGlNRCH0.php on line 41 in Drupal\Core\File\FileUrlGenerator->generateString() (line 58 of core/lib/Drupal/Core/File/FileUrlGenerator.php).

After some research I removed all paragraphs from the node, and then the WSOD and error is gone.

Steps to reproduce

When I add one custom-html paragraph with just the word 'test' the WSOD and error is back again.

Proposed resolution

I tried adding this https://www.drupal.org/files/issues/2020-01-06/added_empty_check_on_uri-...
to to /lib/Drupal/Core/File/FileUrlGenerator.php but error still stays.

Proposed solution, take care that Argument 1 is not null.

Remaining tasks

User interface changes

API changes

Data model changes

Greetings and thanks in advance for looking into this,
Martijn

After upgrading from Drupal 8.9 to Drupal 9.0 I get the two following error/warning messages when trying to create new content using some (not all) of my content types, among them the native “page”-type:

Error message:

The website encountered an unexpected error. Please try again later. Error: Call to a member function getAccountName() on null in Drupal\node\NodeForm->form() (line 155 of core/modules/node/src/NodeForm.php).

Warning message:

call_user_func() expects parameter 1 to be a valid callback, class 'Drupal\node\Entity\Node' does not have a method 'getCurrentUserId' in Drupal\Core\Field\FieldConfigBase->getDefaultValue() (line 397 of core/lib/Drupal/Core/Field/FieldConfigBase.php).

Does anyone know what causes this?

Root cause

• This issue may affect sites that were originally built with an earlier Drupal 8 version than 8.6.x and which were upgraded to Drupal 9.
• The reason is that Node::getCurrentUserId method was deprecated in 8.6.x and was removed in 9.0.0. The replacing method in Drupal 9 is Node::getDefaultEntityOwner
• Configuration entities that are still having a reference to the removed method will trigger this bug.
• Note that other entity types than Nodes (e.g. Media) can also be affected.

Workaround

The following workaround steps are for Node entities but should be quite well applicable for other Entity types as well.

1. You want to identify those Node content types that are affected by this issue.

2. You can either a) do this by trial and error i.e. try to create new nodes for each content type on your site and see which content types are affected OR b) you can export your configuration and search for 'getCurrentUserId' to get a list of configuration files that are affected. The following steps use approach b) using Drush command line tool on Linux.

3. Export all configuration from command line using drush config:export

4. Navigate to your config/sync directory.

5. Identify the affected configuration files using

grep -R "getCurrentUserId" *

. The files matching this search will be like core.base_field_override.node.CONTENT_TYPE.uid.yml, for example core.base_field_override.node.page.uid.yml. As mentioned above, other entity types than nodes might also be affected.

6. For each affected configuration file, first take a backup of the configuration file. Then, use your favorite text editor and replace default_value_callback: 'Drupal\node\Entity\Node::getCurrentUserId' with default_value_callback: 'Drupal\node\Entity\Node::getDefaultEntityOwner' in each affected configuration file. If your site is affected by some other Entity type than Node, you will need to modify this find / replace according to your entity type.

7. Once you have edited all affected configuration you can double check with grep -R "getCurrentUserId" * that you did not miss any affected configuration file.

8. Once you have fixed all affected configuration files, you will need to import these configurations from your config/sync directory back to your database. This can be done with drush config:import

9. After you have imported the configurations, you will need to rebuild your caches. This can be done with drush cache:rebuild

10. Test and verify that you are now able to create new nodes of the affected content types.

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Hi all.
I enabled the “Require email verification when a visitor creates an account” flag to validate email address as part of registration process.
I also enabled “RESTful Web Services” module enabled to trigger registration flow in my headless Drupal ContentaCMS installation through the /user/register endpoint.

Issue description
I found the following issue:
- when a user is created via /user/register?_format=json REST endpoint, the status after creation is “Blocked”
- the onetime password is generated and the email with the one time link is correctly sent to the user
- BUT, after clicking on the link sent via email, the user is getting 403 Access Denied pageI went through the code and I found this ‘if’ in the getResetPassForm(Request $request, $uid) in User.Controller.php

    if ($user === NULL || !$user->isActive()) {
      // Blocked or invalid user ID, so deny access. The parameters will be in
      // the watchdog's URL for the administrator to check.
      throw new AccessDeniedHttpException();
    }

It looks like Blocked user cannot execute password reset (which makes perfectly sense to me).

I checked the same scenario by creating a user through standard Drupal login page (no REST).
After the creation, the user status is set to Active and the email verification process can be completed without issues.

Conclusion
- only user created via /user/register?_format=json cannot finalize the email verification, since their account is blocked.

Workaround
To overcome this issue I enabled Rules module to trigger the following rule
- event: After Saving a new User
- action: unBlock User
This rule is executed every time a new user is created and moves the status from Blocked -> Active

This is a followup from #3086514: Investigate use of the changing color themes for Olivero.

We want to implement color changing themes within Olivero

Olivero currently has a single blue theme (along with gray colors). We want the user to be able to change this to support their specific branding.

Plan

• This will be done through the use of theme settings to set CSS variables.
• Within #3217924: Olivero: Convert all colors (blues and grays) to HSL and normalize hues and saturations. , we will convert all of the colors to HSL format.
• We will then consolidate and rename the colors within #3217926: Olivero Rename blue name-spaced variables to primary, and rename numbers to correspond with luminosity

Theme settings UX

1. The site builder will navigate to the theme settings page
2. Will have an option to either 1) Select color via color picker or 2) paste in a hex value
3. The hex value will be saved to config
4. config value will be pulled in and processed by PHP to determine hue
5. Hue will then be output as CSS custom property, which will then be utilized by the CSS.

Followup issues

• Provide accessibility contrast feedback when selecting colors
• Implement secondary color option when allowing users to select Olivero color scheme

Problem/Motivation

We use Doctrine's annotations to add metadata to our classes. For example, Block's use annotations to set the block ID and admin label. PHP 8.0 introduced a new language feature PHP attributes to support such metadata.

Proposed resolution

• Add support for PHP attributes
• Deprecate doctrine annotations for removal in Drupal 11.

Here's an example of a block annotation:

/**
 * @Block(
 *   id = "system_powered_by_block",
 *   admin_label = @Translation("Powered by Drupal")
 * )
 */
class SystemPoweredByBlock extends BlockBase {
  // ...
}

PHP attributes options

Use named arguments

#[Block(
  id: "system_powered_by_block",
  admin_label: "Powered by Drupal"
)]
class SystemPoweredByBlock extends BlockBase {
  // ...
}

Use arrays

#[Block(array(
  "id" => "system_powered_by_block",
  "admin_label" => "Powered by Drupal",
))]
class SystemPoweredByBlock extends BlockBase {
  // ...
}

Use individual attributes

[#BlockId("system_powered_by_block")]
[#BlockAdminLabel("Powered by Drupal")]
class SystemPoweredByBlock extends BlockBase {
  // ...
}

Problems to solve

• How to support @translation. Nested attribute support was only added in PHP 8.1 - see https://wiki.php.net/rfc/new_in_initializers#nested_attributes
• The unused use sniff we use is problematic - need to move to slevomatic version - #3010032: Add dependency on slevomat/coding-standard

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Some users who have the authority to administer the site might overreact to the scary red messages that show up on the screen if they bump into the admin/logs/updates page or module listing page.

This module adds permission to limit who can see the warnings, who can see the list of modules that need to be updated, and who can change the settings. It's designed to stop pesky inquiries from admins who might misinterpret the update status warnings as critical failures that must be attended to immediately.

Alternative approaches

There are three different approaches to this problem, to be discussed which one to use finally. Afterwards both others should be closed as duplicate:

• #2059375: Update notification messages as an option in settings
• #3239970: Show update notifications only with permission "administer software updates"
• #332796: Add permissions to the update.module to hide warnings (THIS)

Problem/Motivation

Currently the update notification ("Update available") is shown to all users with the permision "administer site configuration", while there is already a permission "administer software updates" which is not used for that.

This leads to the issue that users who are not allowed to update see this message. In many cases, this are customers who are then affraid as they don't understand what they can (not) do and what are the consequences.

There are already two different approaches for this problem:
#332796: Add permissions to the update.module to hide warnings
#2059375: Update notification messages as an option in settings

Both are ready for review. This is the third one and most lightweight. I'd like to suggest to simplify things and only show the message to people who are able to act upon that. Technically that means, the message should be shown to users with the permission "administer software updates" and no more to the more general "administer site configuration" who can see this in the status report.

Steps to reproduce

Use a Drupal project with available updates and "administer site configuration" permission, but without "administer software updates" permission and be confused ;)

Proposed resolution

No need for additional permissions or configuration, which complicates things and can lead to logical problems like eventhough the permission is set, also requires the "administer site configuration" to see the message and "administer software updates" to run the updates... too complex solutions for a quite simple problem.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Credits

Huge THANKS to @voleger who did a great job in the both other issues to create the patches!

Alternative approaches

There are three different approaches to this problem, to be discussed which one to use finally. Afterwards both others should be closed as duplicate:
#332796: Add permissions to the update.module to hide warnings
#2059375: Update notification messages as an option in settings
#3239970: Show update notifications only with permission "administer software updates" (THIS)

Problem/Motivation

We now have the method Drupal\Core\Database\Connection::prefixTable($table) which returns the prefix for the table. In D9 and before there was the possibility to have different prefixes for different tables. In D10 there is only a single prefix for all tables. The method and its parameter suggest that it is still possible to have per table prefixing. This does not improve the developer experience.

Proposed resolution

Deprecate method Drupal\Core\Database\Connection::prefixTable($table) and create the new method method Drupal\Core\Database\Connection::getPrefix(). The new method has no parameters. It just return the class variable $prefix.

Remaining tasks

TBD

User interface changes

None

API changes

See propesed solution.

Data model changes

None

Release notes snippet

TBD

Problem/Motivation

It is currently not possible to configure an audio file using FileAudioFormatter to be muted by default.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/audio#Attributes

Solution

This configuration currently exists in FileVideoFormatter and works properly. Since both the audio and video formatters share FileMediaFormatterBase, moving the muted setting to that class provides this option to both formatters without breaking any existing config for videos.

Problem/Motivation

In #3255504: Remove jQuery dependency from date.js, @alexpott wrote:

Looking at #3202818: Remove untrue declaration of Opera Mini (in reverse proxy mode) support from Drupal 9.3 we don't support Opera Mini - so I think we can file a follow-up issue to completely remove the library in Drupal 10.0.x and deprecate it in Drupal 9.4.x

See that issue for more details. Deprecate the library.

API changes

core/drupal.date is deprecated. No replacement is needed.

Release notes snippet

JavaScript library core/drupal.date is deprecated. No replacement is needed because no supported browsers require it.

Steps to reproduce: just change the body field cardinality to unlimited, create a new node and press the "Add another item" button.

Found while working on #362021-37: field_attach_prepare_translation needs to be updated for D7 API.

Problem/Motivation

When using a theme that has hidden: true set in it's .info.yml file as the default theme, I believe the expected behavior is that it should still appear on appearance settings page. However it is currently not displayed. The theme settings are still available via the toolbar menu, though, and can be seen by going to Appearance > Settings.

Steps to reproduce

Set a theme that has hidden: true in it's .info.yml file as the default theme and view the Appearance settings page (/admin/appearance).

Proposed resolution

Adjust https://git.drupalcode.org/project/drupal/-/blob/9.4.x/core/modules/syst... to either incorporate the ThemeHandler::hasUi method or check the status of the theme as well as if it's hidden (so change SystemContrroller:216 to if (empty($theme->status) && !empty($theme->info['hidden'])) {.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

I found that it's possible to upload SVG images to Drupal 7 (7.38) and they can even be rendered as the original image, but any image styles don't work (obviously since gd doesn't support SVG). Of course there is the imagemagick module that one could try to use and possibly patch, but it didn't seem to work out of box either. I thought that it would be great to add basic SVG support to Drupal core since many browsers support them and they are great for todays world with different screen sizes etc. By basic support I mean that the SVG images would work with styles, not applying the ones that can't be done without gd or similar image manipulation tool, but simply bypassing the styles and applying for example width and height to the img tag directly when theming the images.

Follow-up from #1497374: Switch from Field-based storage to Entity-based storage, by @plach in #248:

There's only one thing that I'd really wish to see changed: currently the views integration code of the Field module treats every class extending the DatabaseStorageController as a SQL implementation. IMHO this is an unneeded limitation, as already pointed out above by @fago: should someone need to write an alternative SQL storage controller, she would be forced to extend
the core one with all its assumptions about the underlying implementation. I'd suggest instead to provide an interface, e.g. SqlStorageControllerInterface and make DatabaseStorageController implement it. The current pseudo-private static methods could be refactored and moved onto that interface, becoming regular methods, and then the views integration code could just check whether the storage controller implements SqlStorageControllerInterface.

I realize that those methods were not made part of the public API intentionally, but I think that since there are legal use cases for needing to retrieve some details about the storage implementation (Views integration being the most obvious), we should provide an actual API that code needing to deal with SQL can properly rely on. Doing the opposite IMHO will just "authorize" people to find the most sneaky ways to circumvent the Entity Storage API. I think a SqlStorageControllerInterface marker interface would be enough for this issue, as I guess that a proper API allowing to describe any SQL table layout would not use the static methods in the current form. Refactoring those would totally be a follow-up.

Creating this issue to discuss and implement that.

Problem/Motivation

If page contains elements with same class or id, and ajax call just targets those one of the element, then the ajax effect is only applieeed to the 1st element.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

This looks like a bug although maybe I'm just not understanding something.

If you look at drupal_cron_run() it has lock functionality which prevents more than one cron process from running at once.

However, the code which processes queue items during cron lives outside of that lock, and thus queue items will be processed every single time cron is called.

This could be an issue especially when combined with the "poormanscron" feature in core. For example, when one (unlucky) person triggers the cron process and gets a slow page request, then before it's complete everyone else who happens to visit the site during that time period seems like they will trigger the processing of queue items (even if they don't trigger the full cron processing) and therefore they might all get slow page requests too..

When you create a Field Type of Text (formatted, long, with summary) you get an option to check for Summary Input which allows you to have a field to explicitly set a Summary. This field is only visible, however, if the Allowed number of values in Field settings is Limited to 1.

Using the 'Unlimited' option or defining values greater than 1 causes the form to auto-hide the Summary field and label. The markup is there, but inline css on the element is setting the display to none.

<div class="js-text-summary-wrapper text-summary-wrapper" style="display: none;">
    ...
 </div>

Migrating node content from older Drupal system to Drupal 8 may carry some contents that have image with image_style that doesn't exist in the Drupal 8 system. In our case, image styles (Default, Preview) are exists in Drupal 7, but not in Drupal 8.

After migrating such content, and viewing it, the image module throw an error and preventing the node page render.

Call stack:
<strong>Call to a member function transformDimensions() on null in template_preprocess</strong>
template_preprocess_image_style(Array, 'image_style', Array) (Line: 287)
Drupal\Core\Theme\ThemeManager->render('image_style', Array) (Line: 437)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array) (Line: 490)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 54)
__TwigTemplate_b990021d9c53bb62452fd087f46528a41d0dcfebc30a9afe45ba263b28f82647->doDisplay(Array, Array) (Line: 432)
Twig_Template->displayWithErrorHandling(Array, Array) (Line: 403)
Twig_Template->display(Array) (Line: 411)
Twig_Template->render(Array) (Line: 64)
twig_render_template('core/themes/classy/templates/field/image-formatter.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('image_formatter', Array) (Line: 437)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 450)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array) (Line: 154)
Drupal\entity_embed\Plugin\Filter\EntityEmbedFilter->Drupal\entity_embed\Plugin\Filter\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 155)

One way to solve this is to recreate the missing image style in the new system. But in case someone doesn't want that, at lease the page rendering should failed gracefully.

Instead of throw error upfront and prevent the entire page from rendering. I suggest it should "Inform the site builders why their image didn't work." Part of the image module has done that, but not in above senario.

Attached is the patch, open for suggestion.