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.
This is spun off #2406685-4: Provide summary report modeled on Update
On that comment, thursday_bw suggested that we add a column to the reports, at least if it's a report of a particular configuration type or system.all, that tells which module/theme/profile the config being reported as missing or different came from.
Let's continue the discussion and patches for this feature request on this issue instead of on that other issue.
Comments
Comment #2
jhodgdonI took a look at what it would take to make this work.
Basically, we would need to duplicate what ExtensionInstallStorage does when it decides where to read config from, given the config name.
What it does is scan all modules, themes, and profiles config/install directory (or config/optional), and makes an internally-stored list of all the files it finds there. See
https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Config!ExtensionI...
Then this list is used when someone calls the getFilePath() method, which is called by the read() method and exists() method... Because this list is indexed by the config item name, it's a simple lookup to find the directory.
We'd need to do something similar. Basically, we could use configLister() to list all the items defined by each module, and then reindex the list so we have a map of config name => provider.
This seems like quite a bit of overhead, but we could do it...
Comment #3
jhodgdonAnd by the way, the patch on #2406685-5: Provide summary report modeled on Update (the issue this was spun off of) basically does exactly that, but only for modules, and also it is done in a way that means the scan is done each time the provider is calculated.
Also as I said on the other issue, I think this functionality should be added to ConfigLister (via a new interface) and not to the report class itself. ConfigLister can then store the mapping locally and reuse it instead of scanning each time.
And we should only have this column if the report is by type, not if the report is by module, theme, or profile (in which case the provider is kind of obvious).
Comment #4
jhodgdonI am going to work on this...
Comment #5
jhodgdonI got this working, along with #2405277: Only list extensions that provide configuration, with a test.