Problem/Motivation

#2311393: Remove hook_element_info() and all references to it replaced hook_element_info with plugins, but there's a todo left in the code

// @todo Once all elements are converted to plugins in
      //   https://www.drupal.org/node/2311393, rely on
      //   $element['#value_callback'] directly.

Proposed resolution

Remove dynamic value callback of form form_type_TYPE_value

Remaining tasks

Review

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

I recently set up update status notifications on a D6 site, and realised I was getting the notifications on Tuesdays. Since SAs go out on Wednesdays this means it could be a full week between the SA and the notification.

Currently you can specify the interval for checks/notifications, but not the day of the week (unless you manually change the tracking variable to a timestamp on the day you want).

Seems like it would make more sense to allow choosing the day(s) of the week to get notifications on, as well as forcing a refresh of the data just before sending the notification.

Steps to reproduce

1. Install a clean site.
2. Enable update notification emails during installation, configure it for "weekly".
3. Notice when emails go out.

Proposed resolution

1. On the Update Manager settings form (/admin/reports/updates/settings), when selecting "Weekly" for the "Check for updates" setting, expose another setting to select which day of the week.
2. The day should default to Thursday.
3. Update Manager should always refresh data before sending any notification emails.

Remaining tasks

1. Confirm that Update Manager is sending emails without refetching data and decide if fixing that should be in scope with the rest of this or split off to a separate issue.
2. Confirm the right UI text for the new setting.
3. ✅ Implement the feature.
4. ✅ Update summary with After screenshot.
5. Reviews + refinements.

User interface changes

Before

After

API changes

None.

Data model changes

TBD. New setting in update.settings.yml, probably under the check section.

Release notes snippet

TBD.

Problem/Motivation

file_validate_extensions was deprecated in favor of constraint validators in #3221793: Move file upload validation from file.module to constraint validators

Until Drupal 11, file_validate_extensions should continue to work as it always did. However, FileUploadHandler::handleExtensionValidation does not have a BC layer, and if $validators['FileExtension'] is not found, then DEFAULT_EXTENSIONS is used instead of the extensions configured by file_validate_extensions

protected function handleExtensionValidation(array &$validators): string {
    // Build a list of allowed extensions.
    if (isset($validators['FileExtension'])) {
      if (!isset($validators['FileExtension']['extensions'])) {
        // If 'FileExtension' is set and the list is empty then the caller wants
        // to allow any extension. In this case we have to remove the validator
        // or else it will reject all extensions.
        unset($validators['FileExtension']);
      }
    }
    else {
      // No validator was provided, so add one using the default list.
      // Build a default non-munged safe list for
      // \Drupal\system\EventSubscriber\SecurityFileUploadEventSubscriber::sanitizeName().
      $validators['FileExtension'] = ['extensions' => self::DEFAULT_EXTENSIONS];
    }
    return $validators['FileExtension']['extensions'] ?? '';
  }

A fix for this should go in the 10x branch, but isn't needed in 11 since file_validate_extensions support is removed.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

We are planning to rewrite UI Patterns upon SDC. To achieve this, we are proposing a few changes and additions:

• #3390980: Make SDC extensible
• #3352063: [PP-1] Allow schema references in Single Directory Component prop schemas
• #3390712: Add component variants to SDC
• Allow declaration of template path. The current issue.
• #3391702: SDC ComponentElement: Transform slots scalar values to #plain_text instead of throwing an exception
• #3391978: SDC: Add a method to retrieve only components not replaced by others

There is already a template property in component definition, but SDC ComponentPluginManager is always overriding its value :

$template = $this->findAsset(
  $component_directory,
  $definition['machineName'],
   'twig'
);
$definition['template'] = basename($template);

We support the statement of "Single Directory Component" where everything related to the component must fit in the same directory. This is the target, this is the good practice to promote.

However, they are real world examples where components in a Drupal theme are using templates from distinct codebase. The upstream codebase has only Twig templates, shared by various PHP app with Twig, and the Drupal theme is adding the Drupal related stuff, including component definitions.

