| Project: | Drupal core |
| Version: | 7.x-dev |
| Component: | base system |
| Category: | bug report |
| Priority: | normal |
| Assigned: | JoshuaRogers |
| Status: | closed (fixed) |
Issue Summary
The registry really put a hurting on me today. Here are two examples where even experienced Drupal devs would be left head scratching (or pounding).
1. I delete a module. Reasonable enough. In older Drupal versions, it would just go away. Now I get a nasty include error, and I cannot access my site, clearing the cache_registry doesn't help. There is no way to get my site in working order without manually removing entries from the registry table and then doing the cache in. This took me awhile to figure out.
2. I install a module (like the latest devel_themer) and it is broken somehow, site is partially accessible now and I can't actually see my admin/build/modules page to disable it. What are my options? Experienced Drupal devs would change the status from 1 to 0 in the system table, and then get their site back. This doesn't work. It took me awhile to track it down, and no amount of cache clearing helped. I had to manually go into the registry table and delete every reference to that file AND then wack the cache. Even going to update.php didn't help
If we have a cache for registry data, doesn't it make sense that if the cache is truncated, the registry should be rebuild from scratch? Or at the very least we need some kind of "emergency switch" which causes it to do so. I use APC, so I don't really have a problem with loading too many files, I'd even like an option to turn the registry cache off, especially while developing.
I'm not terribly knowledgeable about this code registry, although I see the code and I understand the motivation. To improve DX and reduce the obtuse errors, I would suggest the following:
1. If cache_registry is truncated, it should be rebuilt.
2. Going to admin/build/modules causes the registry to be rebuilt. This ensures that someone can access this page to get this back in order.
3. Going to admin/build/themes (see #2)
4. If I disable a module via the system table, it should cease to exist IMO. I can understand if I delete the module from the disk, that would throw an include error until I go to admin/build/modules because otherwise the benefit of the registry for people not running opcode caches is nullified. But setting the status to 0 should stop the module from loading IMO. Perhaps a trigger? Or a quick check on the timestamp of the last modified entry in system (if > last_registry_rebuild) { rebuild } ?
If I'm totally missing an obvious piece of documentation to make this simpler, please let me know.
Thanks!
Jacob
Comments
#1
See #412808: Handling of missing files and functions inside the registry. We probably need to do a registry_rebuild(), but without a locking framework #251792: Implement a locking framework for long operations, this can break horribly. We *need* something like that, but we couldn't yet agree how it should work.
Well, the cache is rebuilt.. from the outdated registry information ;)
We do that. The problem is that we need to registry before we rebuild it.
chx also had to idea for a separate rebuild script, something like rebuild.php, that you can execute when something goes wrong with the registry, menu, modules, whatever, but I can't find the issue at the moment.
#2
Good stuff.. Thanks for the info.
What about if we just put two low level functions as high up in the stack as they need to be to be before the registry (even index.php if need be).
if ($no_rows in cache_registry) {
//rebuild the registry
}
and/or:
if ($_GET['q'] == 'admin/build/modules') {
//rebuild the registry
}
#3
I have a suggestions: we add a recover.php to the root directory. It basically bootstraps Drupal up until the point of initializing the database. At that point it allows someone who can login with uid #1 to see a copy of the /admin/build/modules page. They can safely disable the module from here.
Also, this would be able to prevent the future of Drupal rootkits. (Some module that form_alters the module page changing #default_value = TRUE to #value = TRUE. Yeah. How do you disable that?)
#4
This patch requires the patch from #541444: Create a mode of running Drupal which does not allow contrib hook invocations.. Since it hasn't been added to core yet, I suspect the testing bot will explode the world. Don't let that stop you from trying it though. In practice it works for me.
#5
There are certain module that rely on you not being able to disable them normally (e.g. paranoia) but if the recovery was jsut for uid 1, that's not a real problem.
#6
The class auto-loading bit of the registry is probably useful enough to keep, but I expect that could be very light weight - probably you don't even need to use the tokenizer, maybe just a regex?
#7
The last submitted patch failed testing.
#8
This was taken care of by
#497118: Remove the registry (for functions)