Problem/Motivation

We are using PHP_CodeSniffer for PHP coding standards, ESLint for JavaScript and Stylelint for CSS, but we have nothing for Twig templates.

Steps to reproduce

Proposed resolution

Adopt https://github.com/VincentLanglet/Twig-CS-Fixer for ensuring Twig templates match coding standards.

Dependency evaluation

Maintainership: Primary author is Vincent Langlet, also very active in other projects around Symfony (Symfony itself, Sonata, Doctrine). The author is responsive to issues and pull requests. Only 3 issues are open (2024-07-12), all of them were opened within the last three months.

Security policy: See https://github.com/VincentLanglet/Twig-CS-Fixer/security/policy The latest major version is maintained and receives security updates, which should be fine for a dev dependency.

Release cycle: Frequent releases, 19 so far this year. Version 2.0.0 (current major version) has been released at the end of 2023. The maintainer confirmed that he tries to adhere to semver.

Other dependencies: None that aren't already required by Drupal itself or other dependencies.

Remaining tasks

• Add TwigCS to composer.json and commit-code-check.sh
• Configure it to pass without any violations for now
• Raise child issues to fix individual violations

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Submit button can fill the entire width of the the off canvas dialog box, which can be too wide in situations such as dialogs that appear in the top of the screen

Steps to reproduce

1. Go to your Drupal site.
2. Go to any page with an off canvas dialog with a submit button. ( For example in the module Layout Builder.)
3. Observe the size of the button

Proposed resolution

Off-canvas Submit button width is based on it's content, not the current 100%.

Remaining tasks

User interface changes

The off-canvas submit button width is based on content, not 100% of its container

API changes

Data model changes

Release notes snippet

Problem/Motivation

These three tests are extending kernel test jobs by about 30 seconds.

https://git.drupalcode.org/project/drupal/-/jobs/2936385
https://git.drupalcode.org/project/drupal/-/jobs/2936386

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

PHPStan baseline is currently skipping multiple Call to an undefined method errors in the migration system

Proposed resolution

Fix the errors in the following

• core/modules/migrate/tests/src/Kernel/MigrateTestBase.php
• core/modules/migrate_drupal/tests/src/Kernel/d6/MigrateDrupal6AuditIdsTest.php
• core/modules/migrate_drupal/tests/src/Kernel/d7/MigrateDrupal7AuditIdsTest.php
• core/modules/migrate_drupal/tests/src/Traits/CreateTestContentEntitiesTrait.php
• core/modules/migrate_drupal_ui/tests/src/Functional/MigrateUpgradeTestBase.php
• core/modules/migrate_drupal_ui/tests/src/Functional/d7/FilePathTest.php

Problem/Motivation

With the adoption of gitlab there a few challenges and oppertunities to have subsystem maintainers help out core committers with certian tasks.

Things like retargeting or closing merge requests. This is only possible for accounts with permissions on the drupal project.

This requires is being maintainer or developer. The issue with that is that this would give commit permissions. But we can fix that with branch permissions

https://docs.gitlab.com/ee/user/project/protected_branches.html

By protecting the release branches we can give more permissions to subsystem maintainers but also protect branches from commits by us.

Slack discussion: https://drupal.slack.com/archives/CGKLP028K/p1701285278934459

Steps to reproduce

Proposed resolution

1. Protected Branches and Tags will only allow GitLab Maintainers (and above) to push or GitLab Developers granted explicit permission to push.
2. Core Committers will be GitLab Mainatiners
3. Subsystem maintainers will be GitLab Developers.
4. Provisional committers will be GitLab Developers with an explicit access permission to push (or if the Core team wants a more lax security policy they can skip this and just make them regular maintainers)

Setup up as documented in #26

Remaining tasks

1. Move the documentation from this pdf to d.o. Where?
2. Collect subsystem maintainer usernames
3. Setup permissions as documented in #26
4. Test with single user to validate the policy above has been correctly installed on the core repo
5. Add all subsystem maintainers

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In #3280279: Allow sites to programmatically opt in to accept more image type uploads in CKEditor 5: TIFF, SVG… we added hook_ckeditor5_image_controller_extensions_alter() to allow other modules to modify the list of allowed extensions for CKEditor5's image upload plugin.

