[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