Drupal Core

#2381091: Improve example.gitignore

Tue, 14 Apr 2026 08:04:02 +0000

Project: Drupal Core
Type: Normal task
Version: 11.x-dev
Status: Fixed
Diff: 59a2ce1
Discussion: #2381091 · 20 contributors · 75 comments
Followers: 24

Summary

The example.gitignore template that Drupal ships for new sites now has more precise and complete rules for ignoring sensitive configuration files. The patterns for settings and services files are updated to cover files nested one subdirectory deeper inside each site directory, and explicit allow rules are added so that Drupal's own shipped template files (default.settings.php and default.services.yml) are never accidentally excluded. The alternative commented-out section for setups where .gitignore lives inside the sites/ folder is also updated to cover services files and carry the matching allow rules, which it previously lacked entirely.

Impact

No upgrade or configuration changes required.

Technical details

Two identical files are changed: example.gitignore in the project root and core/assets/scaffold/files/example.gitignore (the copy Composer scaffolding copies into a project). Both previously used the patterns sites/*/settings*.php and sites/*/services*.yml, which only matched files sitting directly inside a named site directory. That missed environment-specific or subdirectory-nested variants such as sites/example.com/subdir/settings.local.php.

The fix replaces those patterns with sites/*/*settings*.php and sites/*/*services*.yml, adding one extra wildcard directory segment to cover one additional level of nesting inside each site directory. Because those broader globs would also match Drupal's own tracked template files (sites/*/default.settings.php and sites/*/default.services.yml), the commit immediately adds negation rules !sites/*/default.settings.php and !sites/*/default.services.yml after each group. Git negation rules re-include files that a preceding pattern would otherwise suppress, so the shipped templates remain visible to git status for core contributors.

The commented-out "sites/ folder" section — intended for sites where .gitignore is placed inside sites/ rather than the project root — previously contained only # */settings*.php and had no coverage for services files at all. The fix expands it to four lines: # */*settings*.php, # !*/default.settings.php, # */*services*.yml, and # !*/default.services.yml, making it consistent with the primary section. During review, ** (recursive double-star) was considered for the services pattern but rejected after it was pointed out that **/*services*.yml would also silently suppress module-provided services.yml files in a multisite layout. The final pattern uses */* (two explicit single-star segments) to limit the match depth. This issue was a follow-up to #2326913, which first introduced services.yml patterns into the example gitignore.

Contribution

Timeline

Opened: November 24, 2014
Committed: April 14, 2026 (11 years later)

Key contributors

mikeker
dawehner
alexpott
jeanfei
lluvigne (La Drupalera by Emergya)
gnuget (Agaric)
xjm (Zoocha)
ankit_rathore (OpenSense Labs)
wim leers (Acquia)
gengo_k
quietone (PreviousNext)

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3536964: run-tests.sh - segregate command line parsing and use Symfony Console classes

Mon, 13 Apr 2026 21:32:48 +0000

Project: Drupal Core
Type: Normal feature request
Version: main
Status: Fixed
Diff: afcf201
Discussion: #3536964 · 6 contributors · 53 comments
Followers: 9

Summary

The run-tests.sh test runner script now uses Symfony Console's argument-parsing infrastructure instead of a hand-rolled parsing function. A new Configuration class centralizes all command-line option handling, improving readability and moving the script closer to becoming a proper Symfony Console application command. For CI operators the most visible changes are: a substantially improved --help output (automatically generated from the option definitions), the --sqlite ':memory:' option now working (the old restriction is gone since #3515347 eliminated sub-process spawning), and the --php option being deprecated and silently ignored. PHP binary detection now uses PhpExecutableFinder from symfony/process.

Impact

Affects module maintainers.

Deprecation: --php option in run-tests.sh is now deprecated and silently ignored; PHP binary detection is handled automatically via PhpExecutableFinder.

Technical details

All changes are in core/scripts/run-tests.sh and the new core/tests/Drupal/TestTools/TestRunner/Configuration.php.

Previously, run-tests.sh contained simpletest_script_parse_args(), a hand-written function that iterated $_SERVER['argv'], maintained a flat $args array of defaults, and shared it as a global throughout the script. Every function accessed global $args and then individual keys.

The new Configuration final singleton class lives in the Drupal\TestTools\TestRunner namespace. All options and their defaults are declared once in Configuration::commandLineDefinition() using Symfony Console's InputDefinition, InputOption, and InputArgument objects. The static factory Configuration::createFromCommandLine() wraps the raw argv in ArgvInput, validates --concurrency, splits the comma-separated tests and types values into arrays, and stores the result in the singleton. Access throughout the script is via Config::get('option-name'), Config::set('option-name', $value), and Config::getTests(). Functions that previously accepted array $args as a parameter (dump_tests_sequence(), dump_bin_tests_sequence()) now call Config::get() directly and drop the parameter.

simpletest_script_init() is simplified: autoloader setup is moved to the top of the script (the ClassLoader instance is passed in as a parameter), and the entire block that guessed the PHP binary from the $_ and SUDO_COMMAND environment variables is removed. The startup banner now calls (new PhpExecutableFinder())->find() inline. The --php option remains accepted so existing scripts do not break, but its value is never read and it is documented as deprecated.

simpletest_script_setup_test_run_results_storage() loses its $new boolean parameter; the caller always creates storage now.

simpletest_script_help() drops the full hand-written option listing and instead calls DescriptorHelper::describe() against the InputDefinition, automatically producing consistent formatted help. Its signature changes to accept InputDefinition $input_definition, string $script_basename, and ConsoleOutput $console_output instead of reading globals.

A companion change in .gitlab-ci.yml sets CI_NODE_INDEX: 1 and CI_NODE_TOTAL: 1 explicitly for the Build job, since those values are now required by the --ci-parallel-node-total and --ci-parallel-node-index option defaults.

