Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
Since not all extensions provide configuration, it would be useful to filter the module, theme, and install profile links to reports to show only those that do.
Proposed resolution
Remaining tasks
User interface changes
API changes
Comment | File | Size | Author |
---|---|---|---|
#13 | only_list_extensions-2405277-13.patch | 5.86 KB | mglaman |
| |||
#5 | only_list_extensions-2405277-5.patch | 857 bytes | mglaman |
#5 | Screen Shot 2016-02-29 at 12.52.53 PM.png | 37.78 KB | mglaman |
Comments
Comment #1
jhodgdonHm. That would make the calculation of the "chose what to report on" list more expensive. I am not sure it is worth the trouble.
Comment #2
jhodgdonComment #3
jhodgdonComment #4
jhodgdonComment #5
mglamanBased on #2678130: Make ::listProvidedItems public, simplify loading a module's config, here is a patch that cuts down the amount of items. Makes it a lot easier to use, in my opinion.
Comment #6
jhodgdonHow's the page load time?
Comment #7
mglamanLocally I did not notice any difference
Comment #8
jhodgdonHm. Well this would need to be applied to the themes and the profile too. Also this patch doesn't consider cases where there are config/optional items but not config/install items, as it is passing in TRUE for listProvidedItems() last argument.
So, it seems like it requires doing quite a few file system scans -- at least twice what this patch does. And I would think that it would slow down the page load quite a bit, at least on some systems, which is why I was concerned about doing it in the first place.
There should be a more efficient way to do this that doesn't require the entire overhead of listProvidedItems(), because really we just want to know "is there anything at all" not "find me the entire list".
Comment #9
mglamanHm. I wonder if we should populate a cache on hook_rebuild that knows of all the modules that provide config. Given the discussion in #2678130: Make ::listProvidedItems public, simplify loading a module's config and comment #8, I'll try to find a viable solution.
It seems like this would be a big user experience win, especially for site builders, if this module becomes a de-facto solution for the contrib upgrade realm.
Comment #10
jhodgdonAs I noted on the other issue, you should absolutely NOT rely on Config Update to make required updates to your modules' config. You should instead make a hook_update_N() that updates config, just like you'd need to do that if your module requires some database changes.
See
https://www.drupal.org/node/2535316
Config Update is not a substitute for hook_update_N().
Comment #11
mglamanyes, hook_update_N() will be used. However if people need to review progressive enhancements delivered by a module, that might be overridden by their site's config this screen is useful.
Comment #12
jhodgdonYes definitely. I'm not saying config_update is not useful. Obviously, I think it's useful or I wouldn't have made it. :)
Comment #13
mglamanOk, here is another shot. This reuses the extension services provided by the module to support config/install and config/optional. It gathers the combined extensions (modules and themes) and gets all available components they provide. This only happens once. When cycling through the currently enabled modules and themes, we check to see if
InstallStorage::CONFIG_INSTALL_DIRECTORY
orInstallStorage::CONFIG_OPTIONAL_DIRECTORY
are in the array of extension storage components.If an extension is not in the array, we continue. In my tests the biggest overhead is the front end rendering of the page (toolbar, dropbuttons.)
Comment #14
jhodgdonNitpick:
You've declared extensionConfigStorage and extensionOptionalStorage to be of type StorageInterface. But this interface doesn't have a getComponentNames method. You need to declare them to be of type ExtensionInstallStorage or something like that.
Other than that, this seems like it would work. But I don't see why this complicated and a bit convoluted array_flip() etc. code would be any more efficient than just using the ConfigLister service from this module, calling its listConfig() method at each step in the module/theme loops, and verifying that either the config/install or config/optional list has something in it. I think that the same directory scans will be done, and it's somewhat clearer code (at least I think so). ???
Also this would need a test before I would add it to the module. I think the test could use some Core modules/themes that currently have just config/install, just config/optional, or neither, and verify that the first two are shown and the third type isn't. Or to be more future-proof, I guess we could make some test modules and themes with these characteristics.
Comment #15
jhodgdonComment #16
jhodgdonI'm working on this along with #2824164: Add name of module/theme/profile to report, because they need basically the same underlying code.
Comment #18
jhodgdonI got this working, with a test, along with #2824164: Add name of module/theme/profile to report.