Proposed resolution

We need to keep this property value if already set in YAML and allows the use of twig namespaces.

name:  Card
template: "@upstream_repo/path/to/template.twig"
props: {}
slots: {}

It may be as simple as adding a condition in ComponentPluginManager.

Related work

If #3390712: Add component variants to SDC is implemented, we can add this property also for variants:

name:  Card
variants:
  primary:
    label: Primary
    template: "@upstream_repo/path/to/template.twig"
props: {}
slots: {}

Remaining tasks

If there is a chance for this feature to be accepted, we (UI Patterns team) can propose a merge request soon.

We have one month before the release of Drupal 10.2.0-alpha1.

API changes

Yes, but not breaking.

Problem/Motivation

When using the Content language detection > Content language plugin, the content admin page does not include the language_content_entity param which is quite confusing for the CMS users as they see the entity label translated but when they click on it, they are redirected to the original language node.

Steps to reproduce

1. Enable Language and Content Translation modules
2. Install Spanish language
3. Access /admin/config/regional/language/detection
1. Keep only "Selected language" in the "Interface text language"
2. Check "Customize Content language detection to differ from Interface text language detection settings"
3. Enable the "Content language"
4. Uncheck the rest
4. Access /admin/structure/types/manage/article
1. Enable translation
5. Create 2 articles, one for each language
6. Access admin/content

Result: Notice that the entity label is translated however links don't include the language_content_entity query param and all link to node/{id}.

Proposed resolution

TBD

Problem/Motivation

On some of my sites, I have twice experienced faulty links to generated CSS and JS.

For some reason, the links to the generated files were malformed, i.e.:

<link rel="stylesheet" href=":443/sites/default/files/css/css_6u7oFEr4OkoMAF9qdJQzJlzRk552XMusS-n-KvqQkO0.css?pa9m7y" media="all" />

A cache rebuild made the problem disappear, and I haven't been able to track down a real root cause for this.

But the problem made me take a closer look at FileUrlGenerator::transformRelative() and noticed it errors on some unusual, edge case input.

I created a patch fixing these edge case errors and extends the test cases with nine new test data set covering these edge cases.

Steps to reproduce

Here are the edge cases I have identified:

• https://example.com:443/page on a https://example.com/something request is transformed into :443/page. Although it is unusual to supply the port number for the default port, it is not an invalid URL. This could be my original problem, although I have no clue why it would end up in this case.
• http://example.com:1337/page on a http://example.com/something request is transformed into /page. So, referencing a URL on a different port when being on a default port transform into a relative URL. Although very unusual, it is at least a theoretical possibility that someone deliberately would reference something on a different port.
• http://example.com on a http://example.com/something request is transformed into an empty string. Although this is probably not the intended use case of the function, it would make the function more robust to handle that case as well.

Proposed resolution

The patch solves the edge cases by hardening the existing regular expression.

Remaining tasks

Code review

User interface changes

NA

API changes

NA

Data model changes

NA

Release notes snippet

NA

Problem/Motivation

The off-canvas settings tray moves away from the right edge of the page when grabbing the resize handle and resizing the tray's width. This then causes the main content to resize in unpredictable ways as well.

It's possible this has something to do with Drupal.displace() calculating the offsets incorrectly.

Steps to reproduce

Create a fresh site, enable layout builder, and set a content type to use layout builder. Edit a node via layout builder and add a section. When the settings tray appears, grab the left side handle and drag it in and out a couple of times. You will see the tray jump around and offset from the right side. This occurs in both firefox and chrome.

Problem/Motivation

I started dipping my toes into autowiring yesterday and one of the first things I butted up against was how to autowire loggers.

If a module needs to log something, most of the time it will do something like this:

services:
  logger.channel.my_module:
    parent: logger.channel_base
    arguments: ['my_module']

  my_module.service:
    class: Drupal\my_module\Foo
    arguments: ['@logger.channel.my_module']

