Follow-up to #2281989: Add a fast and simple way to get module name from the module handler
Problem/Motivation
This function is only being called from AdminController and HelpController, yet it wants a full info file as an argument. We want to get rid of calls to system_get_info() and use the ModuleHandler instead.
Proposed resolution
Either offer this as a trait that both controllers can use or pass in a fake array('name' => $name) info array. Deprecate the function for removal in 9.0, or remove it.
This also allows us to get rid of the calls to system_get_info() and use ModuleHandler::getModuleList() and ModuleHandler::getName() instead
Remaining tasks
Patch
User interface changes
None
API changes
See issue title
Beta phase evaluation
| Issue category | Task because ollow up to #2281989: Add a fast and simple way to get module name from the module handler related to a larger refactoring going on in #2208429: Extension System, Part III: ExtensionList, ModuleExtensionList and ProfileExtensionList to untangle some of the theme/module related functionalitytd> |
|---|---|
| Issue priority | Normal because small DX improvement |
| Prioritized changes | The main goal of this issue is improving DX |
| Disruption | Not disruptive for core/contributed and custom modules/themes as there will only be a BC break if there's some contrib caller calling it with a different human-readable name than the module's real one which is extremely unlikely |
| Comment | File | Size | Author |
|---|---|---|---|
| #38 | 2466933-38.patch | 5.89 KB | andypost |
| #38 | interdiff.txt | 2.56 KB | andypost |
Comments
Comment #1
stefan.r commentedComment #2
stefan.r commentedComment #3
effulgentsia commentedI committed #2281989: Add a fast and simple way to get module name from the module handler, so this is no longer postponed.
What about leaving the function, but removing the 2nd parameter ($info)? Looks to me like the only thing that parameter is used for is for the human-readable name, and can't the function ask the module handler for that instead of requiring it as a parameter? I think it would solve the goal of the issue to remove the system_get_info() calls, and the only BC it would break is if there's some contrib caller calling it with a different human-readable name than the module's real one, which I think is enough of an edge case to be ok breaking.
Comment #4
stefan.r commentedYes that sounds like a step in the right direction :)
Comment #7
effulgentsia commentedAwesome. Thanks.
Comment #8
xjmIs the idea that
system_get_info()calls add performance overhead? Can we add a beta evaluation please since this is a normal task?Comment #9
stefan.r commentedNot a performance issue, system_get_info() is statically cached now so at best this will save a couple hundred microseconds (it's being called once per hook_help implementation in HelpController).
This is just a minor follow up to #2281989: Add a fast and simple way to get module name from the module handler related to a larger refactoring going on in #2208429: Extension System, Part III: ExtensionList, ModuleExtensionList and ProfileExtensionList to untangle some of the theme/module related functionality. We probably eventually want to get rid of system_get_info() and this helps toward that, as there is no reason for this function to need all of the module info.
Comment #10
piyuesh23 commentedAs per last comment from @stefan.r, looks like this issue needs a decision before work.
I am removing the novice tag, since it no longer follows the pointers on https://www.drupal.org/core-mentoring/novice-tasks.
Comment #11
xjmAgreed, thanks @piyuesh23.
Since this is an API change, we now should deprecate the argument instead of removing it. I agree with the longterm goal of removing
system_get_info()in general, but I think that is out of scope here. We can probably go ahead with this for the next development minor if we can do it in a BC way.Comment #17
almaudoh commentedNow that #2208429: Extension System, Part III: ExtensionList, ModuleExtensionList and ProfileExtensionList is in, this can be completed if still necessary, or it could be added to the scope of #2940189: Deprecate system_get_info()
Comment #27
andypostre-roll for 10.1
Comment #28
andypostvalid patch
Comment #30
andypostrandom failure
Comment #31
smustgrave commentedCan the issue summary proposed solution be updated please.
Also this appears to just be removing vs deprecating. Any concern with breaking a contrib module?
Comment #32
andypostI think we can add deprecation but it's can be caught with phpstan - something pass more then one argument to function that expects only one)
Comment #33
andypostHere's a patch to narrow down API to expected information only (human readable module name)
It will help of we'll change resulting array to some value object
as it consumes a string and we gonna formalize extension info structure it makes sense to change type to array|string
Comment #34
andypostAnd there's just a few usages in contrib
Comment #36
andypostFix typo
Comment #37
smustgrave commentedIf the issue summary could be updated also please.
@andypost looking at "Use to pass only $info["name"] instead" that doesn't read right to me. What about just "Pass only $info["name"]"
Comment #38
andypostThanks, fixed and added deprecation test
Comment #39
smustgrave commentedThanks!
Comment #40
catchComment #42
andypostRandom failure
Comment #44
andypostComment #46
catchFixed this typo on commit:
Committed/pushed to 10.2.x, thanks!
This is only used in two places in core - AdminController in system module and HelpController in help module. I think we could make it a trait in system module to get it out of .module altogether? Tagging for a follow-up. Since this issue is already eight years old I didn't want to derail it by proposing that for here.
Comment #47
andypostThank you!
Follow-up already exists #3038971: Move system_get_module_admin_tasks() into a service and deprecate it
Comment #50
quietone commentedPublished the CR