Problem/Motivation

The installer carried a special-case workaround for extension pathnames.
\Drupal\Core\Installer\ExtensionListTrait and the
InstallerModuleExtensionList / InstallerThemeExtensionList subclasses kept a
static pathname cache, and install_begin_request(), InstallStorage and
ExtensionInstallStorage primed ExtensionList::setPathname() for the install
profile. This existed because early-install profile pathnames were not otherwise
resolvable across container rebuilds.

The base ExtensionList now resolves manually added pathnames ($addedPathNames)
directly, so the installer-specific machinery is redundant and can be removed.

Proposed resolution

- Remove profile pathname priming from install_begin_request(), InstallStorage and ExtensionInstallStorage.
- Resolve the active install profile through the profile extension list in ConfigInstaller.
- Seed ModuleExtensionList added pathnames directly instead of via setPathname().
- Stop NormalInstallerServiceProvider swapping in the installer-specific extension lists.
- Reduce InstallerModuleExtensionList, InstallerThemeExtensionList`and ExtensionListTrait to deprecated backward-compatibility shims (deprecated in 11.5.0, removed in 13.0.0) — see CR #3577846: Installer-specific extension list implementations are deprecated.
- Deprecate the now internal-only ExtensionList::setPathname() (deprecated in 11.5.0, removed in 13.0.0).

Remaining tasks

- file CR
- clean-up code

User interface changes

API changes

Deprecated in drupal:11.5.0, removed in drupal:13.0.0:

- `Drupal\Core\Installer\ExtensionListTrait` — no replacement; base extension
list behaviour provides the same functionality.
- `Drupal\Core\Installer\InstallerModuleExtensionList` — use
`Drupal\Core\Extension\ModuleExtensionList`.
- `Drupal\Core\Installer\InstallerThemeExtensionList` — use
`Drupal\Core\Extension\ThemeExtensionList`.
- `Drupal\Core\Extension\ExtensionList::setPathname()` — internal; no replacement.

Data model changes

CommentFileSizeAuthor
#33 2934063-nr-bot_4afgtsns.txt91 bytesneeds-review-queue-bot

Issue fork drupal-2934063

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

dawehner created an issue. See original summary.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

quietone commented

This is now in \Drupal\Core\Installer\ExtensionListTrait.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

andypost’s picture

andypost
he/him
Primary language Russian
commented
Title: Remove the workaround in \Drupal\Core\Installer\InstallerModuleExtensionList::setPathname » Remove the workaround in \Drupal\Core\Installer\ExtensionListTrait::setPathname()
andypost’s picture

andypost
he/him
Primary language Russian
commented
Issue summary: View changes
Status: Active » Needs work

WIP MR created, probably it depends on #3335756: Drop sequences table in Drupal 12

andypost opened merge request !14808

andypost’s picture

andypost
he/him
Primary language Russian
commented
Status: Needs work » Needs review

rebased, ready to go

andypost’s picture

andypost
he/him
Primary language Russian
commented

created change record https://www.drupal.org/node/3577846

trying to remove remaining usage of setPath()

andypost’s picture

andypost
he/him
Primary language Russian
commented
Issue summary: View changes

there's not a lot of usage in contrib so the method could be deprecated in followup

https://search.tresbien.tech/search?q=setPathname%5C(

andypost’s picture

andypost
he/him
Primary language Russian
commented

Codex summarized that variable still required overlay for scanned modules, maybe it make sense to file follow-up

The key distinction is:

- $pathNames in ExtensionList:91 means “the complete filename map is initialized”.
- $addedPathNames:94 is the overlay for pathnames seeded from code.

That matters because getPathNames():423 uses NULL on $pathNames as its initialization sentinel. Once $pathNames is non-NULL, Drupal assumes the full available-extension map is already known and does not load state or rescan.

Why ModuleExtensionList cannot just write into $pathNames:

- %container.modules% only contains enabled modules, built by DrupalKernel::getExtensionsParameter():1637.
- extension.list.module must represent all available modules, not just enabled ones. ModuleExtensionList::doList():153 scans all modules, then marks installed status separately.
- ModuleInstaller::install():135 explicitly does reset()->getList() so newly added modules on disk are rediscovered.

If you seed $pathNames with the enabled-module subset, you are telling ExtensionList “the full map is ready”, which is false. That is exactly why driver_test disappeared earlier: the partial container seed prevented full discovery.

$addedPathNames is still doing one real job today:

- ModuleExtensionList::__construct():79 seeds enabled-module pathnames from %container.modules% as a fast path.
- getPath():552 and getPathname():523 can then answer for installed modules without initializing the full filename cache.

That fast path is not theoretical. It is what removed the extra query in the OpenTelemetry regressions you just found.

smustgrave’s picture

smustgrave commented

Should this be a D12 priority one?

catch’s picture

catch
he/him
Primary language English
commented
Status: Needs review » Needs work

The test failure here looks non-random.

andypost’s picture

andypost
he/him
Primary language Russian
commented
Status: Needs work » Needs review

Fixed AJAX test, the cause: core/tests/Drupal/FunctionalJavascriptTests/Ajax/AjaxTest.php:70 deliberately injects fakeLibrary/fakeLibrary into drupalSettings.ajaxPageState.libraries. On this branch, core/lib/Drupal/Core/Extension/ExtensionPathResolver.php:81 now throws for unknown extensions instead of degrading through the old dirname(getPathname()) behavior. That bubbles through library discovery during AJAX asset resolution, so the fake library kills the request with RuntimeException: Unable to complete AJAX request. The old job 9361908 and
the new job 9367508 are the same regression.

andypost’s picture

andypost
he/him
Primary language Russian
commented
Status: Needs review » Needs work
Issue tags: +DevDaysAthens2026

needs work to split it and revert changes in deprecated classes so any consumers will not break

andypost’s picture

andypost
he/him
Primary language Russian
commented

asked GPT to plan split it

## Summary

- Use 3 issues/MRs: one installer/pathname cleanup, one public API deprecation cleanup, one independent asset-library fix.
- Do not create separate issues for installer wrapper classes that are being deprecated.
- Deprecated installer classes should get only minimal BC/deprecation handling, not standalone refactoring.

## Issue 1: Remove installer pathname workaround

- Move the real behavior change into base extension-list handling so installer-specific static pathname caching is no longer needed.
- Stop the installer container from swapping in InstallerModuleExtensionList and InstallerThemeExtensionList.
- Remove installer/config/profile path priming workarounds from install and config storage code.
- Update related installer/profile kernel tests that manually seeded profile pathnames.
- Deprecate installer wrapper trait/classes as BC shims, but do not split their internals into separate work.

## Issue 2: Deprecate pathname APIs and update core usage

- Deprecate ExtensionList::getPathname(), ExtensionList::setPathname(), and ExtensionPathResolver::getPathname().
- Update core tests/callers to prefer getPath() for directories and getPathNames() when the info-file path is explicitly needed.
- Add focused deprecation coverage for the remaining deprecated API surface.
- Keep this separate from Issue 1 only because it is public API/deprecation-policy work and may need separate change-record review.

## Issue 3: Ignore unknown asset-library extensions

- Catch UnknownExtensionException in LibraryDiscoveryCollector.
- Return an empty library set for unknown client-supplied library extensions.
- Add focused unit coverage for unknown extension lookup.

## Test Plan

- Issue 1: installer/config/profile kernel tests, ExtensionListTest, PHPStan baseline check.
- Issue 2: ExtensionListTest, ExtensionPathResolverTest, deprecation tests, PHPCS/cspell for touched docs/messages.
- Issue 3: LibraryDiscoveryCollectorTest.

andypost’s picture

andypost
he/him
Primary language Russian
commented

Created split #3601471: Ignore unknown client-supplied asset library extensions in LibraryDiscoveryCollector

and working on to split deprecation to re-scope properly

andypost’s picture

andypost
he/him
Primary language Russian
commented

and split out deprecation #3601481: Deprecate extension pathname APIs in favor of path-based lookups

andypost opened merge request !16088

andypost’s picture

andypost
he/him
Primary language Russian
commented
Status: Needs work » Needs review

file clean MR https://git.drupalcode.org/project/drupal/-/merge_requests/16088

andypost’s picture

andypost
he/him
Primary language Russian
commented
Issue summary: View changes
andypost’s picture

andypost
he/him
Primary language Russian
commented

@alexpott I think it ready to go

needs-review-queue-bot’s picture

needs-review-queue-bot commented
Status: Needs review » Needs work
StatusFileSize
new 2934063-nr-bot_4afgtsns.txt91 bytes

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

longwave changed the visibility of the branch 2934063-remove-the-workaround to hidden.

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented
Status: Needs work » Reviewed & tested by the community

MR!16088 looks nice and self contained and ready to go to me.

  • catch committed 589a690c on main 
    task: #2934063 Remove the workaround in \Drupal\Core\Installer\...
catch’s picture

catch
he/him
Primary language English
commented
Version: main » 11.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)

This looks great, so much code removed/deprecated.

Committed/pushed to main, thanks!

Will need a backport MR for 11.x, looks like only one file conflicts.

andypost changed the visibility of the branch 2934063-remove-the-workaround to active.

andypost’s picture

andypost
he/him
Primary language Russian
commented
Status: Patch (to be ported) » Needs review

cherry-picked commit and added InstallerThemeEngineExtensionList as it was removed from main via #3575467: Remove deprecations related to the theme engine

using previous MR but target now 11.x https://git.drupalcode.org/project/drupal/-/merge_requests/14808

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented
Status: Needs review » Reviewed & tested by the community

Backport looks good, thanks @andypost.

  • catch committed 566590da on 11.x 
    task: #2934063 Remove the workaround in \Drupal\Core\Installer\...
catch’s picture

catch
he/him
Primary language English
commented
Status: Reviewed & tested by the community » Fixed

Committed/pushed to 11.x, thanks!

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

andypost’s picture

andypost
he/him
Primary language Russian
commented

CR updated, look ready for publishing

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.