Posted by naught101 on June 19, 2009 at 7:02am
| Project: | Drush |
| Version: | All-versions-5.x-dev |
| Component: | Miscellaneous |
| Category: | feature request |
| Priority: | normal |
| Assigned: | naught101 |
| Status: | closed (fixed) |
Issue Summary
"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.
Comments
#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: View to show projects and modules in a format for drush
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.
#10
+1 for adding version (the other info would be useful as well). I came to the Drush project page to put in a feature request for adding version to "drush sm" and found this issue.
#11
you get version info with `drush update --no` (--no is new in HEAD. before then, just press 'n'). i think someone has to come up with a more cohesive plan for the various pm commands if they want info to move info around.
#12
The 2 listings are quite different - one is module centric, the other is project centric. Modules always inherit their project version, so technically adding this information is a little redundant - however I can see how it would be useful in some situations.
If we are going to do more work on this I think we should aim for a unified and more flexible listing, so you could (for example) group (& filter?) modules by project, by enabled status, by update statues etc, with some control over columns and sort. Ideally some of this would be generalized into the table function (or a new smarttable function, perhaps?) so the grouping, columns etc would not need dedicated code.
#13
Complete info for a module/theme can be obtained with incoming `pm-info` command. See #679832: pm-info: show info for one or more projects..
note also now `statusmodules` is known as `pm-list` and wants to include themes info and provide filters. See #679020: Extend `pm-list` to list modules, themes and profiles and filter by project status (enabled|disabled|uninstalled...).
other related issue proposes to group modules by package: #654682: drush statusmodule --package: Package column and grouping for the statusmodules list. We are speaking of removing Description column to make room for other info. This also introduces in the listing an asymmetry with themes.
`drush update --no` could be wrapped as `drush pm-status`.
#14
no more to do AFAICT
#15
Awesome, looks good. Thanks.
#16
Automatically closed -- issue fixed for 2 weeks with no activity.