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

Reference: https://www.drupal.org/core/beta-changes
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

Comments

stefan.r’s picture

Issue tags: +Novice
stefan.r’s picture

Issue summary: View changes
effulgentsia’s picture

Status: Postponed » Active

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

stefan.r’s picture

Title: Deprecate/remove system_get_module_admin_tasks » Remove info argument from system_get_module_admin_tasks
Issue summary: View changes
Status: Active » Needs review
StatusFileSize
new2.63 KB

Yes that sounds like a step in the right direction :)

Status: Needs review » Needs work

The last submitted patch, 4: 2466933-1.patch, failed testing.

Status: Needs work » Needs review

stefan.r queued 4: 2466933-1.patch for re-testing.

effulgentsia’s picture

Status: Needs review » Reviewed & tested by the community

Awesome. Thanks.

xjm’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs beta evaluation

Is the idea that system_get_info() calls add performance overhead? Can we add a beta evaluation please since this is a normal task?

stefan.r’s picture

Issue summary: View changes
Status: Needs work » Needs review
Issue tags: -Needs beta evaluation

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

piyuesh23’s picture

Issue tags: -Novice

As per last comment from @stefan.r, looks like this issue needs a decision before work.

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.

I am removing the novice tag, since it no longer follows the pointers on https://www.drupal.org/core-mentoring/novice-tasks.

xjm’s picture

Title: Remove info argument from system_get_module_admin_tasks » Deprecate info argument from system_get_module_admin_tasks()
Version: 8.0.x-dev » 8.1.x-dev
Status: Needs review » Needs work

Agreed, 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.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.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.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.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.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.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.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.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.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.

almaudoh’s picture

Now 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()

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.

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.

andypost’s picture

Status: Needs work » Needs review
Related issues: +#2926070: Deprecate ModuleHandlerInterface::getName()
StatusFileSize
new0 bytes

re-roll for 10.1

andypost’s picture

StatusFileSize
new3.56 KB

valid patch

Status: Needs review » Needs work

The last submitted patch, 28: 2466933-27.patch, failed testing. View results

andypost’s picture

Status: Needs work » Needs review

random failure

smustgrave’s picture

Status: Needs review » Needs work
Issue tags: +Needs Review Queue Initiative, +Needs issue summary update

Can the issue summary proposed solution be updated please.

Also this appears to just be removing vs deprecating. Any concern with breaking a contrib module?

andypost’s picture

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

andypost’s picture

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

+++ b/core/modules/system/system.module
@@ -972,14 +972,11 @@ function system_admin_compact_mode() {
-function system_get_module_admin_tasks($module, array $info) {
+function system_get_module_admin_tasks($module) {

@@ -1026,7 +1023,7 @@ function system_get_module_admin_tasks($module, array $info) {
-        'title' => t('Configure @module permissions', ['@module' => $info['name']]),
+        'title' => t('Configure @module permissions', ['@module' => \Drupal::service('extension.list.module')->getName($module)]),

as it consumes a string and we gonna formalize extension info structure it makes sense to change type to array|string

andypost’s picture

And there's just a few usages in contrib

Status: Needs review » Needs work

The last submitted patch, 33: 2466933-33.patch, failed testing. View results

andypost’s picture

Status: Needs work » Needs review
StatusFileSize
new837 bytes
new4.64 KB

Fix typo

smustgrave’s picture

Status: Needs review » Needs work

If 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"]"

andypost’s picture

Status: Needs work » Needs review
StatusFileSize
new2.56 KB
new5.89 KB

Thanks, fixed and added deprecation test

smustgrave’s picture

Status: Needs review » Reviewed & tested by the community

Thanks!

catch’s picture

Title: Deprecate info argument from system_get_module_admin_tasks() » Change $info array argument to system_get_module_admin_tasks() to $name

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 38: 2466933-38.patch, failed testing. View results

andypost’s picture

Status: Needs work » Reviewed & tested by the community

Random failure

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 38: 2466933-38.patch, failed testing. View results

andypost’s picture

Status: Needs work » Reviewed & tested by the community

  • catch committed 42461a87 on 11.x
    Issue #2466933 by andypost, smustgrave, xjm, effulgentsia: Change $info...
catch’s picture

Version: 10.1.x-dev » 11.x-dev
Status: Reviewed & tested by the community » Fixed
Issue tags: +Needs followup

Fixed this typo on commit:

diff --git a/core/modules/system/system.module b/core/modules/system/system.module
index 5f79fca5b8..9a0926a9a9 100644
--- a/core/modules/system/system.module
+++ b/core/modules/system/system.module
@@ -983,7 +983,7 @@ function system_admin_compact_mode() {
  */
 function system_get_module_admin_tasks($module, string|array $module_name) {
   if (!is_string($module_name)) {
-    @trigger_error('Calling ' . __FUNCTION__ . '() with $module_name argument as array is deprecated in drupal:10.2.0 and is required to be staring from drupal:11.0.0. Pass only $info["name"] instead. See https://www.drupal.org/node/3357711', E_USER_DEPRECATED);
+    @trigger_error('Calling ' . __FUNCTION__ . '() with $module_name argument as array is deprecated in drupal:10.2.0 and is required to be string from drupal:11.0.0. Pass only $info["name"] instead. See https://www.drupal.org/node/3357711', E_USER_DEPRECATED);
     $module_name = $module_name['name'];
   }
 

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.

andypost’s picture

  • catch committed 0ef5b7f9 on 11.x
    Issue #2466933 by andypost, smustgrave, xjm, effulgentsia: Change $info...

Status: Fixed » Closed (fixed)

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

quietone’s picture

Published the CR