As Drupal caches more and more data internally to improve performance, it becomes more and more difficult for developers and site administrators to flush the contents of those caches when developing modules and themes, or troubleshooting complex configuration issues. (To properly clear the caches, one must truncate five tables then call menu_rebuild(), drupal_rebuild_theme_registry(), drupal_clear_css_cache(), and drupal_clear_js_cache() -- and then one must deal with third-party modules that cache their own data.)

Devel.module has included a general cache clearing function for some time, and a number of modules have begun to support its 'devel_clear_caches' hook to centralize cache flushing. This function should be in core, though: Dries has commented before that it would be an important addition for D6 before release.

The following patch adds just such a function: drupal_flush_caches(). It automatically clears all core cache tables, calls the necessary internal rebuild functions, and exposes hook_flush_caches() so that modules can clear their own internal data or return lists of their own standard cache tables for truncation. In addition, it provides a simple 'Clear all cached data' button on the admin/configure/performance page, along with an explanation of why it might be used.

For all the developers who've made trips to admin/build/modules and admin/build/themes every time they changed some module code, hoping to flush out the menu and theme registries... this patch is for you.

CommentFileSizeAuthor
#18 drupal_flush_cache.patch3.53 KBeaton
#17 drupal_flush_cache_195173-17.patch4.1 KBpwolanin
#13 drupal_flush_cache.patch4.05 KBeaton
#11 drupal-clear-cache-195173-11.patch3.29 KBwebchick
#10 drupal_flush_cache_3.patch3.16 KBJirkaRybka
#9 drupal_flush_cache_2.patch3.08 KBJirkaRybka
#8 drupal-clear-cache-195173-7.patch3.42 KBwebchick
drupal_flush_cache.patch3.33 KBeaton
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

eaton’s picture

eaton CreditAttribution: eaton commented
Priority: Normal » Critical

After some deliberation, I'm setting the priority on this up to critical. D6 includes even more internal caching than previous versions, and a number of the mechanisms (like CSS and JS caching, menu rebuilding, theme registry rebuilding) have no obvious way to reset their data. This is a pretty significant usability issue for any new developers.

If others feel differently, feel free to set the priority back to normal.

profix898’s picture

profix898 CreditAttribution: profix898 commented

@Eaton: Does http://drupal.org/node/141427 look familiar to you? ;)

Huge +1 on the concept, although it introduces a new hook_flush_caches() that late in the cycle. But I'm all for a simple way to wipe all caches and registry at once (be that a button or only the drupal_flush_caches() function). Also the code looks good, but I guess we need some more comments, right?

Edit: Maybe we should rename '$alltables' to '$cache_tables' or sth. to clarify the purpose, but thats nitpicking.

eaton’s picture

eaton CreditAttribution: eaton commented

hook_flush_caches() is a direct mirror of devel_clear_caches() from devel.module, which a number of modules including Views already support. I'm not too concerned about its addition, as there's no need for anyone to implement it if it's not needed.

What comments do you think would be useful? I can add an entry for hook_flush_caches() to the API hooks file, but I'm not sure what else would make sense in common.inc. Any suggestions?

chx’s picture

