Spin-off from #1081266: Avoid re-scanning module directory when a filename or a module is missing:
$result = db_query("SELECT name, filename FROM {system} WHERE type = 'module' AND status = 1 ORDER BY filename")->fetchAllKeyed();
foreach ($result as $module => $filename) {
if (file_exists($filename)) {
unset($result[$module]);
}
}
if (!empty($result)) {
db_update('system')
->fields(array('status' => 0))
->condition('type', 'module')
->condition('name', array_keys($result), 'IN')
->execute();
drupal_flush_all_caches();
}
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | callgraph_after.png | 1.66 MB | marcoka |
| #7 | callgraph_before.png | 970.99 KB | marcoka |
Comments
Comment #1
mfbIt might be useful to be able to list missing modules and optionally disable them. But I'd say this shouldn't happen automatically. Site admins should be able to temporarily or accidentally remove a module and still have it enabled after they restore it.
Comment #2
damien tournoud commentedComment #3
sunYuck. Better title.
Also, the code in the OP is an example snippet for how this could be done. Not existing code.
Comment #4
rocketeerbkw commentedRan into this issue that resulted in a performance nightmare, love to see this happen.
My idea is to add this to the status report, and from there you can opt-in to disabling the modules. The check for this condition should not happen all the time, maybe when viewing modules list or the status report itself?
Is this a good approach?
Comment #5
MixologicI'd like to chime in for *NOT* automatically disabling modules if they dont exist, but instead providing a warning for missing modules.
Sometimes I develop locally, and throw in a developer module or two (like diff when doing features development) - these modules dont need to be in version control, as Im only really using them for dev purposes. If Im working with another developer, and for whatever reason the best way to sync up is check out the latest and pass over a database dump, if they do not have the modules, they will be disabled, then when I get the db dump *back* from the other dev, I would have to enable all of these all over again. (Sounds like a clunky workflow, except we're on opposite sides of the globe, and thus can work opposite schedules). So.. it would be great to provide info on whats 'enabled' but missing.
An additional useful feature could be that it also lets us know what's *moved* in the system. Sometimes I realize that a module ought to live in sites/sitename.com instead of sites/all or sites/default. It used to break things pretty bad in D6 when I moved a module that was enabled. - havent tried this with D7 yet.
Comment #6
donquixote commentedI also vote for *NOT* automatically disabling anything.
I can already see this cause a lot more problems than it solves, and a lot of noise on the issue queue.
Typical situation:
On a dev site, someone switches to a different git branch, where the respective module is missing. Cron or some random page visit -> module X disabled.
Or, someone is messing around with file permissions. Bam, all modules disabled.
And also, as mentioned in #5, db dumps being copied around to different sites.
Imo, a temporary WSOD is preferable to a remaining "module disabled" effect.
Show a warning, write something to watchdog, etc. But don't do any sticky changes.
----------
The performance problem with drupal_system_listing() being called multiple times is a different story, to be discussed elsewhere.
-----
We also should think of something to happen if a module changes its filesystem location.
Should we update the database immediately? Or provide an administration page where this can be requested manually?
Think of different module versions in different locations.
I would prefer if the admin has to do this manually - even at the cost of a wsod.
Comment #7
marcoka commentedi run the function on my site after i saw a huge problem with is_dir in xhprof. the load time is now 50% less than before.
i added both complete xhprof callgraphs if someone is interested in that.
Comment #8
donquixote commentedThis sounds related to "enable new dependencies introduced with new module versions".
Each of this would be a nice candidate for a Drush command. Or they could even be combined into one.
There is something in my sandbox, maybe we could add to it.
What I have already is a
drush drux-enable-dependencies.
This command could be enhanced, so
1. it checks whether the already enabled modules are actually present in the codebase.
2. it checks whether they have been relocated (which can be resolved with drush cc all, i guess)
3. for each missing module, you can either attempt to download it. Or you just cancel, and then you can disable those things one by one with "drush dis".
That's not so much to add to the existing drux command in my sandbox.
Comment #9
jhedstromModules can no longer be disabled in 8.x. Bumping this back to 7.x. #1081266: Avoid re-scanning module directory when a filename or a module is missing has been committed to 8.0.x, and is back in the 7.x queue as well.