I discovered in my own discussions internally that we can use calls in the service to avoid having to pass the logger into the constructor by using LoggerAwareTrait

  my_module.service:
    class: Drupal\my_module\Foo
    calls:
      - [setLogger, ['@logger.channel.my_module']]

That works well, but what if we automated it?

We could detect services implementing LoggerAwareInterface and autoconfigure a logger for the module and automate the calls part of the service.

Proposed resolution

Autoconfigure a logger logger.channel.module_name for a module that has at least one service implementing LoggerAwareInterface
Don't do this if a logger service already exists with the name logger.channel.module_name
Automatically add setLogger calls

Note that I'm very new to all of this, this was a suggestion from @dpi that I really liked and am keen to get into the weeds and learn about this system.

https://symfony.com/doc/current/logging.html#using-a-logger-inside-a-ser...

Remaining tasks

Agree
Code
Test

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The 7.x Date module allowed the field to have an optional or required end date. D8 always requires the end date.

Proposed resolution

Make end_value in DateRangeItem optional, add validation constraint via configuration.

Key questions

5 key questions have recurred again and again over the life of this issue:

1. Is the start date optional too? NO
2. What value is stored in the end date property if it is left empty in the widget? NULL
3. Does the optional_end_date setting live in the field config or field storage config? STORAGE
4. How are optional and non-optional properties distinguished in the widget? STAR ON REQUIRED PROPERTIES BUT ONLY ON FIELD IF ALL REQUIRED
5. How are missing end dates displayed in the formatter? ONLY START DATE IS SHOWN

Remaining tasks