WebP is officially adopted as an image type by Drupal core, so we need to add CKEditor5 support for it. See #3280279-26: Allow sites to programmatically opt in to accept more image type uploads in CKEditor 5: TIFF, SVG… for more information.

Proposed resolution

Update \Drupal\ckeditor5\Controller\CKEditor5ImageController::upload() to add webp as a valid file name extension.

Update core/modules/ckeditor5/ckeditor5.ckeditor5.yml -> ckeditor5_imageUpload -> ckeditor5 -> config -> image -> upload -> types to add webp as a valid IANA file type.

Remaining tasks

1. Commit #3280279: Allow sites to programmatically opt in to accept more image type uploads in CKEditor 5: TIFF, SVG…
2. Write a patch
3. Review and feedback
4. RTBC and feedback
5. Commit

User interface changes

It is now possible to upload WebP images to CKEditor5 by dragging-and-dropping or using the image upload button.

API changes

None.

Data model changes

None.

Release notes snippet

Added CKEditor5 support for WebP images.

The configuration of custom validation involves the use of the ExecutionContext::addViolation() function.

This function takes a message as its first parameter. If the message parameter is left empty it results in an exception. that states that the message parameter cannot be null. Instead the null message value should be allowed and automatically replaced by a default generic message.

Bellow is the error while we creating the custom validation without a message.
Drupal\Core\Validation\ExecutionContext::addViolation(): Argument #1 ($message) must be of type string, null given,

Steps to reproduce

Configure a custom validation using the ExecutionContext::addViolation() function. Leave out the message parameter.

allow for null

Problem/Motivation

As detected by #2484693: Telephone Link field formatter InvalidArgumentException with 5 digits or fewer in the number, PHP does not guarantee the parse_url function results for URIs.
The problem is that PHP's parse_url is 'designed' for url's not for URIs.
Because by documentation parse_url:

This function is intended specifically for the purpose of parsing URLs and not URIs.

That can lead to many issues as this function is widely used in the Core as shown in the following table:

The ones which work:

Not OK:

Proposed resolution

We have Drupal\Component\Utility\UrlHelper (URL). We should create a similar UrIHelper (URI) class which is a true RFC 3986 parser.

Note: An external parser can't be used with our current Drupal requirements (PHP 5.6+ or php-intl requirements, both which Drupal doesn't have now)

Wrap parse_url in a drupal_parse_uri function so we can manage all specific cases and unit test it.

Remaining tasks

Discuss, Fix PHP, Fix Drupal, Enjoy

User interface changes

None.

API changes

An added URIHelper class.

Data model changes

None.

Problem/Motivation

I create some SDC components, when using theme, the js and CSS file not load correctly.
I got error in chrome console. this is the url generated by SDC:

/yiysites/core/modules/sdc/../modules%5Ccontrib%5Cblocktabs_jquery_ui%5Ccomponents%5Ctabs-default%5Ctabs-default.js?rwh76n

it should be:

/yiysites/modules/contrib/blocktabs_jquery_ui/components/tabs-default/tabs-default.js?rwh76n

Steps to reproduce

1, using a win10 OS.
2, install xampp, XAMPP is the most popular PHP development environment, https://www.apachefriends.org/index.html
3, create a site in sub directory of htdocs
4, install SDC module
5, create a component in custom module.

Proposed resolution

Windows using a different file path compare linux, it use "\\" instead of "/". we need add some logic code for windows condition.
here is some dirty code that I fixed it quickly in makePathRelativeToLibraryRoot of \Drupal\sdc\ComponentPluginManager :

	  $path_from_root=str_replace('\\','/',$path_from_root); 
    //return $dots . $path_from_root;
	$path_from_root= "/" .  $path_from_root;
	return $path_from_root;

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

My theme uses Bootstrap and I noticed I cannot change the library load order to appear before any module CSS libraries, no matter the group I specified (base, component, theme, etc.) - even if specified manually (`group: -200`). I tracked this down to core/lib/Drupal/Core/Asset/LibraryDiscoveryParser.php:165:

