Only list extensions that provide configuration

Hm. That would make the calculation of the "chose what to report on" list more expensive. I am not sure it is worth the trouble.

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

How's the page load time?

Locally I did not notice any difference

Hm. 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".

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

As 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().

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

Yes definitely. I'm not saying config_update is not useful. Obviously, I think it's useful or I wouldn't have made it. :)

Ok, 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 or InstallStorage::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.)

Nitpick:

+++ b/config_update_ui/src/Controller/ConfigUpdateController.php
@@ -270,12 +294,32 @@ class ConfigUpdateController extends ControllerBase {
+      $this->extensionConfigStorage->getComponentNames($combined_extensions),

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.

I'm working on this along with #2824164: Add name of module/theme/profile to report, because they need basically the same underlying code.

I got this working, with a test, along with #2824164: Add name of module/theme/profile to report.