More useful info in statusmodules
naught101 - June 19, 2009 - 07:02
| Project: | Drush |
| Version: | All-Versions-HEAD |
| Component: | Miscellaneous |
| Category: | feature request |
| Priority: | normal |
| Assigned: | naught101 |
| Status: | active |
Description
"Enabled" and "Disabled" doesn't cover all the options for module status. There are three fundamental variables: Exists in filesystem, Installed in database, Enabled in database. It's useful to know all of these (to some extent). Obviously if the module doesn't exist in the filesystem or the DB, it's not relevant, but it would definitely be good to be able to view any modules that are installed, but disabled (ie. module preferences are still in DB), and it would also be good to be able to list modules that are installed and/or enabled, with the files missing.
It would also be good to be able to exclude Core modules somehow. I thought maybe -i sites/all might do it, but it doesn't seem to work.
#1
Hrm, this isn't exactly a fix for the extra info I mentioned, but it adds some info (Project, Name, Version, Status, Dependencies), and removes the relatively useless "description". It also sorts by project.
For some reason, the array passed to pm_module_status() doesn't include the 'status' or 'schema_version' entries, even though module_rebuild_cache() returns them in the array.
If I can figure that out, I would put 'status' in brackets after Enabled/Disabled (it's just a 1 or a zero), and put the 'schema_version' after that in a new column (it's -1 for uninstalled, module db schema version for installed).
Unfortunately, I don't think that will include modules that are installed/enabled whose files are missing.
#2
Ok, got the schema, it was in the parent object. I decided to leave out the "status" digit, as it provides no more information.
This still doesn't deal with installed/enabled modules with missing files, I might see if that can be pulled out with multisite_maintenance code.
#3
version 3 - works, gets all modules names, statuses, and schemas from the db, and adds them to $rows if they aren't in $module_info.
It's a bit ugly, so suggestions for better wording/layout would be good. this format easily allows scripts to
egrep -v "^( Project| drupal| MISSING)"to get data only for non-core modules. Might be better if modules without a project/missing modules were sorted to the bottom, not sure.#4
IMO this goes a bit beyond what we want to do in statusmodules. I agree we could use more info in statsmodules, but not necessarily MISSING info. Not even core drupal provides that.
#5
moshe: what about MISSING as a switch? I agree it's not useful in many situations, but it's very useful for a minority of situations (ie. if you're taking over control of a badly managed site, or if you just madly managed it yourself ;) )
perhaps something like "-a, --listall : include modules that are installed, but missing files"?
#6
Not in core drush. Perhaps try to get drush integration for http://drupal.org/project/enabled_modules
#7
Fair call. #348923: nice simple list of modules for drush_mm and core update
Maybe make this won'tfix?
#8
#9
Now that I think about it, I reckon there's a coupe of things that could still be done with this, even without the MISSING info
Currently, the columns are like this:
Webform (webform) Enabled Enables the creation of forms and questionnaires.At the very least, version info would be useful here. I also think listing the project is a good idea, so that modules can be grouped. Something like this would be a good default:
Project | Module Name (module_name) | Version | Status | DescriptionI'm not sure about dependencies, it could be a bit over the top, but it's also useful for grepping for relationships.
It might also be useful to have a way to turn *off* the description.