$options['group'] = $extension_type == 'theme' ? CSS_AGGREGATE_THEME : CSS_AGGREGATE_DEFAULT;

This essentially forces any theme CSS libraries into the CSS_AGGREGATE_THEME group (100) and overwrites/ignores any specified SMACCS group settings, e.g. 'base' (my_theme.libraries.yml):

bootstrap:
  css:
    base:
      libraries/bootstrap/bootstrap.min.css: {}

And also overwrites setting group specified like this:

bootstrap:
  css:
    base:
      libraries/bootstrap/bootstrap.min.css: { group: -200 }

So this doesn't function according to 'group' property described in the docs: Adding Stylesheets CSS and Javascript JS to a Drupal Theme which specifies the "rarely used" group setting causes assets to be aggregated per group - because it's overwritten in the case of themes and modules.

Even if my module (e.g. Faculty Cards) libraries file specifies 'css: theme' grouping, it still appears in the HTML loaded before the theme bootstrap library (which specifies 'base'):

faculty-cards:
  css:
    theme:
      css/faculty-cards.css: {}
   

The line in LibraryDiscoveryParser means that module CSS libraries are always loaded before theme CSS libraries regardless of SMACCS category (base, layout, component, theme, etc.) specified in respective files. Which means that greater CSS specificity or even worse !important needs to be used in module CSS files to override a theme that uses Bootstrap.

If I comment out the affected line in LibraryDiscoveryParser, ordering is as I would expect and group settings are respected.

Problem/Motivation

Many platforms and development environments use Basic Auth configured on the server to provide a Site Lock. This allows making sites available to select people via the public web without exposing the site to the public in general. For example, https://pantheon.io/docs/lock-environment/. This could be a "production" site before it goes live, or on a dev/staging site.

This server-level auth can conflict with Basic Auth in Drupal if it is set up for access to an API endpoint.

Per http://drupal.stackexchange.com/a/212800/394 and an examination of the Basic Auth provider code, what's happening is that if you use Basic Auth headers, PHP will pick them up and the Basic Auth module in core will be "triggered' to attempt authentication with those credentials. If it fails, the response will be redirected to access denied. After all, a login attempt just failed.

The frustration level this issue can cause makes it a major DX issue when the stars align, and while I marked it as a bug, you could argue it's a support request.

Proposed resolution

This issue is complicated because it could be considered a feature, not a bug. However, there is a common expectation that a "site lock" can be configured without regard for the application configuration.

One solution could be a simple configuration option that allows checking to see if the user account does not exist, and if not treat it as an anonymous request.

Another possibility would be supporting the Drupal site issuing Basic Auth challenges, allowing the site itself to provide the "lock UI".

Remaining tasks

Decide if this is a problem that should be solved. If not solved, this becomes a documentation problem to explain what's going on and recommended workarounds.

User interface changes

?

API changes

?

Data model changes

?

Problem/Motivation

Our security team has flagged a vulnerability where the password is shown in clear text in the "payload" of the login request in the network tab during user authentication on Drupal. Although Drupal stores passwords securely in a hashed format in the database, the password is exposed during transmission, which could be intercepted by a malicious party, leading to potential security breaches.

Steps to reproduce

1. Open the login page of our Drupal site.
2. Open the browser's Developer Tools and navigate to the Network tab.
3. Enter a valid username and password, then submit the login form.
4. Observe the login request payload in the network tab. The password is visible in plain text.

Proposed resolution

Implement client-side encryption of the password before it is transmitted to the server. This can be achieved using JavaScript-based encryption, such as AES, to ensure that the password is encrypted at the client side. Upon receiving the encrypted data, the server can decrypt it and proceed with normal authentication procedures.
Alternatively, enabling HTTPS with secure transmission is a minimum requirement, but this does not prevent the clear-text password from being visible in the browser's developer tools.

Problem/Motivation

I would like to add classes to link fields. It seems like an easy addition to the Default Link Formatter.

Proposed resolution

