Problem/Motivation

#2659940: Extension System, Part III: ThemeExtensionList and ThemeEngineExtensionList marks Module/Theme/Profile extension list as internal for several reasons:

  • Due to the complexity of the task, these changes could not be made in a single issue
  • The improvements in the installer takes time, so overall the API/class design is an ongoing work
  • Swapping out how modules/themes services is not a super common case

open questions

  • Figure out which issues are needed before things are stabilized.
  • Should we add an interface, but keep the classes itself as internal.
  • List usecases for extending the classes

Comments

dawehner created an issue. See original summary.

dawehner’s picture

Issue summary: View changes
almaudoh’s picture

Added meta-issue for deprecating old methods

almaudoh’s picture

One thing I think we should correct before considering extension system stable is that ModuleHandler should not hold the authoritative list of installed modules. The current implementation of ModuleHandler means you have to call ::setModuleList() each time the module list changes, e.g. after a module is installed. As a matter of fact, this info should be retrieved from the ModuleExtensionList::getInstalled() rather than the other way round (as currently implemented). I have raised #2941155: ModuleHandler should not maintain list of installed modules now that ModuleExtensionList exists to discuss around this issue.

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.

cyb_tachyon’s picture

I would like to see ExtensionList services tagged with `extension.list` so that modules can request all extension listing services.

A use case would be a module that provides handling for extension plugins - that module wouldn't necessarily care what type of extension (module, theme, unknown third party extension), it would just want the extension, if it has active status, and then to retrieve whatever plugin config data (usually yaml) it needs.

Happy to provide a patch, unless this issue needs to remain META and then I'll open another issue to tackle it.

geek-merlin’s picture

#10: Tha patch would be trivial, feel free to crosslink an issue!

geek-merlin’s picture

As of the original IS: I feel like these classes should be final so not be subclassed, but open for decoration.

berdir’s picture

#2347783: Deprecate drupal_get_path() and drupal_get_filename() and replace with ExtensionList::getPath() and ExtensionList::getPathname() adds an extension path resolver as an abstraction of those different extension types for getting their path, I'm not sure if other generic cases for accessing info from some any extension type is that common? I also voted against a generic tag based approach for that because it IMHO added quite a bit of complexity but I don't really see us adding other types of extensions?

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.

cyb_tachyon’s picture

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.

andypost’s picture

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.