This week I've finally found the core of several issues that I've had in the past. Are you using install-profiles or features? Then this bug is likely to have affected you too.
What is this all about?
The bug I am talking about is #1891356: Reset drupal static caches when a module is enabled or disabled. and was originally reported in January 2013 as a feature request.
When enabling a module drupal-core resets only some static caches (drupal_static()
). Most of the caches - and all of those used in contrib - are not flushed. So in the same request after enabling a module, there might be some stale caches around. If you're using drush to enable modules or to install an installation profile all modules are enabled in a single "request". That means the caches are kept until the last module is enabled.
For the bug to show it usually needs at least two modules to be enabled in a single request. The first module asks for some information - initializing the cache. The second one tries to use the same information and gets the data from the stale cache thereby triggering an error / misbehavior. The problem that is actually triggered varies. That makes it particularly hard to track down.
I am a maintainer - is my module affected?
- Are you using features or ctools exports? -> your module is likely to be affected.
- Does your module implement
hook_install()
orhook_enable()
? Are you using some other module's functions in those implementations? -> your module is likely to be affected
If you can answer all those questions with no - you're probably ok.
Are there workarounds?
The best solution for site-builders is to simply include the patch into their builds. This immediately removes all issues caused by the stale cache.
Depending on when during module_enable() the possibly stale cache is needed, there are workarounds. I'd recommend against randomly spawning cache-flushes all over contrib though and instead point users to the bug-report in the issue queue. If there is already some bug-report in the issue queue mark it as a duplicate of this issue.
How old is this bug?
I've seen the bug the first time at latest in March 2013, when developing pgbar. At least since then it's using _field_info_collate_types(TRUE)
to refresh the stale field-type cache in pgbar_install()
. In August 2014 - when working at #1681414: Enabling i18n modules fail in install profile I've finally begun to realize that this is actually a core issue: Why does a module that only implements a hook (and doesn't do any caching itself) need to take care of clearing the cache?
But this is not the first instance of this workaround. The oldest one, that I could find is in og-7.x-1.x dating back to November 2011.
The bug is probably as old as drupal_static()
itself. Although I guess it was wanted behavior at some point.
Comments
Thanks for sharing. A lot of
Thanks for sharing. A lot of time has been wasted on building workarounds for this.
Thanks for sharing.
Thanks for sharing.
Question:
I'm a bit confused. Is #1891356 issue D8 related or it's also D7 related?
D7 & D8
This issue is present in both D7 and D8. Due to Drupal's current release policy any fix has to go into D8 first. So it will take a while before we see any fix in D7.
Pages