1. If the start date is missing, stop deleting the end date on saving the form. (See #84.)
2. If missing, indicate that the end date is unknown/unspecified on display. (See #84.)

User interface changes

Field storage settings form:

Only start date is displayed when end date is missing:

History of discussion

#35 "I think we will have to `->setRequired(FALSE)` in the field definition, and then set required on the element in the widgets, based on the settings. Still need a update hook at the end, though."

# 39 UX discussion

#45 first patch from mpdonadio

#48 "Should the optional_end_date setting be moved to the field config instead of the field storage config?"

#63 should we allow start date optional

#64 'datetime_iso8601' datatype has never been set to optional in core

#76 no impact on json_api

#84 discussion around how we should display missing end date

#94 further discussion around what values to store & display if unknown end date

#139 first patch that added optional start date

#144 proposal about how to handle required indicators for optional field parts

#171 removed optional start date from patch

API changes

Data model changes

Problem/Motivation

To wire services to a plugin, developers must implement ContainerFactoryPluginInterface and a custom create() method that pulls services from the container and calls the plugin constructor. This is largely boilerplate code and must be written for each plugin implementation.

Using PHP 8 attributes, we can tag constructor parameters directly and allow the factory class to discover and inject the required services, and drop the create() method entirely.

This also has the advantage of placing the service name directly next to the parameter where it is used, instead of having to keep the create() method and constructor signature in sync in two different places.

Steps to reproduce

Proposed resolution

Add support to ContainerFactory for Symfony's #[Autowire] attribute.

Remaining tasks

Determine if there are any more edge cases to cover.

User interface changes

API changes

Plugins can now wire services by specifying an #[Autowire] attribute on the each constructor parameter, instead of writing a separate create() method.

Data model changes

Release notes snippet

Problem/Motivation

Single directory components (SDC) is a new way to theme Drupal. Instead of scattering related files around your theme, they're contained to one directory. The primary issue for SDC is at #3313520: Single directory components in core.

This issue is postponed on #3352256: [META] Move code from the experimental SDC module to core, since we cannot make Olivero depend on an experimental module. In any case, this issue can (and should) be worked in parallel.

Branding component

As part of SDC's roadmap (see #3345922: Single Directory Components module roadmap: the path to beta and stable), we want to convert Olivero components to use SDC. For this task I'm choosing the Branding component, which includes markup, CSS, and JS.

This component is a good fit because: component is simple and it's a good start to include more components to Olivero theme.

This component involves the following Twig templates, CSS, JS, assets, and libraries:

1. List involved files and systems here

Testing instructions

1. Add testing instructions here.
2. Point out any automated tests that cover this component's refactor.

Problem/Motivation

Recent security releases have shown that the render system needs to be stricter about what it allow to be called by a callback. See:

• https://www.drupal.org/sa-core-2018-002
• https://www.drupal.org/sa-core-2018-004
• #2860607: Code execution via Twig templates (including inline)

Form list of callbacks to target:

• ✓ #process
• ✓ #after_build
• ✓ #value_callback
• #element_validate
• #validate
• #submit
• #date_date_callbacks
• #entity_builders
• #file_value_callbacks

Proposed resolution

Postponed on the render system solution - #2966327: Limit what can be called by a callback in render arrays to reduce the risk of RCE - once we have an agreed solution there we should largely copy it.

1. In 10.2.x deprecate the ability to call any function using call_user_func*() and limit to object implementing FormCallback interface, FormElementInterface or a closure. For objects also limit to specific methods to further narrow the surface area.
2. Try and provide a PHPCS fix that can auto-update code?
3. In 11.0.x remove the ability.

Remaining tasks

1. Refactor all the prior refactoring done against 9.2 against 10.1.x using the new attribute.
2. Find any additional callbacks added since 9.2 and refactor those.

User interface changes

None

API changes

Yes

Data model changes

None.

Problem/Motivation

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.

Steps to reproduce

TBA

Proposed resolution

TBA

Remaining tasks

Add test

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Since the notification the CKeditor is deprecated I changed over to CKeditor 5.
If I want to change my full HTML features, Ido not see any Icon, only text referring to the icons.....

{"undo":{"label":"Undo"},"redo":{"label":"Redo"},"heading":{"label":"Heading"},"style":{"label":"Style"},"specialCharacters":{"label":"Special characters"},"sourceEditing":{"label":"Source"},"bold":{"label":"Bold"},"italic":{"label":"Italic"},"underline":{"label":"Underline"},"code":{"label":"Code"},"codeBlock":{"label":"Code Block"},"strikethrough":{"label":"Strikethrough"},"subscript":{"label":"Subscript"},"superscript":{"label":"Superscript"},"blockQuote":{"label":"Block quote"},"link":{"label":"Link"},"bulletedList":{"label":"Bulleted list"},"numberedList":{"label":"Numbered list"},"horizontalLine":{"label":"Horizontal line"},"alignment":{"label":"Text alignment"},"removeFormat":{"label":"Remove Format"},"insertTable":{"label":"table"},"drupalInsertImage":{"label":"Image"},"indent":{"label":"Indent"},"outdent":{"label":"Outdent"},"textPartLanguage":{"label":"Language"},"drupalMedia":{"label":"Drupal media"}}

If I turn on the old (deprecated) CK editor, then the icons reappear.... see file

Steps to reproduce

No icons shown:
uninstall ck editor
install ck editor 5

Icons shown:

Install ck editor 5
change editor settings to ck editor
When I uninstall ck editor, icons are gone

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Certain links do not contain unique link names for JAWS to announce. As an example within the “Content” screen, there are multiple “Edit” links present in a table. When the links are accessed JAWS announces “Edit link” without providing a unique link name to distinguish each link, instead of announcing as e.g. “Test Detail Page edit link”, “Test Image title edit link” etc.

This defect exists in IE 11 and Google Chrome version 55.0.2883.87 m.

Expected result: All links are expected to contain unique link names in order to distinguish between each link. In this instance JAWS is expected to announce e.g., “Test Detail Page edit link”, “Test Image title edit link” etc.

Reference: Section 508, Part 1194.21, user interface elements (d).

Notes:
• This defect also exists elsewhere within the application.
• This defect exists on a screen that is not accessible via a keyboard. The tester was forced to use the mouse to access this screen, which is not acceptable for a JAWS user.

Steps to reproduce:
1. Open JAWS
2. Open Drupal
3. Use the Tab key to navigate to the “Manage” button and press Spacebar/Enter to select.
4. Use the mouse to select “Content” button.
5. Use the Tab key to navigate to the “Edit” links throughout the screen.

Problem/Motivation

The \Drupal\views\Plugin\views\display\Block::preBlockBuild() method is responsible for manipulating the view before it is rendered by the corresponding block plugin. The block plugin itself actually calls this method, however blocks cannot show exposed filters without using ajax, and the ajax rebuild for views will not call the preBlockBuild() method.

As a practical example, blocks can override the number of results per page for a view, however if they leverage ajax rebuild, on the first rebuild (which is also used for pagers) the view will be rendered without the block's overrides. If the default view shows 50 per page, and the override shows 5, the first ajax call will result in the view now showing 50 instead of 5.

Proposed resolution

Add new function to view Block.php display plugin (getBlockFromAjaxRequest) that runs when ajax is used in a view block.
Adding new function (preparePreview) to DisplayPluginInterface

Previous solution
The views/ajax controller needs to consult the block when rebuilding block displays. Doing this generically is likely to be a bit convoluted.

Remaining tasks

Identify a solution.
Implement it.
Change record (maybe)
Review
Commit

User interface changes

NA - working ajax for view blocks now.

API changes

NA

Data model changes

NA

Problem/Motivation

Since #3110517: Improve Drupal\Core\Ajax\AddCssCommand to accept an array of CSS assets , JS/CSS assets are sent in AJAX responses as arrays of attributes instead of rendered HTML strings. Because of this, inline CSS can no longer be added to AJAX responses through AddCssCommand's (see nod_'s comment here).

Drupal.AjaxCommands.prototype.add_css(), the JS behaviour that adds the assets to the page, expects an href attribute for every asset, something inline assets don't have.

Steps to reproduce

1. Enable and configure the Critical CSS module.
2. Try to trigger any AJAX request: can be a Webform submit, a media library modal, anything.

Proposed resolution

AjaxResponseAttachmentsProcessor will need to check which CSS assets have an href attribute: those that do should be added with AddCssCommand, those that don't should be added with AppendCommand (see gapple's comment here).

Problem/Motivation

\Drupal\media\MediaSourceFieldConstraintsInterface::getSourceFieldConstraints says the return type should be

* @return \Symfony\Component\Validator\Constraint[]
   *   An array of validation constraint definitions, keyed by constraint name.
   *   Each constraint definition can be used for instantiating
   *   \Symfony\Component\Validator\Constraint objects.

But actually, its an array where the keys are validation plugin IDs and the values are options for the plugin.

Steps to reproduce

Proposed resolution

Update the documentation

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

After drupal core upgrade 9.5.1. I am getting Uncaught ReferenceError: loadjs is not defined in site. This is breaking other js in the site. This js defined in core.libraries.yml file.

Steps to reproduce

See #30

TL;DR:
If any script uses

"use strict";
(function(window, document, Drupal, $) {
  // Your code here
})(window, document, Drupal, jQuery);

instead of

(function(window, document, Drupal, $) {
  "use strict";
  // Your code here
})(window, document, Drupal, jQuery);

and JS aggregation is enabled, this happens!

Proposed resolution

Ensure loadjs is available in global scope, make core more robust for the described case.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Problem/Motivation

The update module has to individually fetch project XML for each project installed on a site. This can reach 300+ http requests which is a lot.

However, guzzle supports async support and promises, so it might be possible to rewrite this using Fibers and guzzle promises. As long as we don't hit memory issues, we might be able to then skip the batch support and do it directly.

Steps to reproduce

Proposed resolution

There are two components to getting update data for an extension:

1. Fetch the project XML
2. Parse the project XML.

Ideally we'd do something like this:

1. Have the list of projects to fetch update data for.
2. Issue up to x number of async requests for the project xml.
3. As soon as one request comes back, issue another x async http requests, process the html for any that have come back, rinse and repeat until no more requests or XML to process.

Need some sort of absolute cap on outgoing http requests too.

Had a look at doing this 'quickly' but found the http retry logic which makes it a bit more complicated to implement, so just opening the issue for now.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet