Active
Project:
Drupal core
Version:
main
Component:
extension system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
29 Jan 2018 at 22:32 UTC
Updated:
5 Jun 2022 at 15:44 UTC
Jump to comment: Most recent
#2659940: Extension System, Part III: ThemeExtensionList and ThemeEngineExtensionList marks Module/Theme/Profile extension list as internal for several reasons:
Comments
Comment #2
dawehnerComment #3
almaudoh commentedAdded meta-issue for deprecating old methods
Comment #4
almaudoh commentedOne thing I think we should correct before considering extension system stable is that
ModuleHandlershould not hold the authoritative list of installed modules. The current implementation ofModuleHandlermeans 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 theModuleExtensionList::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.Comment #5
almaudoh commentedComment #10
cyb_tachyon commentedI 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.
Comment #11
geek-merlin#10: Tha patch would be trivial, feel free to crosslink an issue!
Comment #12
geek-merlinAs of the original IS: I feel like these classes should be final so not be subclassed, but open for decoration.
Comment #13
berdir#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?
Comment #15
cyb_tachyon commentedAdded #3179546: Tag ExtensionList services with extension.list
Comment #18
andypostNow it looks like duplicate of #2940190: [meta] Deprecations of old functions in Extension system
Comment #20
andypost