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
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