chx CreditAttribution: chx commented
Status: Needs review » Closed (won't fix)

admin/build/modules resets most important caches, rebuilds the menu. More than that, use devel module, please. (Note to hswong3i: I am fair. I am won't fixing even Eaton's patches if they are not good ideas.)

eaton’s picture

eaton CreditAttribution: eaton commented
Status: Closed (won't fix) » Needs review

admin/build/modules resets most important caches, rebuilds the menu. More than that, use devel module, please. (Note to hswong3i: I am fair. I am won't fixing even Eaton's patches if they are not good ideas.)

admin/build/modules does not flush cache tables, does not flush the theme, and does nothing for third-part modules like Views. admin/build/themes resets the theme registry, but does nothing for menus or cache tables. admin/settings/performance resets the CSS and JS caches but does nothing for the menu, theme, or db caches. And none of these things are documented anywhere. You're just expected to pick them up via osmosis.

It's a baffling experience for first-time developers, and there is NO documentation, anywhere, to suggest that cached data might be the cause of the problem. Even downloading devel.module and using its cache flush link requires knowing what the problem is in the first place. This, at least, puts an explanation for the problem on the performance page.

The concept for this patch was greenlighted by Dries approx. 1-2 weeks ago, but no one rolled it. I was doing some work this weekend and decided it needed to at least get a chance. Given the previous conversations about the issue, I'd at least like to get some feedback from a committer before it's wont-fix'd.

JirkaRybka’s picture

JirkaRybka CreditAttribution: JirkaRybka commented

+1 for this. I already needed to flush caches for non-development reasons, such as changed settings to a contributed filter format not appearing in custom blocks using that format, changed translations to table headers not appearing on Views-customized tables. I also see in the queue, that nearly *every* unclear support request leads to recommendation to flush all caches first, and only then report a bug. Particularly localization might (and might not) need to flush caches in daily workflow, depending on where the changed strings are. Devel module should not be required here IMO.

bertboerland’s picture

bertboerland CreditAttribution: bertboerland commented

subribing.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented
Status: Needs review » Needs work
FileSize
drupal-clear-cache-195173-7.patch3.42 KB

Huge +1 for this. This is a re-roll that fixes a few minor things like $alltables (we don't moosh words together in variable names), added some comments to the flush cache function, and some missing PHPDoc for the submit handler.

Tested and works. If someone could look over my changes and give it one more go, I think this is rtbc.

JirkaRybka’s picture

JirkaRybka CreditAttribution: JirkaRybka commented
Status: Needs work » Needs review
FileSize
drupal_flush_cache_2.patch3.08 KB

I tested the patch - applies cleanly, works well. But I have some nitpicks, so I re-rolled it rather than setting RTBC:

- Variable name $alltables changed to $cache_tables per #2 (also my opinion). Either way needs underscore.

- The new fieldset didn't have a title, in contrast to the rest of that page.

- Tweaked the description a bit, to remove mention of developers (it was visually a collision with devel.module purpose, but I believe this button is aimed elsewhere), added mention of translations (which is great field of use cases, according to my experience - at the very least page cache and block cache are interfering to translations), and called the operation as refreshing once (to give a clue, what it does in final effect, and so comfort less experienced users - I think these users might be afraid to click it, being under impression of deleting some mysterious internal data permanently).

(Also common.inc missed a newline char at the end)

JirkaRybka’s picture

JirkaRybka CreditAttribution: JirkaRybka commented
FileSize
drupal_flush_cache_3.patch3.16 KB

Cross-posted accidentally...

Another re-roll, with comment on system_clear_cache_submit() from #8. $cache_tables name seems to be agreed upon :)

The detailed comments inside drupal_flush_caches() not included here, though. IMO it's overkill, the code is really simple to be understood as is.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented
Status: Needs review » Reviewed & tested by the community
FileSize
drupal-clear-cache-195173-11.patch3.29 KB

Ok, then the only other change in mine was that weird %warning thing in the description of the fieldset. I talked to Heine in #drupal and he said that that text should be included with the parent string for better context, including the <em> tags around it.

Confirmed it still works, so tentatively marking this RTBC since it's had 3 sets of eyes on it.

kbahey’s picture

kbahey CreditAttribution: kbahey commented
Status: Reviewed & tested by the community » Needs review

+1 for this too. This is sorely needed.

Regardless of whether visiting menu clears all, we need a more explicit way that is visible in the user interface.

eaton’s picture

eaton CreditAttribution: eaton commented
FileSize
drupal_flush_cache.patch4.05 KB

Here's a slightly tweaked version of the patch. It adds node_types_rebuild() to the list of tasks performed, and replaces the calls on the admin/build/modules and admin/build/themes pages to use the central function, as per chx's request in irc.

Again -- if it's determined that this is too late in the cycle to go in, I'll accept it. The importance of this functionality had been discussed at several points though, and I wanted to make sure that the OPTION of including it in 6 was at least available.

chx’s picture

chx CreditAttribution: chx commented
Status: Needs review » Reviewed & tested by the community

I missed the bit about Dries supporting this addition. If that's so, what else can I say? Go!

Crell’s picture

Crell CreditAttribution: Crell commented

+1 on concept, but do we need to be wary of the order that cache tables are cleared/rebuilt in? See: http://drupal.org/node/195202 .

I am also wary of a new hook in beta3 state, but will defer to Dries/Gabor on that. It's an important task, whenever it goes in.

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented
Status: Reviewed & tested by the community » Needs work

+1 on concept, but the cache_menu table is missing from the list. cache_update is also missing, but I'm not sure what that's used for.

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented
Status: Needs work » Needs review
FileSize
drupal_flush_cache_195173-17.patch4.1 KB

Ssince this is meant as a debugging tool, the order of clearing should not matter much. However - it probably makes sense to clear the caches after the CSS, JS, etc caches are cleared, and for good measure make sure the page cache is cleared last.

Eaton pointed out to me that the menu_rebuild() clears the menu cache. See also: http://drupal.org/node/170514

after conversation with Crell and Eaton on IRC - omit cache_form, since clearing that may bork form-submissions that are in process. Also rename the function to "drupal_flush_all_caches" so that it does NOT match the patten hook_flush_caches()

eaton’s picture

eaton CreditAttribution: eaton commented
FileSize
drupal_flush_cache.patch3.53 KB

And oooooone more patch. This one puts the module admin page and the theme admin page back to their original behavior of explicitly setting specific caches. This explicit 'full flush' of the cache system isn't something we want to trigger every time we turn around: it's more of a troubleshooting tool and sprinkling it around drupal would have performance repercussions.

So. The patch is now smaller and is back to being a pure UI convenience -- it doesn't impact the behavior of any existing forms or pages.

JirkaRybka’s picture

JirkaRybka CreditAttribution: JirkaRybka commented

I totally agree with #18. Didn't get a chance to test code again here (yet), but otherwise I feel like this is RTBC.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented

This'd be very nice to have, I get fed up enabling and disabling css aggregation when doing minor theming all the time, a one button push to invalidate the cache would be nice without the overhead of running devel. Definitely modules/themes pages shouldn't do a full cache flush, that'd be overkill. so as with JirkaRybka #18 looks good to me for the various reasons stated.

robertDouglass’s picture

robertDouglass CreditAttribution: robertDouglass commented

I have to jump in and say that maintaining advcache and memcache modules will be *much easier* with this patch. The idea is fantastic and I sorely hope this goes in to D6. I can haz cache hook? Plz?

Dries’s picture

Dries CreditAttribution: Dries commented
Status: Needs review » Fixed

I promised in Barcelona to let this feature slip in. Committed to CVS HEAD. Thanks all.

Anonymous’s picture

(not verified) CreditAttribution: commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.