[support] Was Sub-theme now Emptying cache.

Jamie Holly hovercrafter at earthlink.net
Sat Oct 12 00:48:22 UTC 2013


Doing a cache rebuild on each save has actually been discussed before, 
but there's a huge problem here. That means every page load all your 
directories need scanned, the file mtime pulled and that compared to a 
previous mtime. You got a site with a lot of bigger modules and the 
performance impact could end up being more severe than no cache at all. 
There is work to get something similar in Drupal 8 for javascript and 
css aggregation only. That issue is here:

https://drupal.org/node/678292

About the only viable option would be for Drupal to add a setting to 
clear certain cache items on each page. The reason for certain items is 
that it depends on what is being developed. 99% of the time theme 
developers just need to rebuild the theme and theme registry, while 
module builders also need to rebuild tons of other things, such as 
menus, hook registry, module.info, etc. That's why a tool like admin 
menu is so awesome. You can clear all the caches, or select what you 
want to clear right from the toolbar.

When I'm working on a big theme I usually end up putting this at the top 
of my template.php file:

system_rebuild_theme_data();
drupal_theme_rebuild();

That clears what I need on every page load until I get the theme done. 
Then I just comment them out (and don't forget to do that before going 
live. My scattered mine has been down that road before!).  A lot of the 
bigger themes even have options to clear the cache on every page load. 
Zen is a good example that has this.

Honestly this is one of those things where there isn't a "one size fits 
all", so it's best just left up to the end user. One thing to keep in 
mind is that a vast majority of the Drupal installs out there never see 
any kind of customization. People install Drupal through a control panel 
script, like Fantastico, that their hosting provider supplies and that's 
it. Honestly things like I mentioned above would be good candidates as 
new features for the devel module.

(** One note of watching for file changes. I have actually been playing 
with a NodeJS script that does just that. It watches the directories I 
set for file updates and can trigger an action, such as drush cc all via 
the shell. Since NodeJS runs persistent and has greater access to OS 
tools, like inotify on Linux, the tool is ideal for it. Of course that 
means having NodeJS run on your development machine.)

Jamie Holly
http://hollyit.net

On 10/11/2013 8:07 PM, Roger wrote:
> > The caching is all tied to performance.
> > Without it Drupal becomes a huge anchor.
> Jamie thank you for an excellent description.
>
> You raise an interesting point.
> Wouldn't you agree that, as this is a well documented flaw during
> development, Drupal could  better handle cache instead of passing it off
> to the developer who in my experience, doesn't need caching until final
> testing.
> Surely it could be a simple core process to empty cache on each save, an
> automated housekeeping matter?
> Roger



More information about the support mailing list