\Drupal\Tests\block\Kernel\Migrate\d7\MigrateBlockContentTranslationTest is skipped since #3375592: [random test failure] Random failure in MigrateBlockContentTranslationTest
https://git.drupalcode.org/issue/drupal-3389365/-/jobs/4840855
Currently the content moderation and workflow modules allow site builder to apply a workflow to block types. But there is no moderated view to view those blocks in the workflow
Similar to #2902187: Provide a way for users to moderate content, we need to allow users to moderate block_content entities after #2820848: Make BlockContent entities publishable.
This is currently postponed on:
#2862041: Provide useful Views filters for Content Moderation State fields
#2902187: Provide a way for users to moderate content
#2820848: Make BlockContent entities publishable
Here's how the UI looks:
#3379725: Make Block config entities fully validatable made Block config entities fully validatable, and the settings for 2 block plugins:
block.settings.block_content:*:) (see block_content.schema.ymlblock.settings.search_form_block (see search.schema.yml)N/A
Also make
block.settings.system_menu_block:*:
type: block_settings
label: 'Menu block'
mapping:
level:
type: integer
label: 'Starting level'
depth:
type: integer
label: 'Maximum number of levels'
expand_all_items:
type: boolean
label: 'Expand all items'fully validatable.
level: must be between 0 and $this->menuTree->maxDepth()→ Range constraint?depth: really relative depth, aka levels to display IF available. Currently 0 means "no limit". Must be between 1 and min($level + $depth - 1, $this->menuTree->maxDepth()).
Wouldn't it be better to make depth optional, aka nullable: true? Then we don't need to assign a special meaning to 0
expand_all_items: either we accept that this is basically nonsense for a single-level menu, or we accept that it's really a "best effort" thing. I vote the latter, that seems pragmatic and simple.None.
None.
None.
TBD
TBD
We need some guidelines for svg & svg icons for Drupal core.
The issue have come up during the work on the RSS icon #2427213: Replace feed.png with feed.svg
To sum it up we need Guidelines:
Write a guideline... here is a start:
When converting from existing raster images to vector images, it is better to maintain the existing image size (dimensions) and colors from the originals, to minimize scope creep on the issue queues. There are many examples of endless design-by-committee tickets on the issue queues that languish for years, ultimately to be abandoned because a redesign opens up too many unanswerable questions.
Since these little icon files are assets that will be loaded (downloaded) millions of times across millions of websites, one of the most important tenants is to require the smallest file size possible for the SVGs in core. So just as "profiling" the server-side implications of changing each phptemplate into twig, so important is it also to ensure SVG files are optimized and even potentially minified. This means manual (or automatic) removal of all "crap" produced by vector design applications like Illustrator, Sketch, and Inkscape. Removal of these elements should not inhibit editability in these applications as the resulting SVG still conforms to the spec.
There are not so many graphics in Drupal core, so it is not problematic to have high standards here. Once created, the SVG file could be unmodified for years.
There are a number of ways to optimize SVGs including via the svgo command and/or optimized manually -- each of which might produces better results in different cases. The best method usually depends on the complexity of the SVG. For example, the points required for a rounded rectangle as a <path>end up being more code than using a <rect> with the rx and ry attributes to give the rounded corners. The strategy can be that a designer can create the SVG and someone else can optimize it with svgo or by hand.
All core assets should pass through the validator http://validator.w3.org successfully. Although, we can ignore the "DOCTYPE missing" error, it seems not necessary and to be removed in SVG 1.2 according to MDN documentation article (about namespaces)
<style> tag). Note: this is a manual procedure, there are not many tools to automate this process. Try Illustrator CSS Properties: SVG Elements in the SVG save settingsaria-hidden="true" and focusable="false" attributes should be added to the root SVG element.height, width, and viewBox attributes are always present. SVGO sometimes strips out one or more of these attributes.There is no single right answer to inline versus external SVG.
Inline SVG (i.e. SVG images embedded directly inside twig templates) is preferred over external SVG asset files added via <img> tag, or referenced in CSS backgrounds, in cases where SVG needs to be manipulated (e.g. animated or color changed) via CSS or JavaScript, whereas external SVGs referenced in CSS backgrounds cannot.
When SVG does not need manipulation, keeping them as external assets has the benefit of SVG files being cached by the browser.
We need to weigh the pros/cons and analyze the SVG Sprite option also (less HTTP requests, and cacheable).
Consider also that HTTP 2.0 is minimizing the benefit of "saving HTTP requests".
Although SVG is widely supported, there are some exceptions, like IE8. There is barely any consensus on the "best way" to support fallbacks. If using inline SVGs (as is the best practice), then by and large the best fallback method has to be the SVG <switch> structure, because it is the only foolproof fallback method that has no dependencies on javascript. The switch tag requires the first element be a group tag <g> followed by a single <foreignObject> tag containing the fallback <img> inside.
Other fallback methods available: Use .no-svg and .svg classes in css to provide background image fallbacks. Because this fallback method requires modernizr javascript be loaded on the page, this is an inferior solution that should only be considered as a last resort.
SVG Accessibility is only really applicable to inline SVGs. Inline SVGs can be be given text alternatives by adding a <title id="title"> tag inside the SVG and referencing this using an aria-labelledby="title" attribute on the <svg> tag itself, i.e.:
<svg aria-labelledby="title">
<title id="title">Alternative text goes here</title>
<!-- Remaining SVG code follows. -->
</svg>
ARIA support is introduced officially into the SVG 2.0 specification, but it is still possible to use ARIA with SVG 1.1 content. Some examples in this article will raise a flag when you validate your HTML, but it’s a reasonable exception to make.
-- Léonie Watson Tips for Creating Accessible SVG (Sitepoint article)
If the image content is purely graphical, add the role="img" attribute to the <svg> tag. If the SVG is interactive, make use of <text> tags for readable text and make the interactive elements focusable by wrapping them in <a xlink:href="http://example.com"> tags.
<title>and <desc> for accessible labels, these will need to be localizable.The current recommendation is that text in SVGs (particularly visible text) should be avoided. As stated on a blog post from Una Kravets:
Running the website through the web interface Google Translate Tool could possibly translate the SVG text if the character glyphs exist in the specified font, but may also break the SVG due to viewbox constraints. So even though the diagram text is highlightable, don't rely on SVG images to be the tools you need for text translation.
Nightwatch test is flakey. For some reason nightwatch is not able to press the confirm button to install the toolbar module.
│ ✖ NightwatchAssertError │
│ Timed out while waiting for element <#system-modules-confirm-form, #system-modules-non-stable-confirm-form> to be present for 10000 milliseconds. - expected "found" but got: "not found" (10446ms) │
│ │
│ Error location: │
│ /builds/project/drupal/core/tests/Drupal/Nightwatch/Commands/drupalInstallModule.js:30 │
│ ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– │
│ 28 | if (force) { │
│ 29 | // Click `Continue` if applicable. │
│ 30 | this.waitForElementPresent( │
│ 31 | '#system-modules-confirm-form, #system-modules-non-stable-confirm-form', │
│ 32 | 10000, │
│ –––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
https://git.drupalcode.org/project/drupal/-/jobs/5054046/viewer
https://git.drupalcode.org/project/drupal/-/jobs/5011069/viewer
Not sure, but ideally we can install modules in tests without clicking buttons in the UI
Now Drupal provides Locking mechanisms with two Lock API methods to acquire the lock
That's looks enough, but actually - not, because of this nuance in the function wait():
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...
/**
* Waits a short amount of time before a second lock acquire attempt.
* ...
* @return bool
* TRUE if the lock holds, FALSE if it may be available. You still need to
* acquire the lock manually and it may fail again.
*/
public function wait($name, $delay = 30);
The problem is here:
You still need to acquire the lock manually and it may fail again.
Let me elaborate on this.
If we have several parallel requests that waiting for the lock to be released, they produce multiple parallel SQL requests to check. Let's imagine two requests, for example.
When the lock is released, both two requests receives FALSE from the function wait(), and then - immediately tries to acquire the lock. And, in this case, one of two requests will obligatorily fail with acquiring the lock.
So, all developers, who need to acquire the lock in a reliable way, need to implement an infinite loop with "wait() + lock()" to workaround this, that is not good. Also, this loop produces a lot of load to the database.
One of the workarounds like this you can see here: https://git.drupalcode.org/project/test_helpers/-/commit/6d4f4e0028cd7e0...
As a solution, I propose to implement a new method "waitAndAcquire()" that will wait and acquire the lock at once.
And this can be implemented in a much better way than with the "wait() + lock()" loop, because we can produce "acquire lock" SQL queries (insert queries that fail if not released) instead of "check the lock" (just select queries) that can guarantee to acquire the lock directly during the query, not using a second query that can fail.
What do you think about this idea? And maybe someone has better ideas to resolve this issue?
Follow-up of #3485069: [CI] Spin off Drupal Components tests in a job of their own, add test coverage metrics.
Components tests coverage metrics differ slightly by PHP version, and apparently the last PHP version job completing the components unit test is winning the box. Not a big deal, but this can cause some confusion when looking at test results and seeing that metrics are changing even if components code/tests are not part of the MR.
Example from HEAD on Apr 28, 2025:
PHP 8.3 and 8.4
Classes: 31.62% (37/117)
Methods: 46.88% (315/672)
Lines: 36.59% (2782/7604)
PHP 8.5
Classes: 30.77% (36/117)
Methods: 46.43% (312/672)
Lines: 36.53% (2778/7604)Possible solutions:
Currently two users can register with same email address: one use as username and another one use as email. When the user with the username that is an email address (that does not match their email address) navigates to user/password to reset password, they cannot receive the reset email because the user password reset form allows entering either a username or email, an the notification goes to the account that has that as the email.
Also, @catch asked for this in #111317-83: Allow users to login using either their username OR their e-mail address
Steps to reproduce:
user/password to reset password, enter a@example.com.When new users register, check the username and email fields against already registered users to make sure the username is not already registered as an email and vice versa.
To deal with already registered users who have conflicts, users who have matching emails and usernames are allowed to select which user to email the password reset link to when resetting their password.
Password reset form UI change: If it detects a conflict with username/email, it allows the user to pick which account they meant. Screenshot:
After shot 2 in #117 shows some errors.
N/A
Seems like it should be part of validation due to how email is used. Edge case, but could happen with forgetful users.
1) Make a user with username 'example@example.com' and email != that
2) Make a user with mail 'example@example.com'
3) Go to user/pass to reset password, enter 'example@example.com'.
4) Password email will be sent to example@example.com; the first user will not be able to get a password email with username.
There should be an option to disable the password strength check in the settings for user registration. Right now it can only be disabled by a custom module with a hack messing with the javascript function that checks the password.
Timestamp fields have a range constraint so that no value outside of the range of the database storage can be saved. The changed and created field types extend the timestamp field type but are missing that constraint. That means that invalid created or changed values that enter the system via a migration or JSON:API, for example, are not properly validated and may cause exceptions when being saved.
$node = Node::create([
'title' => 'Back to the future',
'type' => 'article',
// This is not a 32-bit integer.
'created' => 2147483649
]);
// This yields 0, thus no violation is recorded.
$node->validate()->count();
// Brace for SQL exception.
$node->save();
Copy the constraints over from TimestampItem to CreatedItem and ChangedItem.
-
-
-
-
-
hook_preprocess and hook_preprocess_HOOK functions are still required to be in a .module/.inc file.
N/A
Gather the preprocess hooks in the HookCollectorPass.
Then store theme suggestions in a container parameter.
Cache the prefix and the hook separately in an invoke map like this: ['module' => $prefix, 'hook' => 'preprocess_'. $hook] Then because named arguments work together with the splat operator (they were designed together for PHP 5.6 but named arguments needed to wait until 8.0 -- we are well past that version), we can just pass such an array to invoke directly.
Add a new attribute extending Hook to make it easier to write preprocess hooks.
Finally we modify Registry to use invokeAllWith for gathering hook_preprocess_HOOK to avoid checking missing preprocess functions.
Add PREFIX and SUFFIX constants to the hook attribute to facilitate extension.
Rename hooks_converted to skip_procedural_hook_scan and StopProceduralHookScan to ProceduralHookScanStop This is required to ensure that preprocess hooks are picked up in all modules that adopted these parameters and attributes.
All this requires surprisingly little code to provide both full backwards compatibility and OOP capability. What this does not provide is the ability to implement preprocess hooks in OOP code multiple times by the same module. This is not even planned as it would require a significant overhaul of the theme registry system. Do not let perfect be the enemy of good enough.
template_preprocess_HOOK functions are not included, they are handled in #3501136: Explicitly register template_preprocess callbacks in hook_theme()
Finalize review
Follow ups:
Explore how the data structure should evolve as we explore allowing themes to implement hooks as OOP. #3518985: Explore data structures for long term OOP hooks in themes
Look at replacing contextual_preprocess as some sort of fixed preprocess, it is in every preprocess definition so there may be a way to optimize the registry around that. #3518986: contextual_preprocess is in every preprocess definition, explore optimizing the map
N/A
Added #[Preprocess] hook attribute extending #[Hook]. It is recommended these attributes to be committed to every supported branch for the same reason Hook and LegacyHook was. Aspiring contrib authors can use the LegacyHook attribute and pattern with preprocess hooks much like with any other hook to maintain a single branch which is compatible with Drupal before and after this patch.
Rename hooks_converted to skip_procedural_hook_scan and StopProceduralHookScan to ProceduralHookScanStop This is required to ensure that preprocess hooks are picked up in all modules that adopted these parameters and attributes.
N/A
tableresponsive.js is used on the extensions page and elsewhere where tables are loaded. If a page has multiple tables (eg the extensions page with multiple module categories), the eventhandlerEvaluateColumnVisibility event handler will be invoked (number of tables) factorial times (for a page with 50 tables, 50 x 49 x 48... times).
Open /admin/modules. Open the developer console of your web browser and find and set a breakpoint in the eventhandlerEvaluateColumnVisibility function. Reload the page and observe that the function is called repeatedly. If you also set a breakpoint at the TableResponsive.tables.push call in the behaviour function, you'll see that the event handler is called once after the first push, twice after the second and so on.
Add a flag to the top of the evaluate function, allowing the event handler to exit immediately before the last table is added. Set the flag during the attach call when we aren't on the last table being attached.
I have a working patch and have confirmed on my local that the page load time for my site that has 50 module categories goes from 30s plus to completing almost immediately. I have compared the page before and after applying the patch and have not found any differences.
None
None
None
None
Not required
PHP 8.4 has been out for nearly half a year now, so I think we could switch the default test environment to use it.
https://packagist.org/php-statistics
Switch default pipeline to PHP 8.4 and MySQL to 8.4 LTS as 8.0 is outdated https://dev.mysql.com/doc/refman/8.4/en/mysql-releases.html
agree and commit
Update DeprecatedServicePropertyTrait to deprecate for Drupal 12 and allow custom messages.
As above
None
N/a
TBD
N/a
N/a
I have a project with a lot of configurations (3 037, mostly because of multiple languages). The site installation from existing configuration (drush site:install --existing-config) takes about 10 minutes. I did profile the installation and this is the TOP 10 slow calls:
As you can see, Drupal\Core\Config\FileStorage->getAllCollectionNamesHelper() is the slowest operation during installation.
Also, take a look at php::SplFileInfo->isDir(). It called 13'937'541 times, and almost all the calls (13'919'940) comes from Drupal\Core\Config\FileStorage->getAllCollectionNamesHelper(), but php::SplFileInfo->isDir() is slow by itself:
This is clearly because Drupal\Core\Config\FileStorage->getAllCollectionNamesHelper() doesn't cache its result in any way. It's always calculated in runtime. It seems to me like a bottleneck.
Install the website from existing configs and profile it. The more configs you have, the more problems you will see.
Provide at least a static caching for the results of this method.
The content translation module adds permissions to user roles via the \Drupal\content_translation\ContentTranslationPermissions class. Whether the permission exists depends on the content translation status which is defined by a config file but this is not added correctly to the dependencies. And even if it was the permissions is not removed because when translation is disabled a status value is set in the language.content_settings.* config entity - if the entity was deleted it would work once the dependency is added.
Once #3358586: RuntimeException: Adding non-existent permissions to a role is not allowed lands the next step will be to go to the log page and see the error.
None
None
None
I am trying to implement a datetime-local element but I can't get it to work
All my tests led me to the catch (\Exception $e) in Datetime::valueCallback()
with the error "The date cannot be created from a format."
Build a custom form with the following method in it:
/**
* {@inheritdoc}
*/
public function buildForm(array $form, FormStateInterface $form_state) {
$form['datetimepicker'] = [
'#type' => 'datetime',
'#date_date_element' => 'datetime-local',
'#date_time_element' => 'none',
];
$form['submit'] = [
'#type' => 'submit',
'#value' => 'Submit',
];
return $form;
}
Then access your form page, fill the input and submit the form.
Datetime::valueCallback() to provide a valid format (ie. $date_format = 'Y-m-d'; and $time_format = 'H:i:s';) to \DateTime::createFromFormat() when '#date_date_element' is 'datetime-local'Datetime::processDatetime() to fill $element['#value'] from a 'Y-m-d\TH:i:s' submitted value after the form has been processed.'#date_date_element' is 'datetime' since it's also using an invalid format. If not open a dedicated new issue to fix it11.x has 60k files in node_modules compared to 40k in 11.0.x, this appears to be increasing the time that the cspell job takes to upload the cache to gitlab - e.g. https://git.drupalcode.org/issue/drupal-3497431/-/jobs/5103456 takes four minutes.
We only use the cspell cache in nightwatch tests, so by the time we've uploaded the cache from cspell, then downloaded it again in nightwatch, we could just run yarn in the nightwatch tests and it would take less CI minutes overall.
PHPUnit 11 was released on February 2, 2024, supporting PHP 8.2 and above. Drupal 11 is still using PHPUnit 10.
drupal-phpunit-upgrade script to to upgrade to PHPUnit 11 if the PHP version is 8.4+.--fail-on-phpunit-deprecation CLI toggle introduced in PHPUnit 11.3PHPUnit 11 can now be used for testing. While the shipped version remains PHPUnit 10, it's possible to update to PHPUnit via composer update phpunit/phpunit --with-dependencies. Drupal core testing on PHP 8.4 requires PHPUnit 11 as a minimum.
In #3238652: [policy] Decide how long major Drupal versions should be supported we are moving to doing a new major release every 2 years. And having supporting every major version for at least 4 year. Therefor supporting 2 major versions at all times.
As a developer working Drupal core, I would like to work with newest database versions. Just the newest Drupal major version has the newest Symfony version. It is no fun when we cannot work with the newest functionality that the database supports. Now we have to wait for #3315265: Improve support of native MERGE on postgresql 15 and JSON support is waiting on SQLite 3.38 (released in Februari 2022).
A new policy doc in https://www.drupal.org/about/core/policies for this and the results of #3363102: [Policy] How to select the minimum required database versions, with a title about requirements.
Databases
The Database requirements are set about 6 months before a major release. They are set so that the latest Drupal version is as forward-compatible as possible.
Consideration is given to adopting features that are common to all supported databases in core. And to changes that allow core to remove workarounds for different implementations of a feature.
Statement
MySQL
Prefer the MySQL LTS available before the first major beta window..
See MySQL release information.
MariaDB
TBA
See MariaDB release information.
PostgreSQL
Prefer the most recent PostgreSQL major version that is available prior to the first beta window for a Drupal major version.
See PostgreSQL release information.
SQLite
Select an SQLite minor version based on feature set and availability.
=== original proposal ===
We have 2 options:
1. Keep doing the way we have been doing it. Looking at the main Linux distributions and see what database version they support. Then use that to select a sensible minimum version to require for each database supported by core.
2. We are setting the minimum required version for each database 6 months before the new major Drupal is expected to be released. We can as an alternative that what at that moment is the newest release of each database as the minimum required version. Most Drupal sites use containers and can run with any database version that is required. If for some reason you cannot use containers and do not have access to the newest database, then use the previous major Drupal version that has still support. There are always 2 Drupal major version that get support.
After an accessibility audit by an authority on Accessibility (www.Anysurfer.be) it has become clear that role="navigation" should be removed from language switcher blocks.
The comment was: "r is geen reden om in de accessibility tree van het taalkeuzeblok een navigatieblok te maken."
"> There is no reason to create a navigation block in the accessibility tree of the language switcher block".
Have a multilingual Drupal with a language switcher.
Review patch.
Patch removes the role="navigation" addition from the language blocks.
Review
For accessibility reasons removed role="navigation" from language blocks.