Comments

webdrips’s picture

Issue summary: View changes
webdrips’s picture

Issue summary: View changes
webdrips’s picture

Issue summary: View changes
Kristen Pol’s picture

Might be good to change the architecture to be more pluggable so that others could add checks as well to their own modules if they wanted to. Either OO/plugins or a hook. For the latter, if my module is coolstuff and it implements coolstuff_module_in_use (returning true/false), then the module_in_use module checks if the function is there and calls it if so.

Even if this isn't done, it might be good to at least pull out the module-specific checks into their own files, e.g. modules_in_use.blog.inc, etc. and pull these in programmatically so that if the file does exist then it knows to check that module. That way someone could contribute a new include file for a specific module without having to update the admin.inc file and it would be more obvious which modules are checked.

Also, I wonder if there are some more generic ways to check if modules might be in use. For example, say it's the context module, and the database is checked for any db tables with 'context' in their names and then check the size of the tables. This obviously won't work for modules that don't have their own db tables or they added something and then disabled it but it might be a good metric to add. Similarly, all variables with 'context' in them could be shown.

I wonder if any of this is already in site audit, architecture, or similar modules. I know that you can analyze modules that have been disabled but not uninstalled properly and variables that haven't been deleted. I don't remember any module that checks if enabled modules might be good candidates to be disabled though.

apaderno’s picture

Assigned: webdrips » Unassigned