Help text is also updated: the :memory: restriction on --sqlite is removed (resolved by #3515347), and references to @group annotations are replaced with #[Group()] attributes (see #3556580). The issue was explicitly blocked on #3515347 landing first, because that change removed the internal --test-id and --execute-test options and simplified the arguments this MR had to cover.

Upgrade

If your CI scripts pass --php to run-tests.sh, that argument is now a no-op and can safely be removed:

# Before
php ./core/scripts/run-tests.sh --php "$(which php)" --url http://example.com/ --all

# After
php ./core/scripts/run-tests.sh --url http://example.com/ --all

If your CI job uses --ci-parallel-node-total or --ci-parallel-node-index without supplying the corresponding CI_NODE_INDEX / CI_NODE_TOTAL environment variables, set them explicitly (or pass the values directly on the command line) to avoid an argument-without-value error.

Contribution

Timeline

Opened: July 19, 2025
Committed: April 13, 2026 (8 months later)

Key contributors

mondrake
jonathan1055
longwave (Full Fat Things)
amateescu

Collaboration

The issue was blocked for several months waiting on #3515347. Once that landed, jonathan1055 unblocked it and tested the MR in a real contrib CI pipeline using the Scheduler project's test suite, sharing pipeline links and comparing logs with the non-patched version. This surfaced a concrete bug: the startup banner was printing /usr/bin/sudo as the PHP binary path instead of the actual PHP executable. mondrake traced the root cause to the old environment-variable-sniffing logic and replaced it with PhpExecutableFinder::find() from symfony/process. jonathan1055 then retested and confirmed the fix. He also manually tested --list, --list-files, --help, and --class, which prompted clarifications in the help text around fully-qualified class names and escaped backslashes on the command line.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3562645: Fix return types and baselined errors of core/tests/ Build|FunctionalJavascript|Functional code - round 4

Mon, 13 Apr 2026 19:25:14 +0000

Project: Drupal Core
Type: Normal task
Version: main
Status: Fixed
Diff: 62b09c0
Discussion: #3562645 · 5 contributors · 17 comments
Followers: 7

Summary

This is a purely internal code-quality change that adds missing PHP return type declarations to test helper classes and traits in Drupal core's Build, Functional, and FunctionalJavascript test suites. It has no effect on production sites or end users.

Impact

No upgrade or configuration changes required.

Technical details

Part of a multi-round effort to bring core/tests/ up to full static-analysis coverage (see also #3551596 round 1, #3562361 round 2, #3562868 round 3, and #3579189 round 5 for Kernel tests). Round 4 targeted the Build, Functional, and FunctionalJavascript test namespaces, manually adding return types that Rector could not add automatically.

The commit (62b09c02) touches 26 files across three areas:

Build tests (core/tests/Drupal/BuildTests/Framework/BuildTestBase.php): Added void to standUpServer(), stopServer(); ?string parameter type and void return to the overloaded working_dir parameters in instantiateServer() and copyCodebase(); string return to getWorkingPath(), getWorkspaceDirectory(), getDrupalRoot(), getDrupalRootStatic(); and Finder return to getCodebaseFinder(). The subclass TemplateProjectTestBase in package_manager tests received the same typed override for instantiateServer().

FunctionalJavascript tests: WebDriverTestBase gained Session return on initMink() (requiring a new use Behat\Mink\Session import), void on installModulesFromClassProperty(), initFrontPage(), assertJsCondition(), and createScreenshot(). JSWebAssert had ?NodeElement return added to waitForButton(), waitForLink(), waitForField(), waitForId(), and waitOnAutocomplete(). PerformanceTestBase received void on prepareEnvironment() and installModulesFromClassProperty(). AjaxFormPageCacheTest::getFormBuildId() gained a string return type.

Functional tests: InstallerTestBase received void on all installer lifecycle methods (visitInstaller(), setUpLanguage(), setUpProfile(), setUpSettings(), setUpRequirementsProblem(), setUpSite(), refreshVariables(), initFrontPage()). Subclasses InstallerExistingConfigSyncDirectoryMultilingualTest and InstallerSiteConfigProfileTest had their setUpProfile() / setUpSite() overrides fixed to drop the now-incorrect return parent::... statement since the parent now returns void. UpdatePathTestBase had void added to all of its methods including the abstract setDatabaseDumpFiles(): void. Several REST resource test bases (BaseFieldOverrideResourceTestBase, DateFormatResourceTestBase, etc.) had void added to setUpAuthorization().

Shared trait: CronRunTrait::cronRun() in core/tests/Drupal/Tests/Traits/Core/CronRunTrait.php gained a void return type, eliminating many missingType.return baseline entries across the modules that use this trait (block, field, help, locale, search, system, update).

Variable initialisation: ComposerProjectTemplatesTest had an undefined variable $project_stabilities fixed by adding $project_stabilities = [] before its first use, resolving a variable.undefined PHPStan error.

Baseline cleanup: All resolved errors were removed from core/.phpstan-baseline.php (316 lines removed, 62 lines added), shrinking the suppression list by roughly 48 entries of type missingType.return and one variable.undefined. Some entries remain because they originate in runtime traits that cannot be fixed in this issue.

Contribution

Timeline

Opened: December 11, 2025
Committed: April 13, 2026 (4 months later)

Key contributors

mondrake
dcam

Collaboration

Reviewer dcam verified all new type hints, found nothing to flag, and cleared the issue for RTBC after asking only for a rebase of the baseline file due to merge conflicts. mondrake subsequently adjusted the baseline and self-RTBCed per dcam's explicit permission.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3571400: Deprecate functions in menu_ui.module and move to hooks or helper class

Mon, 13 Apr 2026 16:04:08 +0000

Project: Drupal Core
Type: Normal task
Version: 11.x-dev
Status: Fixed
Diff: 41ea677
Discussion: #3571400 · 6 contributors · 39 comments
Followers: 6

Summary

Six procedural functions in menu_ui.module that handled node menu link saving and form building have been deprecated in Drupal 11.4.0. Their logic has been moved to two proper OOP homes: a new MenuUiUtility service class, and new methods on the existing MenuUiHooks class. Site owners and module developers who call these functions directly will see deprecation notices and should update to the new equivalents before Drupal 12.0.0 or 13.0.0.

Impact

Affects module maintainers.

Deprecation: Six procedural functions in menu_ui.module deprecated 11.4.0: _menu_ui_node_save() and form handlers moved to MenuUiHooks; menu_ui_get_menu_link_defaults() moved to MenuUiUtility::getMenuLinkDefaults().
New API: New MenuUiUtility service class with public getMenuLinkDefaults(NodeInterface $node) method and @internal menuUiNodeSave() method.

Technical details

The six procedural functions that lived in core/modules/menu_ui/menu_ui.module were split across two destinations based on their nature.

New MenuUiUtility service (core/modules/menu_ui/src/MenuUiUtility.php): _menu_ui_node_save() and menu_ui_get_menu_link_defaults() were moved here as menuUiNodeSave() and getMenuLinkDefaults() respectively. These functions carried substantive logic used outside the hook system (e.g., in MenuSettingsConstraintValidator and form submit handlers), making a standalone service appropriate. The service is autowired and registered in menu_ui.services.yml as Drupal\menu_ui\MenuUiUtility: ~. menuUiNodeSave() is annotated @internal; getMenuLinkDefaults() is part of the public API. In MenuUiUtility, static \Drupal::entityQuery() and MenuLinkContent::create() calls were converted to injected EntityTypeManagerInterface, EntityRepositoryInterface, and EntityFieldManagerInterface dependencies.

MenuUiHooks class (core/modules/menu_ui/src/Hook/MenuUiHooks.php): The four form-handler procedurals (menu_ui_node_builder, menu_ui_form_node_form_submit, menu_ui_form_node_type_form_validate, menu_ui_form_node_type_form_builder) were moved in as nodeBuilder(), formNodeFormSubmit(), formNodeTypeFormValidate(), and formNodeTypeFormBuilder(). The class gained EntityRepositoryInterface DI, and MenuUiUtility is injected via #[AutowireServiceClosure(MenuUiUtility::class)] to avoid loading the utility eagerly. Form references to old procedural callbacks ($form['#submit'][], $form['#entity_builders'][]) were updated from string function names to static::class . ':methodName' format.

MenuSettingsConstraintValidator was updated to implement ContainerInjectionInterface and use AutowireTrait, receiving MenuUiUtility via constructor injection and replacing a direct menu_ui_get_menu_link_defaults() call.

Deprecation versions:

_menu_ui_node_save() and menu_ui_form_node_form_submit(), menu_ui_form_node_type_form_validate(), menu_ui_form_node_type_form_builder(): deprecated 11.4.0, removed 12.0.0.
menu_ui_get_menu_link_defaults() and menu_ui_node_builder(): deprecated 11.4.0, removed 13.0.0.

All deprecated functions now emit E_USER_DEPRECATED via @trigger_error() and delegate to the new service methods. Change records are consolidated at https://www.drupal.org/node/3566774.

Upgrade

Replace direct calls to the deprecated procedural functions with service calls or class method calls:

// BEFORE
_menu_ui_node_save($node, $values);

// AFTER
\Drupal::service(\Drupal\menu_ui\MenuUiUtility::class)->menuUiNodeSave($node, $values);

// BEFORE
$defaults = menu_ui_get_menu_link_defaults($node);

// AFTER
$defaults = \Drupal::service(\Drupal\menu_ui\MenuUiUtility::class)->getMenuLinkDefaults($node);

// BEFORE (form #submit / #entity_builders references)
$form['actions'][$action]['#submit'][] = 'menu_ui_form_node_form_submit';
$form['#entity_builders'][] = 'menu_ui_node_builder';
$form['#validate'][] = 'menu_ui_form_node_type_form_validate';
$form['#entity_builders'][] = 'menu_ui_form_node_type_form_builder';

// AFTER — these are now handled internally by MenuUiHooks; if you are calling
// them directly, use the service:
\Drupal::service(\Drupal\menu_ui\Hook\MenuUiHooks::class)->formNodeFormSubmit($form, $form_state);
\Drupal::service(\Drupal\menu_ui\Hook\MenuUiHooks::class)->nodeBuilder($entity_type, $entity, $form, $form_state);
\Drupal::service(\Drupal\menu_ui\Hook\MenuUiHooks::class)->formNodeTypeFormValidate($form, $form_state);
\Drupal::service(\Drupal\menu_ui\Hook\MenuUiHooks::class)->formNodeTypeFormBuilder($entity_type, $type, $form, $form_state);

Note: MenuUiUtility::menuUiNodeSave() is @internal and not intended for direct external use.

Contribution

Timeline

Opened: February 4, 2026
Committed: April 13, 2026 (2 months and 2 commits later)

Key contributors

smustgrave (Mobomo)
dcam
nicxvan (nLightened Development LLC)
berdir (MD Systems GmbH)
claudiu.cristea (Webikon)
godotislate

Collaboration

A debate in the thread shaped the final design. After smustgrave initially moved _menu_ui_node_save and menu_ui_get_menu_link_defaults to a utility class, nicxvan and berdir discussed whether the helpers warranted a dedicated service at all, since they are form-related rather than a general API. berdir noted the functions are "form related callbacks and helpers, not an API," and that DI was "always tricky with these issues." godotislate later reviewed the MR and expressed reluctance about the utility class ("rickety menu UI code lives on as service code"), preferring the logic be moved or marked @internal to avoid expanding the public API surface. nicxvan argued for an internal utility class so it stays isolated from the hook service. That compromise held: menuUiNodeSave() was marked @internal while getMenuLinkDefaults() remained public. At commit time godotislate applied two final refinements directly: moving the @internal annotation from the class level down to just the menuUiNodeSave() method, and switching the service declaration to autowire form Drupal\menu_ui\MenuUiUtility: ~.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3581958: Alter hook for site configure form in DemoUmamiHooks uses outdated services

Mon, 13 Apr 2026 15:12:43 +0000

Project: Drupal Core
Type: Normal bug report
Version: 11.x-dev
Status: Fixed
Diff: 1bf6e1f
Discussion: #3581958 · 5 contributors · 23 comments
Followers: 5

Summary

Installing the Umami demo profile through the browser UI with "Check for updates automatically" enabled caused a fatal error after submitting the site configuration form. The page displayed "The website encountered an unexpected error" with a Symfony DependencyInjection RuntimeException about a synthetic service. This bug has been fixed; Umami can now be installed through the UI without errors regardless of whether the update status module is enabled.

Impact

No upgrade or configuration changes required.

Technical details

The Umami install profile's DemoUmamiHooks class implements hook_form_install_configure_form_alter (via the #[Hook] attribute) to add a submit handler to the site configuration form. When the form is submitted with "Check for updates automatically" checked, SiteConfigureForm::submitForm() installs the update module, which triggers a full container rebuild. Any service objects instantiated from the old container become stale.

The submit handler was registered as the instance callable [$this, 'installConfigureSubmit'], where $this is the DemoUmamiHooks service object from the old container. When Drupal invokes this handler after the container rebuild, installConfigureSubmit() calls setUserPasswords(), which used $this->entityTypeManager->getStorage('user') -- the entityTypeManager was injected from the old container and is now stale, causing the crash.

The fix converts both installConfigureSubmit() and setUserPasswords() to static methods in DemoUmamiHooks. The callable in formInstallConfigureFormAlter() is changed from [$this, 'installConfigureSubmit'] to [static::class, 'installConfigureSubmit'], and setUserPasswords() replaces $this->entityTypeManager->getStorage('user') with \Drupal::entityTypeManager()->getStorage('user'). Using the global \Drupal static ensures the entity type manager is always retrieved from the current (rebuilt) container. The EntityTypeManagerInterface constructor parameter is removed from DemoUmamiHooks entirely. A code comment was added to setUserPasswords() explaining why DI is intentionally avoided here. Both methods are also marked @internal.

The root cause was traced (via git bisect) to #3516264, where CKEditor5Hooks was refactored to inject ModuleHandlerInterface and LibraryDependencyResolverInterface via DI instead of calling \Drupal::moduleHandler() inline -- the opposite pattern. The sibling fix for SiteConfigureForm itself is #3573856.

Test coverage was added by overriding installParameters() in UmamiMultilingualInstallTest to set enable_update_status_module = TRUE, so the functional test now exercises the container-rebuild path.

Contribution

Timeline

Opened: March 27, 2026
Committed: April 13, 2026 (16 days and 2 commits later)

Key contributors

godotislate
benjifisher (Harvard Web Publishing)
nicxvan (nLightened Development LLC)
dries
catch (Third and Grove)

Collaboration

benjifisher's review drove several improvements. After reproducing the error manually on both main and the feature branch, he used git bisect to identify #3516264 as the change that introduced the regression, and explained the link between that issue's DI refactor and the crash. He requested a code comment in setUserPasswords() explaining why DI is not used, which godotislate added. He also opened a broader discussion about guidelines for using DI safely around container rebuilds, to which godotislate responded with a clear explanation of the mechanism: a container rebuild invalidates all service objects instantiated from the previous container, and static methods with \Drupal:: calls are the correct escape hatch in this situation. dries spotted a minor inaccuracy in the added comment (SiteConfigureForm::submit() vs. SiteConfigureForm::submitForm()), which was also corrected before the issue was marked RTBC.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3581407: Remove unused properties from unit tests

Mon, 13 Apr 2026 08:07:14 +0000

Project: Drupal Core
Type: Normal task
Version: main
Status: Fixed
Diff: 473f5e4
Discussion: #3581407 · 4 contributors · 15 comments
Followers: 6

Summary

Thirteen unused protected properties were removed from unit test classes across Drupal core. The properties were declared at the class level but never actually read anywhere in the tests, making them dead code. The cleanup has no effect on test coverage or runtime behavior.

Impact

No upgrade or configuration changes required.

Technical details

This issue was discovered via shipmonk/dead-code-detector (tracked in #3581155). The single commit removes 109 lines of dead property declarations from 13 unit test files:

BlockPageVariantTest - $contextHandler (ContextHandlerInterface mock)
FieldStorageConfigEntityUnitTest - $entityTypeId (string)
FieldUninstallValidatorTest - $fieldTypePluginManager (FieldTypePluginManagerInterface mock)
FormErrorHandlerTest - $linkGenerator (LinkGeneratorInterface mock)
ContentLanguageSettingsUnitTest - $entityTypeId (string, plus its setUp() assignment)
MigrateSourceTest - $sourceIds (array)
SubProcessTest - $plugin (SubProcess instance)
AliasManagerTest - $cacheKey and $path (both strings)
SearchPluginCollectionTest - $pluginInstances (array of SearchInterface)
TimestampItemNormalizerTest - $item (TimestampItem)
PathBasedBreadcrumbBuilderTest - $linkGenerator property and a corresponding setLinkGenerator() setter on the TestPathBasedBreadcrumbBuilder stub class, plus the use import for LinkGeneratorInterface
UserRegistrationResourceTest - ERROR_MESSAGE constant and $reflection (ReflectionClass)
MessagesTest (views) - $view (ViewExecutable)

The investigation in comments traced several of these properties back to their original additions (e.g. ContentLanguageSettingsUnitTest to #2355909, SubProcessTest to #2147811, AliasManagerTest to #2233623) and confirmed they were never read from the start. A companion issue (#3581404) handled the same cleanup for kernel tests. The scope was intentionally limited to properties flagged by shipmonk/dead-code-detector; any additional properties spotted during review were noted for separate follow-up issues.

Contribution

Timeline

Opened: March 25, 2026
Committed: April 13, 2026 (18 days later)

Key contributors

longwave (Full Fat Things)
borisson_ (Calibrate)
catch (Third and Grove)
smustgrave (Mobomo)

This content is AI-generated and may contain errors. See Drupal Digests for more.

#2986699: Add missing getter method to retrieve range (limit/offset) from Select query objects

Mon, 13 Apr 2026 07:49:34 +0000

Project: Drupal Core
Type: Normal bug report
Version: 11.x-dev
Status: Fixed
Diff: b124145
Discussion: #2986699 · 9 contributors · 35 comments
Followers: 10

Summary

Drupal's Select query builder has always supported $query->range($start, $length) to apply LIMIT/OFFSET, but there was no public way to read that range back out of the query object. This made it impossible for hook_query_alter() implementations, query decorators, and contrib modules to inspect whether a range had already been set and what its values were. A new getRange() method is now available on all Select query objects, returning null when no range has been configured, or an associative array with start and length keys when one has. The change is backward compatible.

Impact

Affects module maintainers.

New API: New getRange(): ?array method on SelectInterface, Select, and SelectExtender returns null when no range is set, or ['start' => int, 'length' => ?int] when one is.

Technical details

The Select class stores its range limiter in a protected $range property (typed array|null). Before this change the property could only be written via range() and was not readable through any public API.

The fix adds getRange(): ?array to three places:

SelectInterface (in core/lib/Drupal/Core/Database/Query/SelectInterface.php): new method declaration with a precise phpdoc return type of array{start: int, length: ?int}|null and descriptions of the two array keys (start — first record to return; length — number of records to return).
Select (in core/lib/Drupal/Core/Database/Query/Select.php): concrete implementation that returns $this->range by reference, consistent with the existing by-reference getters (getTables(), getGroupBy()). The @var array docblock on $range was also corrected to @var array|null.
SelectExtender (in core/lib/Drupal/Core/Database/Query/SelectExtender.php): delegation wrapper that forwards the call to $this->query->getRange(), also by reference.

The method returns by reference so that callers can mutate the range in-place (as demonstrated by the new kernel tests). Returning null — rather than an empty array — when no range is set was a deliberate decision made during review; drunken monkey pointed out the discrepancy between an earlier draft (which returned []) and the issue summary's stated intent of returning null.

New kernel test class SelectGetRangeTest (in core/tests/Drupal/KernelTests/Core/Database/SelectGetRangeTest.php) covers both Select and SelectExtender: it asserts null before any range is applied, correct array values after range() is called, and that the returned reference is live (mutations via the reference affect the query).

Contribution

Timeline

Opened: July 18, 2018
Committed: April 13, 2026 (7 years and 2 commits later)

Key contributors

borisson_ (Calibrate)
drunken monkey
neptune-dc

Collaboration

The issue was originally filed by drunken monkey in July 2018 with a patch, but it stalled without a test. Seven years later, at a Bug Smash Initiative session, luke.stewart picked it up, verified the feature was still missing, and noted it needed tests and possibly a change record. neptune-dc opened a merge request with kernel tests. drunken monkey returned to review, added a return type hint to the interface declaration, and flagged the mismatch between the draft returning [] and the stated intent of returning null — neptune-dc updated the code accordingly. smustgrave rebased and aligned the change record for the main branch before catch committed it.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3562868: Add types to class properties in core/tests code via Rector - round 3

Mon, 13 Apr 2026 07:35:51 +0000

Project: Drupal Core
Type: Normal task
Version: main
Status: Fixed
Diff: 03614b2
Discussion: #3562868 · 4 contributors · 20 comments
Followers: 6

Summary

This is a purely internal code-quality change that adds native PHP type declarations to class properties in Drupal's core/tests directory. It has no effect on site behavior, configuration, or the public API. Because the changes are confined to test code, there are no backwards-compatibility concerns.

Impact

No upgrade or configuration changes required.

Technical details

This issue is the third in a series (following #3551596 and #3562361) that progressively modernizes core/tests code using Rector. The first two rounds added return types and parameter type hints; this round specifically targets class property declarations.

The workflow ran Rector with ->withPreparedSets(typeDeclarations: true) over core/tests, then applied PHPCS to fix code style. No PHPStan baseline update was required because native property types are only enforced at PHPStan level 6; core currently runs at level 1.

The commit touches around 70 test files with 618 additions and 973 deletions. The dominant pattern is replacing a @var docblock with a native typed property declaration. For example, in BuildTestBase.php: private $workspaceDir (with @var string docblock) becomes private string $workspaceDir, and nullable properties like $hostPort and $commandProcess become private ?int $hostPort = NULL and private ?Process $commandProcess = NULL.

Rector cannot automatically determine intersection types for PHPUnit mock objects because it only sees the interface being mocked, not the MockObject or Stub wrapper. Those properties were manually typed with PHP intersection syntax after Rector's output, e.g., protected CsrfTokenGenerator&MockObject $csrfToken, protected StorageInterface&Stub $storage. One pre-existing error was also corrected: FileUrlGeneratorInterface|MockObject (a union type) was fixed to FileUrlGeneratorInterface&MockObject (the correct intersection type).

Where a single property is assigned both a MockObject and a Stub in different test methods, a @todo split the variable to allow proper type annotation was added and the property was left with a plain interface type. The change is a pure mechanical transformation plus the manual intersection-type additions; mondrake explicitly avoided fixing other issues along the way to keep the MR focused.

Contribution

Timeline

Opened: December 12, 2025
Committed: April 13, 2026 (4 months later)

Key contributors

mondrake
catch (Third and Grove)

Collaboration

borisson_ noticed test failures in the merge request and asked whether something was wrong with the Rector rule. mondrake explained that the failures stemmed from missing deprecations in the calling code rather than a misconfigured rule, and noted that Rector cannot intersect MockObject types automatically, requiring manual additions. smustgrave asked whether a PHPStan baseline update was needed and whether new violations would be caught going forward; mondrake clarified that Rector and PHPStan are independent tools and that native property types only become a PHPStan concern at level 6, which core has not yet reached.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3522561: Fully type StatementInterface methods' parameters

Sun, 12 Apr 2026 20:26:14 +0000

Project: Drupal Core
Type: Normal task
Version: 11.x-dev
Status: Fixed
Diff: ab14cc0
Discussion: #3522561 · 7 contributors · 38 comments
Followers: 7

Summary

All method parameters in StatementInterface now carry proper PHP type declarations. Previously, the interface used untyped parameters that relied on runtime assert() checks inside StatementBase to validate types. Module developers who implement or extend StatementInterface directly will need to update their method signatures to match the new typed versions. Additionally, the $cursor_orientation and $cursor_offset parameters of fetch() are deprecated as of drupal:11.4.0 and will be removed in drupal:12.0.0 with no replacement.

Impact

Affects module maintainers.

API change: All StatementInterface method parameters now carry PHP type declarations; $cursor_orientation and $cursor_offset on fetch() are deprecated in drupal:11.4.0 and removed in drupal:12.0.0.
Deprecation: fetch() parameters $cursor_orientation and $cursor_offset deprecated in drupal:11.4.0, removed in drupal:12.0.0; no replacement.

Technical details

The database layer's StatementInterface (core/lib/Drupal/Core/Database/StatementInterface.php) had untyped parameters across its fetch and execute methods that were only validated at runtime via assert() calls in StatementBase. This issue replaced those assertions with proper PHP type declarations on both the interface and its base implementation.

StatementInterface signature changes:

execute(?array $args = [], array $options = []) -- was fully untyped
setFetchMode(FetchAs $mode, string|int|null $a1 = NULL, array $a2 = []) -- $mode was untyped
fetch(?FetchAs $mode = NULL, $cursor_orientation = NULL, $cursor_offset = NULL) -- $mode was untyped; $cursor_orientation and $cursor_offset are now deprecated in drupal:11.4.0 (removal in drupal:12.0.0, see #3551924)
fetchField(int $index = 0) -- was untyped
fetchAll(?FetchAs $mode = NULL, ?int $column_index = NULL, ?array $constructor_arguments = NULL) -- was untyped
fetchCol(int $index = 0) -- was untyped
fetchAllKeyed(int $key_index = 0, int $value_index = 1) -- was untyped
fetchAllAssoc(string $key, ?FetchAs $fetch = NULL) -- both parameters were untyped; $fetch also drops the previously documented (and already-deprecated) int|string union for PDO constants, accepting only ?FetchAs

In StatementBase (core/lib/Drupal/Core/Database/Statement/StatementBase.php), the assert() guards were removed and the concrete signatures were updated accordingly. In the 11.x backport, StatementBase retains FetchAs|int union types for $mode arguments on setFetchMode(), fetch(), fetchAll(), and fetchAllAssoc() to preserve backward compatibility with the existing deprecation path for integer PDO::FETCH_* constants; the interface itself uses only FetchAs since parameter types are contravariant -- an implementing class may accept types at least as wide as the interface declares, so tightening the interface signature requires no deprecation cycle. This design insight, raised by longwave in comment #21, simplified the implementation substantially (the original approach had planned a full @todo/commented-out deprecation dance, which turned out to be unnecessary for parameter types as opposed to return types).

The StatementInterface phpdoc example code was also updated to reference StatementBase instead of StatementWrapperIterator and to use fully-qualified class names. The fetchObject() return type in the interface was refined from mixed to object|false|null.

Upgrade

Any class that directly implements StatementInterface (rather than extending StatementBase) must update its method signatures:

// Before
public function execute($args = [], $options = []) {}
public function setFetchMode($mode, $a1 = NULL, $a2 = []) {}
public function fetch($mode = NULL, $cursor_orientation = NULL, $cursor_offset = NULL) {}
public function fetchField($index = 0) {}
public function fetchAll($mode = NULL, $column_index = NULL, $constructor_arguments = NULL) {}
public function fetchCol($index = 0) {}
public function fetchAllKeyed($key_index = 0, $value_index = 1) {}
public function fetchAllAssoc($key, $fetch = NULL) {}

// After
public function execute(?array $args = [], array $options = []) {}
public function setFetchMode(FetchAs $mode, string|int|null $a1 = NULL, array $a2 = []) {}
public function fetch(?FetchAs $mode = NULL, $cursor_orientation = NULL, $cursor_offset = NULL) {}
public function fetchField(int $index = 0) {}
public function fetchAll(?FetchAs $mode = NULL, ?int $column_index = NULL, ?array $constructor_arguments = NULL) {}
public function fetchCol(int $index = 0) {}
public function fetchAllKeyed(int $key_index = 0, int $value_index = 1) {}
public function fetchAllAssoc(string $key, ?FetchAs $fetch = NULL) {}

Any call to fetch() that passes non-NULL values for $cursor_orientation or $cursor_offset will trigger a deprecation error in drupal:11.4.0. Remove those arguments; there is no replacement.

Contribution

Timeline

Opened: May 3, 2025
Committed: April 11, 2026 (11 months and 2 commits later)

Key contributors

mondrake
smustgrave (Mobomo)
longwave (Full Fat Things)
dcam
godotislate
amateescu

Collaboration

longwave's comment #21 pointed out that PHP parameter types are contravariant -- adding a type hint to an interface parameter does not break implementing classes, because PHP allows implementors to accept a wider type. This observation made the planned deprecation scaffolding unnecessary for parameter type additions, simplifying the patch significantly. mondrake incorporated this in the next push.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3583849: Deprecate PgSql Connection::*Savepoint() methods

Sat, 11 Apr 2026 21:40:46 +0000

Project: Drupal Core
Type: Normal task
Version: 11.x-dev
Status: Fixed
Diff: 5b4ad87
Discussion: #3583849 · 4 contributors · 12 comments
Followers: 6

Summary

Three PostgreSQL-specific savepoint methods on the database connection class (addSavepoint(), releaseSavepoint(), rollbackSavepoint()) are deprecated in Drupal 11.4.0 and will be removed in 13.0.0. Custom or contributed modules that call these methods on a PostgreSQL connection need to switch to the standard TransactionManager API. This is an internal change with no effect on site behavior.

Impact

Affects module maintainers.

Deprecation: Connection::addSavepoint(), Connection::releaseSavepoint(), Connection::rollbackSavepoint(), and the $savepoints property on the PgSql driver are deprecated; use TransactionManager::startTransaction() with Transaction::commitOrRelease()/rollback() instead.

Technical details

The PostgreSQL driver in Drupal uses savepoints named mimic_implicit_commit to wrap individual queries (SELECT, INSERT, UPDATE, DELETE, TRUNCATE, UPSERT) and schema introspection calls in a rollback-safe savepoint. This lets PostgreSQL mimic MySQL/SQLite behavior where a single failed query inside a transaction does not abort the entire transaction, which is important for on-demand table creation (e.g. \Drupal\Core\Cache\DatabaseBackend).

Previously, this was managed through three custom methods on Drupal\pgsql\Driver\Database\pgsql\Connection: addSavepoint(), releaseSavepoint(), and rollbackSavepoint(), along with a $savepoints property that tracked active savepoints by name. These methods were thin wrappers around startTransaction() and the Transaction object's own commitOrRelease()/rollback() methods, making them redundant after #3398767 introduced explicit commit support and #3406985 converted all core transactions to use ::commitOrRelease().

This change deprecates all three methods and the $savepoints property, adding @trigger_error() calls to each. All internal call sites across eight files in core/modules/pgsql/src/Driver/Database/pgsql/ (Connection.php, Delete.php, Insert.php, Schema.php, Select.php, Truncate.php, Update.php, Upsert.php) were migrated to the new pattern. The old pattern called addSavepoint() unconditionally (the transaction check was inside the method). The new pattern explicitly checks $this->connection->inTransaction() first, then calls $this->connection->startTransaction('mimic_implicit_commit') and operates directly on the returned Transaction object, using $savepoint->commitOrRelease() on success and $savepoint->rollback() on exception. The Connection::query() method was similarly restructured, collapsing the $wrap_with_savepoint variable into a single if block.

Upgrade

If custom or contributed code calls addSavepoint(), releaseSavepoint(), or rollbackSavepoint() on the PostgreSQL connection, replace them with the TransactionManager pattern:

Before:

$this->connection->addSavepoint();
try {
  $result = do_something();
  $this->connection->releaseSavepoint();
}
catch (\Exception $e) {
  $this->connection->rollbackSavepoint();
  throw $e;
}

After:

if ($this->connection->inTransaction()) {
  $savepoint = $this->connection->startTransaction('mimic_implicit_commit');
}
try {
  $result = do_something();
  if (isset($savepoint)) {
    $savepoint->commitOrRelease();
  }
}
catch (\Exception $e) {
  if (isset($savepoint)) {
    $savepoint->rollback();
  }
  throw $e;
}

Contribution

Timeline

Opened: April 9, 2026
Committed: April 11, 2026 (2 days and 2 commits later)

Key contributors

mondrake
andypost (Skilld)
amateescu

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3406985: Convert all transactions in core to use explicit ::commitOrRelease()

Sat, 11 Apr 2026 21:29:54 +0000

Project: Drupal Core
Type: Normal task
Version: 11.x-dev
Status: Fixed
Diff: 8d78571
Discussion: #3406985 · 8 contributors · 63 comments
Followers: 21

Summary

All database transactions across Drupal core now use explicit $transaction->commitOrRelease() instead of relying on implicit commit when the Transaction object goes out of scope or is unset. This is an internal change with no direct user-facing effect, but it lays the groundwork for deprecating the implicit commit-on-destruct behavior and resolving a class of failures caused by unpredictable object destruction order (particularly with xdebug 3.3+ in develop mode).

Impact

No upgrade or configuration changes required.

Technical details

Drupal's database layer wraps operations in Transaction objects. Historically, these transactions were committed when the object was destroyed (going out of scope or via unset($transaction)). This "autocommit on destruct" pattern is fragile because PHP does not guarantee destruction order during shutdown, and xdebug 3.3+ in develop mode changes destruction order enough to cause failures. The parent issue #3398767 introduced Transaction::commitOrRelease() as an explicit alternative; this issue converts every transaction site in core to use it.

The commit touches 15 production files across the config, database, entity, menu, routing, locale, sqlite, and workspaces subsystems. The changes follow a few patterns:

Where core previously used unset($transaction) as an intentional commit trigger (in ExportStorageManager, ImportStorageTransformer, PoDatabaseWriter, and WorkspaceTracker::moveTrackedEntities), those calls are replaced with $transaction->commitOrRelease().

In try/catch blocks where transactions were committed implicitly by falling through (e.g. SqlContentEntityStorage::save(), SqlContentEntityStorage::delete(), SqlContentEntityStorage::restore(), MenuTreeStorage::doSave(), MatcherDumper::dump(), Insert::execute(), WorkspaceMerger::merge(), WorkspacePublisher::publish()), an explicit $transaction->commitOrRelease() is added before the end of the try block.

In SqlContentEntityStorage, the catch blocks now wrap $transaction->rollBack() calls in an additional try/catch for TransactionOutOfOrderException, because after an explicit commit the transaction may already be resolved when the catch block runs. Similarly, MenuRouterRebuildSubscriber::menuLinksRebuild() adds a $this->connection->inTransaction() guard before attempting rollback.

In TransactionManagerBase::unpile(), an early return is added when getConnectionTransactionState() returns ClientConnectionTransactionState::Committed. This makes commitOrRelease() a safe no-op when called on a transaction that was already committed (e.g. by a prior DDL statement on a non-transactional-DDL database), instead of throwing TransactionOutOfOrderException. A minor fix in TransactionManagerBase::rollback() also changes a direct property assignment to use the setConnectionTransactionState() setter.

Test updates in TransactionTest and DeleteTruncateTest convert implicit commit patterns to use commitOrRelease(), and relax expectations that previously required TransactionOutOfOrderException in scenarios where the transaction was already committed. Deprecation of the implicit commit behavior is deferred to #3584238.

Contribution

Timeline

Opened: December 8, 2023
Committed: April 11, 2026 (2 years and 2 commits later)

Key contributors

mondrake
mradcliffe (Kosada)
ghost of drupal past
godotislate
amateescu

Collaboration

mondrake worked on this issue for over two years, maintaining the MR through repeated rebases. After the full scope (conversions plus deprecations) stalled in review, mondrake opened a second MR with reduced scope covering only the conversion of core transactions to explicit commit, deferring the deprecation work to #3584238. This unblocked progress. ghost of drupal past raised a question about whether the historical decision in #301049 to prohibit explicit commits had been considered. amateescu investigated and confirmed that the prohibition in #301049 was a safeguard against bypassing the nesting layer via raw PDO::commit(), not a design objection to explicit commits through the managed API, and committed the change.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3548957: Deprecate ToStringTrait

Fri, 10 Apr 2026 20:06:48 +0000

Project: Drupal Core
Type: Normal task
Version: 11.x-dev
Status: Fixed
Diff: 671cd63
Discussion: #3548957 · 5 contributors · 25 comments
Followers: 6

Summary

ToStringTrait is deprecated. The trait existed to work around a PHP bug (fixed in PHP 7.4) that prevented __toString() from throwing exceptions. Since Drupal requires PHP 8.2+, the workaround is unnecessary. The two classes that used the trait, DateTimePlus and TranslatableMarkup, now implement __toString() directly. This is an internal change with no visible effect on site behavior.

Impact

Affects module maintainers.

API change: DateTimePlus and TranslatableMarkup no longer use ToStringTrait; exceptions in __toString() now propagate instead of being converted to trigger_error() calls.
Deprecation: ToStringTrait deprecated in 11.4.0, removed in 13.0.0; implement __toString() directly instead.

Technical details

ToStringTrait provided a __toString() that caught exceptions and converted them into trigger_error() calls, because older PHP versions made it fatal for __toString() to throw. The trait also exposed a _die() method used only to make tests possible. Since PHP 7.4 lifted that restriction, the entire mechanism is dead code.

The trait had exactly two users: DateTimePlus and TranslatableMarkup. Both now have their own __toString() that calls (string) $this->render() without exception handling. DateTimePlus explicitly implements \Stringable. TranslatableMarkup already satisfies \Stringable through its parent FormattableMarkup, which implements MarkupInterface (extends \Stringable). Its new __toString() overrides the parent's version to call render() instead of placeholderFormat().

The Drupal error handler in errors.inc had a special case ($to_string) that treated E_USER_ERROR from __toString() as fatal. This was removed because the trait no longer emits those errors.

The ToStringTrait file is kept but triggers E_USER_DEPRECATED at file load time, scheduled for removal in drupal:13.0.0. The PHPStan baseline entries for _die() on both classes were removed. TranslatableMarkupTest was simplified: instead of a custom error handler verifying that exceptions become E_USER_WARNING, it uses expectException() to confirm that exceptions now propagate normally.

Upgrade

Replace use ToStringTrait; with a direct __toString() method:

// Before
use Drupal\Component\Utility\ToStringTrait;

class MyClass {
  use ToStringTrait;

  public function render() {
    return 'output';
  }
}

// After
class MyClass implements \Stringable {
  public function render() {
    return 'output';
  }

  public function __toString(): string {
    return (string) $this->render();
  }
}

Contribution

Timeline

Opened: September 26, 2025
Committed: April 10, 2026 (6 months and 2 commits later)

Key contributors

andypost
chi
dcam
amateescu

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3301682: Define bundle classes via attributes

Fri, 10 Apr 2026 12:19:41 +0000

Project: Drupal Core
Type: Normal feature request
Version: main
Status: Fixed
Diff: ff83524
Discussion: #3301682 · 14 contributors · 77 comments
Followers: 33

Summary

Bundle classes can now be registered by placing a #[Bundle] attribute on a class in a module's Entity/ namespace, instead of implementing hook_entity_bundle_info_alter(). This removes boilerplate when a project has many bundle classes spread across many modules. The attribute accepts entityType, bundle, label, and translatable parameters. The hook_entity_bundle_info_alter() approach still works and can override attribute-provided values.

Impact

Affects module maintainers.

New API: New \Drupal\Core\Entity\Attribute\Bundle attribute for declaring bundle classes without hook_entity_bundle_info_alter()

Technical details

Declaring a bundle class previously required implementing hook_entity_bundle_info_alter() and setting the class for each bundle. With many bundle classes across many modules, this meant many hook implementations and use statements in .module files.

The new \Drupal\Core\Entity\Attribute\Bundle attribute extends ContentEntityType, which itself extends EntityType. Because EntityTypeManager already discovers classes with EntityType attributes under each module's Entity/ subdirectory (recursively), bundle classes are picked up by the existing AttributeDiscoveryWithAnnotations without introducing a new discovery mechanism. The issue explored three other approaches (a plugin manager, a compiler pass, and a standalone discovery class in EntityTypeManager::findDefinitions()) before settling on this derivative-based design proposed by ghost of drupal past.

The Bundle constructor formats its ID as {entity_type_id}:{bundle} using the plugin derivative separator. In EntityTypeManager::findDefinitions(), definitions whose IDs contain : are filtered out of the normal entity type definitions. Their bundle class, label, and translatable info is collected and attached to the parent entity type definition via the entity_type_bundle_info property. EntityTypeBundleInfo::getAllBundleInfo() then reads that property and merges it into bundle info. The processing order is: hook_entity_bundle_info runs first, then attribute bundle info is applied, then hook_entity_bundle_info_alter runs. Optional attribute properties (label, translatable) that are NULL do not override values already set by hooks.

For entity types that define a bundle_entity_type (e.g. nodes use node_type), the attribute cannot create new bundles. If the bundle entity does not exist, the attribute info is silently skipped (per berdir's suggestion in #65-#69). This prevents invalid states where bundles exist without their expected config entities.

EntityType::__construct() was updated to handle derivative IDs: if the ID contains :, the entity type part and the bundle part are validated separately against ID_MAX_LENGTH and BUNDLE_MAX_LENGTH (both 32 characters). EntityTypeManager::getDefinition() throws a \LogicException if called with a derivative ID, preventing bundle definitions from being accessed as entity types.

Upgrade

To use the new attribute, place #[Bundle] on a class extending the entity type's base class in your module's Entity/ namespace:

use Drupal\Core\Entity\Attribute\Bundle;
use Drupal\Core\StringTranslation\TranslatableMarkup;
use Drupal\node\Entity\Node;

#[Bundle(
  entityType: 'node',
  bundle: 'article',
  label: new TranslatableMarkup('Article'),
)]
class Article extends Node {}

The corresponding hook_entity_bundle_info_alter() implementation can then be removed. The hook_entity_bundle_info_alter() still works and takes precedence over attributes, so both approaches can coexist.

Projects migrating from the contrib Bundle Class Attribute module need to update the attribute namespace and rename the entityType parameter from entityType to entity_type_id if the contrib module used that name (or verify the parameter name matches).

Contribution

Timeline

Opened: August 4, 2022
Committed: April 10, 2026 (3 years and 2 commits later)

Key contributors

dpi (PreviousNext)
mstrelan (PreviousNext)
avpaderno
berdir (MD Systems GmbH)
godotislate
ghost of drupal past
catch (Third and Grove)
acbramley (PreviousNext)

Collaboration

mstrelan opened the issue and created the first three merge requests exploring different discovery approaches (plugin manager, compiler pass, standalone discovery). godotislate then proposed a fourth approach in MR 14763, and ghost of drupal past proposed the derivative-based approach in MR 14764, which godotislate implemented. berdir identified the problem of attributes creating bundles for entity types with bundle_entity_type (like nodes), leading to the safeguard that silently skips nonexistent bundle entities.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3226806: Move filter implementations from filter.module to plugin classes

Fri, 10 Apr 2026 10:34:44 +0000

Project: Drupal Core
Type: Normal task
Version: 11.x-dev
Status: Fixed
Diff: ec8c056
Discussion: #3226806 · 6 contributors · 52 comments
Followers: 9

Summary

Nine procedural functions in filter.module are deprecated and their logic moved into the corresponding filter plugin classes. This is part of the broader effort to eliminate core .module files (#3566536). The deprecated functions still work during the deprecation period by delegating to the plugin manager. No direct replacement is provided for calling the functions; callers should use the filter plugin manager instead.

Impact

Affects module maintainers.

API change: FilterUrl and FilterHtmlImageSecure now implement ContainerFactoryPluginInterface with new constructor parameters (BC layer falls back to service container with deprecation notice until 12.0.0)
Deprecation: Nine procedural functions in filter.module (_filter_url, _filter_url_parse_full_links, _filter_url_parse_email_links, _filter_url_parse_partial_links, _filter_url_escape_comments, _filter_url_trim, _filter_autop, _filter_html_escape, _filter_html_image_secure_process) deprecated in 11.4.0 for removal in 13.0.0; logic moved to FilterUrl, FilterAutoP, FilterHtmlEscape, and FilterHtmlImageSecure plugin classes with no direct replacement

Technical details

When filters were converted to plugins in #1868772, the plugin process() methods were thin wrappers that called back into procedural functions in filter.module. For example, FilterAutoP::process() just called _filter_autop(). This change moves the actual logic into the plugin classes and deprecates the procedural functions.

Four plugin classes are affected:

FilterAutoP: The line-break-to-paragraph logic from _filter_autop() is inlined directly into process(). No dependency injection needed.
FilterHtmlEscape: The one-liner _filter_html_escape() body (trim(Html::escape($text))) is inlined into process().
FilterUrl: The most complex change. The class now implements ContainerFactoryPluginInterface and receives the filter_protocols container parameter via #[Autowire(param: 'filter_protocols')]. The main URL-matching logic from _filter_url() moves into process(). Six helper functions become protected methods: parseFullLinks(), parseEmailLinks(), parsePartialLinks(), escapeComments(), unescapeComments(), and trimUrl(). The old _filter_url_escape_comments() used a static variable to toggle between escape and unescape modes; this was split into two separate methods using an $htmlComments instance property for temporary storage. The old _filter_url_trim() used a static variable to store the URL length; trimUrl() reads directly from $this->settings['filter_url_length'].
FilterHtmlImageSecure: Now implements ContainerFactoryPluginInterface and injects FileUrlGeneratorInterface, ModuleHandlerInterface, and the app.root parameter, replacing the \Drupal::service() and \Drupal::root() calls that were in _filter_html_image_secure_process().

The deprecated functions (_filter_url, _filter_autop, _filter_html_escape, _filter_html_image_secure_process) delegate to the appropriate plugin via the plugin manager so the code exists in only one place, per joachim's suggestion. The smaller callback functions (_filter_url_parse_full_links, _filter_url_parse_email_links, _filter_url_parse_partial_links, _filter_url_escape_comments, _filter_url_trim) retain their original logic inline since they cannot easily delegate to the plugin instance.

Tests in FilterKernelTest are updated to instantiate plugins via the plugin manager instead of calling the deprecated procedural functions.

Upgrade

Callers of _filter_autop(), _filter_html_escape(), or _filter_html_image_secure_process() should use the plugin manager:

$result = \Drupal::service('plugin.manager.filter')
  ->createInstance('filter_autop')
  ->process($text, $langcode)
  ->getProcessedText();

Callers of _filter_url() should pass settings when creating the plugin:

$result = \Drupal::service('plugin.manager.filter')
  ->createInstance('filter_url', ['settings' => ['filter_url_length' => 72]])
  ->process($text, $langcode)
  ->getProcessedText();

No replacement is provided for _filter_url_parse_full_links(), _filter_url_parse_email_links(), _filter_url_parse_partial_links(), _filter_url_escape_comments(), or _filter_url_trim(). These were internal callbacks.

Contribution

Timeline

Opened: August 4, 2021
Committed: April 10, 2026 (4 years and 2 commits later)

Key contributors

claudiu.cristea (Webikon)
nicxvan (nLightened Development LLC)
longwave (Full Fat Things)
joachim (Factorial GmbH)
amateescu
larowlan (PreviousNext)

Collaboration

This issue was opened by longwave in 2021 as a simple cleanup but sat idle for years. joachim initially argued underscore-prefixed functions could be removed without deprecation since they were always considered private, but claudiu.cristea pushed back noting that third-party code uses them (especially _filter_autop), establishing the deprecation approach. joachim later suggested having the deprecated functions delegate to the plugin so the logic only exists in one place, which shaped the final design. claudiu.cristea drove the implementation, creating a fresh MR after the original could not be rebased due to conflicts in deleted code.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3581817: Move uses of Shortcut from Jsonapi to Shortcut

Thu, 09 Apr 2026 21:44:59 +0000

Project: Drupal Core
Type: Normal task
Version: 11.x-dev
Status: Fixed
Diff: b4c833b
Discussion: #3581817 · 5 contributors · 26 comments
Followers: 7

Summary

This is an internal code reorganization with no user-facing effect. Shortcut-specific filter access logic that lived in the JSON:API module was moved to the Shortcut module, so the Shortcut module now owns its own access restrictions for JSON:API queries.

Impact

No upgrade or configuration changes required.

Technical details

TemporaryQueryGuard in JSON:API has a switch statement with hard-coded access conditions for several core entity types. Its own documentation notes that modules should implement hook_query_ENTITY_TYPE_access_alter() instead, and that the hard-coded cases exist only because some core entity types have not done so yet. The shortcut case restricted non-admin users to only query shortcuts from their currently displayed shortcut set.

This change removes the case 'shortcut' from TemporaryQueryGuard::getAccessCondition() and the hook_jsonapi_shortcut_filter_access implementation from JsonapiHooks. Both are moved to ShortcutHooks in the shortcut module.

The filter access hook (jsonapiShortcutFilterAccess) moves with a small difference: the new version adds ->addCacheContexts(['user']) to the access result, which was previously handled by the TemporaryQueryGuard code path that set cacheability on the condition side.

The query restriction (limiting results to the user's displayed shortcut set) is now implemented as hook_query_shortcut_access_alter via the new queryShortcutAccessAlter() method in ShortcutHooks. This follows the hook_query_TAG_alter pattern documented in TemporaryQueryGuard. The new implementation finds the shortcut_field_data base table and adds a condition on shortcut_set to match the user's displayed set.

A stale @var annotation in WorkflowTest that incorrectly referenced \Drupal\shortcut\ShortcutSetInterface was also fixed to \Drupal\workflows\WorkflowInterface.

Contribution

Timeline

Opened: March 27, 2026
Committed: April 9, 2026 (13 days and 2 commits later)

Key contributors

sourav_paul (Innoraft)
smustgrave (Mobomo)
quietone (PreviousNext)
longwave (Full Fat Things)
amateescu

Collaboration

An initial approach by sourav_paul introduced a new JSON:API API surface (static helper and new hook) to let shortcut own the logic. smustgrave and catch pushed an alternative that avoided adding new API. longwave then discussed the approach with smustgrave on Slack and produced the final merge request, which uses the existing hook_query_TAG_alter pattern already documented in TemporaryQueryGuard. The participants agreed this narrower approach was better than introducing new JSON:API API just to move one module's logic.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3457818: Optimize CacheContextsManager:::convertTokensToKeys()/optimizeTokens()

Thu, 09 Apr 2026 13:20:56 +0000

Project: Drupal Core
Type: Normal bug report
Version: 11.x-dev
Status: Fixed
Diff: 160ab21
Discussion: #3457818 · 9 contributors · 42 comments
Followers: 15

Summary

Sites with many cache context lookups per request, such as those using the Group module or the Access Policy API, were spending measurable CPU time inside CacheContextsManager::optimizeTokens(). This change makes that method significantly faster, reducing time spent there by roughly half in real-world profiling, with no change to behavior or public APIs.

Impact

No upgrade or configuration changes required.

Technical details

The bottleneck was in CacheContextsManager::optimizeTokens() in core/lib/Drupal/Core/Cache/Context/CacheContextsManager.php. Three algorithmic improvements were made:

Early return for single-token arrays. When count($context_tokens) <= 1, no ancestor can exist and no optimization is possible, so the method returns immediately instead of entering the loop.
O(1) ancestor lookup via hash table. The old code used in_array($ancestor, $context_tokens) (linear scan) to check whether an ancestor token was present. The new code builds $context_tokens_lookup = array_flip($context_tokens) once before the loop and uses isset($context_tokens_lookup[$ancestor]), reducing each ancestor check from O(n) to O(1).
Deferred getService() call. Previously, every token that contained a period or colon triggered a call to $this->getService($context_id)->getCacheableMetadata($parameter)->getCacheMaxAge() before checking for ancestors. Now the cheap string-based ancestor search runs first, and getService() is called only when an ancestor is actually confirmed. In one profiling session this dropped getService calls from 3,775 to only those cases where an ancestor exists.

The change deliberately avoids caching getCacheableMetadata() results, because cache context values can change during a request. That optimization (safe at minimum for anonymous users) is tracked in the companion issue #3582977.

The unit test CacheContextsManagerTest::testOptimizeTokens() was updated to assert exact container call counts using $this->exactly($expected_container_calls), replacing the old $this->any() stub. The StandardPerformanceTest was updated to reflect three fewer cache gets per measured scenario. The getMockContainer() helper was also converted from a mock to a stub since it no longer needs call-count expectations.

Contribution

Timeline

Opened: June 28, 2024
Committed: April 9, 2026 (1 year and 2 commits later)

Key contributors

kristiaanvandeneynde (Factorial GmbH)
berdir (MD Systems GmbH)
tibezh
klausi (jobiqo - job board technology)
longwave (Full Fat Things)
catch (Third and Grove)

Collaboration

The design went through one substantive shift. tibezh's initial patch included caching getCacheableMetadata() results in a class property, arguing the metadata is static. kristiaanvandeneynde blocked that specific change, pointing out that cache context values can legitimately change during a request and that caching them could produce incorrect optimization decisions. The final patch dropped the metadata cache entirely. catch later argued the concern may not apply to anonymous users and that a static cache is probably safe in that scope, but the two contributors agreed to pursue that improvement separately in #3582977 rather than complicate this fix.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3457818: Optimize CacheContextsManager:::convertTokensToKeys()/optimizeTokens()

Thu, 09 Apr 2026 13:20:56 +0000

Project: Drupal Core
Type: Normal bug report
Version: 11.x-dev
Status: Fixed
Diff: 160ab21
Discussion: #3457818 · 9 contributors · 42 comments
Followers: 15

Summary

Impact

No upgrade or configuration changes required.

Technical details

The bottleneck was in CacheContextsManager::optimizeTokens() in core/lib/Drupal/Core/Cache/Context/CacheContextsManager.php. Three algorithmic improvements were made:

Early return for single-token arrays. When count($context_tokens) <= 1, no ancestor can exist and no optimization is possible, so the method returns immediately instead of entering the loop.
O(1) ancestor lookup via hash table. The old code used in_array($ancestor, $context_tokens) (linear scan) to check whether an ancestor token was present. The new code builds $context_tokens_lookup = array_flip($context_tokens) once before the loop and uses isset($context_tokens_lookup[$ancestor]), reducing each ancestor check from O(n) to O(1).
Deferred getService() call. Previously, every token that contained a period or colon triggered a call to $this->getService($context_id)->getCacheableMetadata($parameter)->getCacheMaxAge() before checking for ancestors. Now the cheap string-based ancestor search runs first, and getService() is called only when an ancestor is actually confirmed. In one profiling session this dropped getService calls from 3,775 to only those cases where an ancestor exists.

Contribution

Timeline

Opened: June 28, 2024
Committed: April 9, 2026 (1 year and 2 commits later)

Key contributors

kristiaanvandeneynde (Factorial GmbH)
berdir (MD Systems GmbH)
tibezh
klausi (jobiqo - job board technology)
longwave (Full Fat Things)
catch (Third and Grove)

Collaboration

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3457818: Optimize CacheContextsManager:::convertTokensToKeys()/optimizeTokens()

Thu, 09 Apr 2026 13:20:56 +0000

Project: Drupal Core
Type: Normal bug report
Version: 11.x-dev
Status: Fixed
Diff: 160ab21
Discussion: #3457818 · 9 contributors · 42 comments
Followers: 15

Summary

Impact

No upgrade or configuration changes required.

Technical details

The bottleneck was in CacheContextsManager::optimizeTokens() in core/lib/Drupal/Core/Cache/Context/CacheContextsManager.php. Three algorithmic improvements were made:

Early return for single-token arrays. When count($context_tokens) <= 1, no ancestor can exist and no optimization is possible, so the method returns immediately instead of entering the loop.
O(1) ancestor lookup via hash table. The old code used in_array($ancestor, $context_tokens) (linear scan) to check whether an ancestor token was present. The new code builds $context_tokens_lookup = array_flip($context_tokens) once before the loop and uses isset($context_tokens_lookup[$ancestor]), reducing each ancestor check from O(n) to O(1).
Deferred getService() call. Previously, every token that contained a period or colon triggered a call to $this->getService($context_id)->getCacheableMetadata($parameter)->getCacheMaxAge() before checking for ancestors. Now the cheap string-based ancestor search runs first, and getService() is called only when an ancestor is actually confirmed. In one profiling session this dropped getService calls from 3,775 to only those cases where an ancestor exists.

Contribution

Timeline

Opened: June 28, 2024
Committed: April 9, 2026 (1 year and 2 commits later)

Key contributors

kristiaanvandeneynde (Factorial GmbH)
berdir (MD Systems GmbH)
tibezh
klausi (jobiqo - job board technology)
longwave (Full Fat Things)
catch (Third and Grove)

Collaboration

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3457818: Optimize CacheContextsManager:::convertTokensToKeys()/optimizeTokens()

Thu, 09 Apr 2026 13:20:56 +0000

Project: Drupal Core
Type: Normal bug report
Version: 11.x-dev
Status: Fixed
Diff: 160ab21
Discussion: #3457818 · 9 contributors · 42 comments
Followers: 15

Summary

Impact

No upgrade or configuration changes required.

Technical details

The bottleneck was in CacheContextsManager::optimizeTokens() in core/lib/Drupal/Core/Cache/Context/CacheContextsManager.php. Three algorithmic improvements were made:

Early return for single-token arrays. When count($context_tokens) <= 1, no ancestor can exist and no optimization is possible, so the method returns immediately instead of entering the loop.
O(1) ancestor lookup via hash table. The old code used in_array($ancestor, $context_tokens) (linear scan) to check whether an ancestor token was present. The new code builds $context_tokens_lookup = array_flip($context_tokens) once before the loop and uses isset($context_tokens_lookup[$ancestor]), reducing each ancestor check from O(n) to O(1).
Deferred getService() call. Previously, every token that contained a period or colon triggered a call to $this->getService($context_id)->getCacheableMetadata($parameter)->getCacheMaxAge() before checking for ancestors. Now the cheap string-based ancestor search runs first, and getService() is called only when an ancestor is actually confirmed. In one profiling session this dropped getService calls from 3,775 to only those cases where an ancestor exists.

Contribution

Timeline

Opened: June 28, 2024
Committed: April 9, 2026 (1 year and 2 commits later)

Key contributors

kristiaanvandeneynde (Factorial GmbH)
berdir (MD Systems GmbH)
tibezh
klausi (jobiqo - job board technology)
longwave (Full Fat Things)
catch (Third and Grove)

Collaboration

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3457818: Optimize CacheContextsManager:::convertTokensToKeys()/optimizeTokens()

Thu, 09 Apr 2026 13:20:56 +0000

Project: Drupal Core
Type: Normal bug report
Version: 11.x-dev
Status: Fixed
Diff: 160ab21
Discussion: #3457818 · 9 contributors · 42 comments
Followers: 15

Summary

Impact

No upgrade or configuration changes required.

Technical details

The bottleneck was in CacheContextsManager::optimizeTokens() in core/lib/Drupal/Core/Cache/Context/CacheContextsManager.php. Three algorithmic improvements were made:

Early return for single-token arrays. When count($context_tokens) <= 1, no ancestor can exist and no optimization is possible, so the method returns immediately instead of entering the loop.
O(1) ancestor lookup via hash table. The old code used in_array($ancestor, $context_tokens) (linear scan) to check whether an ancestor token was present. The new code builds $context_tokens_lookup = array_flip($context_tokens) once before the loop and uses isset($context_tokens_lookup[$ancestor]), reducing each ancestor check from O(n) to O(1).
Deferred getService() call. Previously, every token that contained a period or colon triggered a call to $this->getService($context_id)->getCacheableMetadata($parameter)->getCacheMaxAge() before checking for ancestors. Now the cheap string-based ancestor search runs first, and getService() is called only when an ancestor is actually confirmed. In one profiling session this dropped getService calls from 3,775 to only those cases where an ancestor exists.

Contribution

Timeline

Opened: June 28, 2024
Committed: April 9, 2026 (1 year and 2 commits later)

Key contributors

kristiaanvandeneynde (Factorial GmbH)
berdir (MD Systems GmbH)
tibezh
klausi (jobiqo - job board technology)
longwave (Full Fat Things)
catch (Third and Grove)

Collaboration

This content is AI-generated and may contain errors. See Drupal Digests for more.