Problem/Motivation

The default AJAX progress throbber icons looks poor on a retina display.

• throbber-active.gif is a low resolution animated GIF.
• throbber-inactive.png is a low resolution static
  PNG.

Note: some instances of .ajax-progress-throbber currently reference throbber-active.gif, while others reference loading-small.gif. loading-small.gif is being worked on in a separate issue #2575253.

Proposed resolution

• Replace throbber-active.gif with a high resolution animated SVG throbber-active.svg.
• Replace throbber-inactive.png with a high resolution static SVG throbber-inactive.svg.
• Maintain existing image size, color, and animation speed from the originals.
• Replace references to each file in core ajax-progress and autocomplete stylesheets.
• Replace references to each file Stable theme.
• Redirect old GIFs to new SVGs in core's bundled .htaccess file.

Codepen for before/after comparison:
https://codepen.io/jameswilson/full/LYoZaXy

Before:

Inactive:
Active:

After:

Inactive: throbber-inactive.svg
Active: throbber-active.svg

Note: server limitations on uploading SVGs and/or rendering images from git.drupalcode.org prevent us from displaying the proposed SVGs inline here. See the Codepen for a better comparison.

Remaining tasks

1. Ensure that overriding throbber's is as easy as possible and provide instructions for how themers can use libraries-override.
   COMPLETE: (See Docs → Theming Drupal → Update the throbber
2. Override core's default throbber design in the Olivero theme, to help document an approach for themers to follow.
   COMPLETE: (See Olivero's throbber.svg).
3. Create a patch.
4. Review the code changes.
5. Manually test and upload before/after screenshots.
6. Since Seven was removed from core, copy issue credits from folks who worked on #2775725: Update throbber icon in Seven theme that was split out from this issue while Seven theme was still in core.

User interface changes

Users on devices with high resolution screens will see a crisp image with no diffusion artifacts or blur inherent from legacy image formats.

Users on devices with low resolution may or may not notice much of a visual difference.

API changes

In as much as images can be considered an "API", the old GIF files will be removed. In case any themes still reference the old images, the routes to these static assets can be redirected at the server level to the new SVG assets. Such redirects have been added to the .htaccess file shipped with Drupal core.

Problem/Motivation

When a view with an exposed form (or another form using GET as #method) is being rendered using a lazy builder and that form throws a EnforcedResponseException (for example when the exposed form reset button is pressed), big pipe does not handle this exception; the redirect will not happen.

Steps to reproduce

Using Views Reference Field and a view with exposed filters and ajax:

1. Enable Views
2. Install module BEF
3. Create a view with some exposed filters, enable ajax, enable BEF and activate showing the Reset button.
4. Install module Views Reference Field (> 8.x-2.0-beta4)
5. Create a content type with a field View Reference and configure it to allow selecting the view created.
6. Add a node and select the view
7. View the page and use some exposed filters, then when the reset button appears, press it

It will reload the page showing an error instead of the view.

Proposed resolution

Have Big Pipe catch the EnforcedResponseException and send a redirect response ajax command.

Remaining tasks

None

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Big Pipe now handles redirect responses in GET requests.

Problem/Motivation

In #2800605: Warn/inform users when the hosting environment has a too low limit of APCU cache we did not consider that ByteSizeMarkup::create returns a translated string representation of the size.

Steps to reproduce

1. Need to make sure that PHP compile with APCu support and APCu cache was enabled
2. If site has only English language, needs to add another language, Russian or example.
3. Needs to set non-English language to admin user and go to site Status Report

Proposed resolution

Force set English for ByteSizeMarkup::create function

Result

Before patch:

After patch:

Problem/Motivation

The docs say:

   * @param string $field
   *   If it doesn't contain a dot, then an entity base field name. If it
   *   contains a dot, then either field name dot field column or field name dot
   *   delta dot field column. Delta can be a numeric value or a "%delta" for
   *   any value.

But you can chain through relationships, as seen in the test EntityQueryRelationshipTest:

      ->condition("user_id.entity.name", $this->accounts[0]->getAccountName(), '<>')

      ->condition("user_id.entity:user.name", $this->accounts[0]->getAccountName())

Steps to reproduce

Proposed resolution

Rather than document this fully here, we should refer to the comprehensive docs at Drupal\Core\Entity\Query\QueryInterface::condition()

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The batch API takes callbacks, but these have to be functions or static methods on classes.

If we use the callable resolver, we can also allow callbacks in service notation, that is, in the form 'my_service:methodName'.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Found working on #3352851: Allow assertions on the number of database queries run during tests.

MariaDB [db]> SELECT FROM_UNIXTIME(created) FROM node_field_data;
+------------------------+
| FROM_UNIXTIME(created) |
+------------------------+
| 2023-11-07 21:42:54    |
| 2023-11-07 21:42:54    |
| 2023-11-07 21:42:54    |
| 2023-11-07 21:42:54    |
| 2023-11-07 21:42:54    |
| 2023-11-07 21:42:54    |
| 2023-11-07 21:42:54    |

Views like related recipes are ordering by created timestamp, but because it's the same, this can mean random results.

Steps to reproduce

Proposed resolution

Add a second to each node as it's created, or give them specific, fake, backdated dates.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Email FAPI element was added without support of multiple attribute. See https://www.drupal.org/project/drupal/issues/1174620#comment-4564144.

Currently even if the attribute set directly through #attributes property Drupal does not accept comma-separated emails.

Steps to reproduce

• Add to any form an email element

$form['email'] = [
  '#type' => 'email',
  '#title' => $this>t('Email'),
];
 

'#attributes' => ['multiple' => '']

Proposed resolution

Support "multiple" attribute same way as for select lists.

$form['emails'] = [
  '#type' => 'email',
  '#title' => $this->t('Emails'),
  '#multiple' => TRUE,
  '#description' => $this->t('Comma-separated email addresses.')
];

• Allow to add multiple attribute via #multiple element property
• Update element validation to support #multiple property

Later, it will be possible to add this option to Email fields as well, but first, an element itself needs to comply with the HTML documentation.

Remaining tasks

Confirm there are no implications here for things like \Drupal\Core\Field\Plugin\Field\FieldFormatter\MailToFormatter that expect a single email address.
Items in the MR
#44
#45
Review
Commit

User interface changes

NA

API changes

The API of the Email Render element must be updated.
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Render%21...

Data model changes

NA

Release notes snippet

Provide multiple attribute support for Email render element.

Problem/motivation

This issue was openend way back and referenced in the json:api code. Since this issue is deemed outdated, the reference to the issue should be removed from core.

Remaining tasks

Remove reference to this issue from: core/modules/jsonapi/src/Normalizer/JsonApiDocumentTopLevelNormalizer.php:217

Old IS

Issue title pretty much says it all, but there are certainly other clean-ups to be done in the exception classes, like these static \Drupal:: bits:

$error['links']['via']['href'] = \Drupal::request()->getUri();

and

$resource_type = \Drupal::service('jsonapi.resource_type.repository')->get($entity_type_id, $bundle);
$resource_type_name = $resource_type->getTypeName();
$route_name = !is_null($relationship_field)
  ? "jsonapi.$resource_type_name.$relationship_field.related"
  : "jsonapi.$resource_type_name.individual";
$url = Url::fromRoute($route_name, ['entity' => $entity->uuid()]);
$errors[0]['links']['via']['href'] = $url->setAbsolute()->toString(TRUE)->getGeneratedUrl();

Problem/Motivation

Following the update to PHPStan 1.11 we can now use the more specific @phpstan-ignore instead of @phpstan-ignore-next-line, where we can now specify exactly what we are ignoring so other errors on the same line do not get ignored.

Documentation for this feature is at https://phpstan.org/user-guide/ignoring-errors#ignoring-in-code-using-ph...

Steps to reproduce

Proposed resolution

Remove all @phpstan-ignore-next-line.
Run PHPStan in verbose mode.
Re-add all comments back using @phpstan-ignore with the specific error identifier.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

There were some poking around on our site and they were looking for security holes. This is related to #3378487: Validating String Encodings Before Insert but for a specific probe that I think we can solve.

Steps to reproduce

1. Setup a select field exposed taxonomy filter in a View
2. Pass in a incorrect string through the get arg: https://site.test/news?tags%5B0%5D=4978&year=%FF%FE%3Cscript%3Ealert%282...

Proposed resolution

Encode the values as UTF8

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Hi Team

Drupal Version 9.5.10

I've had an email from our server guys highlighting a possible security issue.

It appears we've had a malicious bot attack which was blocked but the logs show the error below:

"NOTICE: PHP message: Uncaught PHP Exception Drupal\Core\Entity\EntityStorageException: "SQLSTATE[HY000]: General error: 1366 Incorrect string value: '\xC0\xA7\xC0\xA2%2...' for column 'value' at row 1: INSERT INTO "webform_submission_data" ("webform_id", "sid", "name", "property", "delta", "value") VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3,

My understanding is that the submission was supposed to fail, this is what the spambot was trying to do in order to force a hard PHP error, which it can then use for another, more specific attack.

The server team explained it like this:

Someone (bot) is POST'ing non-unicode probably just binary data to it. So in short form something like:

POST field = \xC0\xA7\xC0\xA2.... spam
... no validation ...
INSERT INTO webform_submission_data VALUES value = \xC0\xA7\xC0\xA2...

As \xC0 is not a valid style byte for a unicode value MySQL is rejecting the INSERT with an error which is bubbling up and being raised as an Drupal\Core\Entity\EntityStorageException.

The actual data prefixed with \xC0\xA7\xC0\xA2 seems to be just spam, badly double-encoded something or other who's purpose is unclear. It was sent by a malicious scanner though so I would assume it's used to trigger or indicate some kind of security issue somewhere. I doubt in this instance it's actually unsafe, MySQL is quite correct to reject it. You generally shouldn't rely on database insert data validation though.

Any POST data to a form that generates a hard PHP error is a major security risk (likely due to type coercion bugs). It can lead to exploits and leaks from the database, even from something as basic as missing type handing.

Conclusion

Although this sounds like a Webform issue, I've already raised the issue and the reply was, "The Webform module uses core's ContentEntityBase API for managing submissions, and that's what would be responsible for the data submission. Drupal's standard operating logic is to accept all data and then filter it on display. As such, the database query should allow the data to be saved, so the fact that it failed to save suggests a bug somewhere."

Again, my understanding is that the query was supposed to fail to throw a hard PHP error. After some discussion we decided it was a "core issue to validate the encoding of every inserted string. It's a big "ask", it's a security hardening and it needs input from the community."

Any advice of how I'd add an extra layer of validation/sanitisation to the core's ContentEntityBase API?

Problem/Motivation

When a filter that uses a placeholder, without arguments, is configured in a text format, to run before the filter_htmlcorrector filter, the first filter's placeholder is not replaced on rendering the text. The drupal-filter-placeholder element remains.

A filter might use a placeholder without arguments simply to postpone rendering something that may be expensive to build. I haven't seen any examples in core, but I've come across a custom one before that builds a form in place of a custom token in text.

This is an issue since Drupal 10.2, which started using masterminds/html5 in #2441811: Upgrade filter system to HTML5. I would guess it's still the same in later versions, though I haven't actually tested yet.

Steps to reproduce

1. Configure a text format:
   1. Enable a filter that uses a placeholder without any arguments (I'm not aware of any in core, sorry).
   2. Enable core's 'Correct faulty and chopped off HTML' filter and ensure it runs after that.
2. Make some content that uses that text format and which would cause that first filter's placeholder to be used.
3. Expected result: the placeholder is replaced. Actual result: the drupal-filter-placeholder element remains.

Proposed resolution

Do not add the arguments attribute to the placeholder markup when it is empty, so that the placeholder does not get altered by the filter_htmlcorrector filter. (This would then match the behavior of \Drupal\Core\Render\PlaceholderGenerator::createPlaceholder().)

Remaining tasks

Review MR.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

Problem/Motivation

This code in Renderer is being too clever:

      assert(count($elements['#lazy_builder'][1]) === count(array_filter($elements['#lazy_builder'][1], function ($v) {
        return is_null($v) || is_scalar($v);
      })), "A #lazy_builder callback's context may only contain scalar values or NULL.");

Instead of a fancy count and array_filter callback, just use a plain foreach, and that way the assertion can say which parameter is the problem.

It's not always clear from looking at the code which thing is not a scalar!

Steps to reproduce

Make a render array with a #lazy_builder element and put an object or an array as one of the parameters.

Proposed resolution

Change the assertion message to give the index of the parameter causing the problem.

Remaining tasks

Answer #8
Manual testing

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In #2994696: Render embedded media items in CKEditor, we added the ability for media items embedded in formatted text to be previewable in CKEditor. The previews are fully rendered media entities. The problem, though, is that if those media entities have attached asset libraries, those libraries are NOT included as part of the rendered preview.

This is totally intentional, for reasons that can be summed up as "overwhelming, unjustified complexity". As Wim Leers stated in #2994696-214: Render embedded media items in CKEditor:

We specifically do not want to load asset libraries associated with a rendered entity because A) that would also load JS, and we don't want previews to become interactive, they're just previews, B) a rendered media entity's hypothetical attached CSS (because there isn't any in Drupal core) would be written with the assumption that basic theme CSS is already present, which is not true in CKEditor iframe instances.

[...] Media entities rendered by Drupal don't have asset libraries attached by default. I explained above why we don't want this. I can expand on it more if you like. Loading attached CSS and JS — problematic as it is for the reasons I've outlined already — would require us to use the AJAX system. This would mean that requests would use the back-end theme instead of the front-end theme, thus loading both the wrong template (that of the admin theme) and the wrong asset libraries (those of the admin theme). It would also make the responses uncacheable (AJAX responses are uncacheable). If you want the nitty gritty background, see #2844822: The preview in CKEditor does not use the same Twig template as the one on the front end (default theme). Specifically, see #2844822-41: The preview in CKEditor does not use the same Twig template as the one on the front end (default theme), where I anticipated this would come up 🙉. Entity Embed prior to 1.0 was using the AJAX system. One early user with a super advanced use case needed it. They acknowledged it would not work for everyone always. Many people ran into the problem of the wrong Twig template being used. By now 23% of all Drupal 8 Entity Embed installs is using 8.x-1.0 where no AJAX request is used, and hence no CSS or JS is loaded. There have been no complaints. (I just triaged the Entity Embed issue queue again to make sure.)

We agreed to open this issue as a place to further discuss this, if it's requested by enough people.

Proposed resolution

TBD

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Release notes snippet

TBD

Problem/Motivation

After #3427413: Stop using action in user module in role entity hooks and #3413949: Move some Action plugins to Action module we could consider moving the configurable user actions to the actions module, since they don't necessarily make sense without a UI.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In #540008: Add a container parameter that can remove the special behavior of UID#1 an approach was taken where we can simply flag tests that are failing if we turn off user 1's super user powers, so that they can be taken care of in a followup. This issue is to collect all of these followups.

The goal is to have no tests in Drupal core that rely on UID1's special privileges so that we:

1. Know these tests are correctly assigning the necessary permissions to run
2. Can turn off the super user access policy in D11, knowing it won't break core
3. Can remove the super user access policy in D12, providing an admin account recovery tool to replace it

Steps to reproduce

Go into any of the tests flagged with:

  /**
   * {@inheritdoc}
   *
   * @todo Remove and fix test to not rely on super user.
   * @see https://www.drupal.org/project/drupal/issues/3437620
   */

And:

1. Remove the code below that sets the usesSuperUserAccessPolicy to TRUE.
2. Run the test to see which test methods are failing:

core/modules/file/tests
• src/Kernel/SaveTest.php

Proposed resolution

Assign the right permissions to make the test go green without the super user access policy. Those few tests that specifically test said policy can obviously stay, but will be removed along with the policy in D12.

Remaining tasks

MR to commit

MR 8651

Problem/Motivation

Hi, I'm running into a problem that the `entity_reference_label` formatter does not check the URL access to the entity, but only relies on checking the access to the 'view label' operation and I'm getting invalid links.

Steps to reproduce

This can be reproduced by displaying a link to the user. The user always returns AccessResultAllowed for the 'view label' operation, but the direct view link (the 'view' operation) requires additional permissions.

Proposed resolution

I suggest adding an additional access check to the generated URL and if it is not available, output the label as plain text.

Remaining tasks

See #9.
Code review

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In #3413949: Move some Action plugins to Action module 3 plugins were moved to the Action UI module.

Some sites will be have been using these plugins through modules such as Views bulk operations or ECA without the need for the Action UI module. Enabling the deprecated Action UI module is undesirable in these cases.

As noted in https://www.drupal.org/project/drupal/issues/3427549#comment-15487959 configurable action plugins are still useful in modules such as Views Bulk Operations and ECA where the action system is used.

Steps to reproduce

n/a

Proposed resolution

Move UnpublishByKeywordComment(comment_unpublish_by_keyword_action), UnpublishByKeywordNode(node_unpublish_by_keyword_action) and AssignOwnerNode(node_assign_owner_action) back to their original modules.

Remaining tasks

• Decide if core should keep these plugins
• Move them back

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

It would be great to have new events getting dispatched while importing data to have better controls and modularity.
For example, if an exception occurs, the MigrateEvents::POST_IMPORT is never called, which can lead to confusion when we want to have pre and post processes to our migration in any cases.

I suggest to add a new event MigrateEvents::IMPORT_FAILED which would be called before any return MigrationInterface::RESULT_FAILED;.

In the same way, we could add a new event MigrateEvents::ROW_SKIPPED which would be called in the catch (MigrateSkipRowException $e) block.

This will allow you to add post treatments when an error occurs in your migrations, like a custom logging or archiving system, to help the user to debug and fix his migration.

Some ideas for improvements, in the way to gain control over migration:
- Add an option to immediately stop the import when a row is skipped (if the user want to import ALL rows without exception, he probably doesn't want to lose time to import the rest of the data if a row has been skipped).
- Add an option to use database transaction while importing to automatically rollback the transaction in case of failure (the migrate rollback method may not be the best if you want to run several time the same migration with different data each time).

Steps to reproduce

Proposed resolution

I suggest to add a new event MigrateEvents::IMPORT_FAILED which would be called before any return MigrationInterface::RESULT_FAILED;.

In the same way, we could add a new event MigrateEvents::ROW_SKIPPED which would be called in the catch (MigrateSkipRowException $e) block.

Remaining tasks

Review
Commit
Smile

User interface changes

N/A

API changes

Data model changes

Release notes snippet

Problem/Motivation

1. A views handler (e.g.) a filter can be configured to use a particular plugin
2. The Views Handler Manager does not respect this and takes whatever plugin is defined by views data (hook_views_data + hook_views_data_alter)
3. See ViewsHandlerManager::getHandler($item) - the $item contains the correct plugin_id, yet that is ignored and the views data plugin ID is used instead

This is a problem for #3347343: Continuation Add Views EntityReference filter to be available for all entity reference fields in particular as it means existing configuration is not respected, forcing us to duplicate the views filter rather than allow replacement to avoid a breaking change.

Steps to reproduce

1. Create a filter, e.g. a numeric filter on a View
2. Use hook_views_data_alter to change the default filter to something else (e.g. entity_reference)
3. Check the configured view; the numeric configuration is not respected and the filter plugin loaded is entity_reference instead of the configured numeric filter

Proposed resolution

Ensure that ViewsHandlerManager respects existing configuration

Remaining tasks

Update ViewsHandlerManager to respect existing configuration
Add automated test case to verify this

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Views configuration is no longer overridden by views data (hook_views_data + hook_views_data_alter)