Add a new configuration option to the formatter.

Remaining tasks

• write tests

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

We are in the process of removing at least four themes from Drupal core in Drupal 10:

1. #3308998: Remove Stable from core
2. #3110137: Remove Classy from core
3. #3304285: Remove Seven from core
4. #3304256: Remove Bartik from Drupal core

As a result of this, we have some icons in the core/misc/icons directory that are not being used anywhere.

Proposed resolution

Audit uses of all icons in the core/misc/icons and delete all icons that are no longer being used anywhere.

Remaining tasks

User interface changes

Release notes snippet

Problem/Motivation

Testing with https://accessibilityinsights.io and their Ad hoc tools, the Landmarks widget identified that the ARIA landmarks are missing around some of the content on the main page.

"Contain all visible content within the landmark areas.
Turn on the Landmarks visualization, then zoom out so you can see the entire page. If you see any visible content (like text, images, or controls) outside the dashed borders, that’s a failure."

The Main content isn't in a region.

The Recipes title isn't either. Although the main region is visible for the list of recopies:

Missing Footer. This probably should have a <footer> tag rather than just a series of div's too.

Steps to reproduce

Open any Umami page, notice that some regions are not placed inside landmark regions.

Proposed resolution

Make sure all Drupal regions are inside landmarks - header, footer, main.

Remaining tasks

Move code in page.html.twig around a little to make sure header and footer items are inside the header/footer landmarks and that all other content is inside a 'main' landmark

Update the CSS to reflect this new mark up.

User interface changes

None

Introduced terminology

None

API changes

None

Problem/Motivation

Messages can be added with js using Drupal.Message, see: https://www.drupal.org/node/2930536

but the markup output does not match Umami's in
https://git.drupalcode.org/project/drupal/blob/8.8.x/core/profiles/demo_...

Claro overrides the theme function: Drupal.theme.message
https://git.drupalcode.org/project/drupal/blob/8.8.x/core/themes/claro/j...

If Umami had a similar override then js messages would look more like the twig messages.

Steps to reproduce

Proposed resolution

Add a Drupal.theme.message function for Umami to override core/misc/message.js and output markup that matches the twig template.

1. 3100083-add-js-message is actual fix branch.
2. 3100083-web-components - an experimental branch with web components. Both message methods (Drupal render and javascript theme function) use the same template.

Remaining tasks

Review

User interface changes

Before

After

API changes

NA

Data model changes

NA

Release notes snippet

Problem/Motivation

CKEditor 5 has released a security update: https://github.com/ckeditor/ckeditor5/releases/tag/v43.1.1

The CKEditor team has determined that Drupal core is not affected by this vulnerability but we should upgrade anyway to avoid security scanners complaining.

Steps to reproduce

Proposed resolution

Update CKEditor5 to v43.1.1 in all supported branches down to 10.2.x, if possible.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

CKEditor 5 is updated to 43.1.1. This is a security release.

The CKEditor team has determined that Drupal core is not affected by this vulnerability but we upgraded anyway to avoid security scanners complaining.

Problem/Motivation

CKeditor 5 fields have a different border color:

Steps to reproduce

- Go to /node/add/page or /node/add/article
- Compare CKEditor 5 text field with the others

User interface changes

Before

After (example with different fields, but with the same type)

Problem/Motivation

Using datetime views filter and filtering with an invalid date, there is no validation and fatal error occured.

To reproduce:

