Posted by jim0203 on July 10, 2011 at 6:44pm
When a Drupal site is being developed its often the case that modules are installed that don't provide any actual functionality once the site goes live. Is it technically possible to write a module for Drupal 6 and/or Drupal 7 that lists these stray modules? Is such a module desirable?
Comments
.
No idea if it would be possible, but I'd sure love one. :)
Michelle
I'd say its pretty rare that
I'd say its pretty rare that developers add modules without reason. A custom module that automatically goes through all possible scenarios of a module's use on every page may not even capture the business requirements of why said modules is still in place, which can lead to regressions on removal. Why not just go through module list manually and disable or delete what you know 110% don't need?
variants -- ways to know what modules from the last dev are for
I can think of a couple variants for this:
1) a dev/live-throttle, something that shuts off devel, simplemenu if you're using it just for admin, and views-UI [?] when you're done building UIs, etc. to cut down the modules when live.
2) a confused-programmer's system, that tracks function calls and somehow tells you if a module has been used for anything at all in the last 1000 page views, in case the last developer just left everything enabled. Sounds like a technical nightmare.
3) what I think I might actually like... a way to add to / edit the little bit of info on the module page, so when I skim the module page I can see what I'm using a module for if the developer's description wasn't clear, perhaps with toggle buttons (dev/_live _not-sure-if-will-use) to keep track of things that might get left over. ex:
Content Permissions 6.x-2.7 Set field-level permissions for CCK fields. We use this for the mansion cck, only the owner can edit "release the hounds" field. _X might or might not use. _X_dev _X_live
Is one of these close to the use-case you're thinking about?
Check out the Environments
Check out the Environments module that Grayside is working on :)
Please clarify which module and why
@patcon: Which module do you mean?
In any case, how would the module be useful for seeing what modules are truly being used on a site?
Documentation is part of the problem
It's often hard to tell, even after installing, what a module actually DOES. What I mean is, a module may add admin controls... anywhere. Not just in a "Settings > Modulename" pane, but they can modify controls or add functionality in other places as well (or work entirely invisibly with no admin interface at all).
One problem is modules are extremely poor at documenting where they are adding or changing controls in the interface. If I could always have a reference describing everywhere that module added or changed/enhanced a control in admin, I'd be able to say, "oh, it added these controls...which I never use, so let's nuke it." Or "oh, so THIS is the module that adds that really useful functionality!"
That would at least help figure out which modules are providing useful functionality, and which are abandoned experiments.
Good modules will have a
Good modules will have a README.txt and/or a "Read documentation" link on the project page which will make evident how to configure the module. (D7 modules can also add a "Settings" link to the module list page, though this isn't quite intuitive and won't work for some types of modules such as input filters which don't really have an entirely separate page for their settings.)
If you ever encounter a module which looks useful to you but you don't know how to use it, add an issue in its issue queue. Lack of documentation and/or an unintuitive interface is definitely a bug!
The Boise Drupal Guy!
a confused-programmer's
This isn't really all that feasible either; if the module implements hook_boot or hook_init it will always be "used" on every page load even if no other hooks or functions are being executed. Alternatively, if caching is on, hook_menu might or might not get called even though the module's hooks are being used (hook_menu generally only gets called on cache flushes and module admin/enable).
And let's not forget the API-only modules that might not have any initialization hooks, but get loaded and called by other modules as needed...
Short of a well-published hook that could be called to check on how often the module is being used by its estimation (not unlike Windows software admin that tells you if something is used frequently, often, or rarely and the last execution date) you've got no sure-fire way to know if the module is being used in some way.
Cool but impossible
This is a nice idea... it's not uncommon to try out a new module and then forget about it.
But, yeah, like others mentioned, figuring out if it is really "used" is the trick. Some modules don't have much code at all. Some don't have any pages of their own and just have hooks. Some are API modules for other modules, etc.
Kristen
Contact: https://www.hook42.com/contact
Drupal 7 Multilingual Sites: http://www.kristen.org/book