• Add a datetime field to the 'Basic page' node type (the bundle).
• Create a view to list the entities and add a filter on the datetime field
• Create a Page display with its own path to the view
• View the page display
• In the exposed filter enter a search string in an invalid format e.g. try: lun 2018-04-27. The following error should occur:
  

  <em class="placeholder">Exception</em>: DateTime object not set. in <em class="placeholder">Drupal\Component\Datetime\DateTimePlus-&gt;__call()</em> (line <em class="placeholder">355</em> of <em class="placeholder">core/lib/Drupal/Component/Datetime/DateTimePlus.php</em>). <pre class="backtrace">Drupal\datetime\Plugin\views\filter\Date-&gt;opSimple(&#039;sesame_quota_option__field_sesame_opt_date.field_sesame_opt_date_value&#039;) (Line: 314)
  Drupal\views\Plugin\views\filter\NumericFilter-&gt;query() (Line: 1370)
  Drupal\views\ViewExecutable-&gt;_build(&#039;filter&#039;) (Line: 1259)
  Drupal\views\ViewExecutable-&gt;build() (Line: 390)
  Drupal\views\Plugin\views\display\PathPluginBase-&gt;execute() (Line: 180)
  Drupal\views\Plugin\views\display\Page-&gt;execute() (Line: 1627)
  Drupal\views\ViewExecutable-&gt;executeDisplay(&#039;page_1&#039;, Array) (Line: 77)
  Drupal\views\Element\View::preRenderViewElement(Array)
  call_user_func(Array, Array) (Line: 378)
  Drupal\Core\Render\Renderer-&gt;doRender(Array, ) (Line: 195)
  Drupal\Core\Render\Renderer-&gt;render(Array, ) (Line: 226)
  Drupal\Core\Render\MainContent\HtmlRenderer-&gt;Drupal\Core\Render\MainContent\{closure}() (Line: 582)
  Drupal\Core\Render\Renderer-&gt;executeInRenderContext(Object, Object) (Line: 227)
  Drupal\Core\Render\MainContent\HtmlRenderer-&gt;prepare(Array, Object, Object) (Line: 117)
  Drupal\Core\Render\MainContent\HtmlRenderer-&gt;renderResponse(Array, Object, Object) (Line: 90)
  Drupal\Core\EventSubscriber\MainContentViewSubscriber-&gt;onViewRenderArray(Object, &#039;kernel.view&#039;, Object) (Line: 76)
  Drupal\webprofiler\EventDispatcher\TraceableEventDispatcher-&gt;dispatch(&#039;kernel.view&#039;, Object) (Line: 156)
  Symfony\Component\HttpKernel\HttpKernel-&gt;handleRaw(Object, 1) (Line: 68)
  Symfony\Component\HttpKernel\HttpKernel-&gt;handle(Object, 1, 1) (Line: 57)
  Drupal\Core\StackMiddleware\Session-&gt;handle(Object, 1, 1) (Line: 47)
  Drupal\Core\StackMiddleware\KernelPreHandle-&gt;handle(Object, 1, 1) (Line: 99)
  Drupal\page_cache\StackMiddleware\PageCache-&gt;pass(Object, 1, 1) (Line: 78)
  Drupal\page_cache\StackMiddleware\PageCache-&gt;handle(Object, 1, 1) (Line: 47)
  Drupal\Core\StackMiddleware\ReverseProxyMiddleware-&gt;handle(Object, 1, 1) (Line: 38)
  Drupal\webprofiler\StackMiddleware\WebprofilerMiddleware-&gt;handle(Object, 1, 1) (Line: 50)
  Drupal\Core\StackMiddleware\NegotiationMiddleware-&gt;handle(Object, 1, 1) (Line: 23)
  Stack\StackedHttpKernel-&gt;handle(Object, 1, 1) (Line: 664)
  Drupal\Core\DrupalKernel-&gt;handle(Object) (Line: 19)

• Search for the same date with day in english works: mon 2018-04-27. Same for date only: 2018-04-27

Proposed resolution

Mimic the date filter validation from views module.

Remaining tasks

1. Add tests
2. Review

Problem/Motivation

At present, require() which imports Node.js built-in module like "fs" is written require('fs').
Current Node.js supports "node:" import which identifies Node built-in module clearly.
The Node.js native test runner must needs "node:" prefix when it import. New Node.js built-in modules may require "node:" when it import in near the future.

FYI: eslint-plugin-unicorn can enforce "node:" prefix to require() which imports Node.js built-in module. (Ref)

Proposed resolution

Add "node:" prefix to all of require() which import Node.js builtin module such as util, fs, path and so on.

Merge request link

Remaining tasks

User interface changes

No.

API changes

No.

Data model changes

No.

Release notes snippet