As we all know, block caching is very useful. However, on complex social/web 2.0 sites with a node_access module (like organic groups) block caching is disabled, because core doesn't allow block caching and a node access module running at the same time. While this is a weird architectural issue, I am wondering about best practices to deal with this on a drupal site with many authenticated users and a node_access module.
Take these questions for this situation:
-
Views has got it own 2 caching settings: 1 per-view and (if block) 1 per block. Are both of these 'worthless' in this situation, or is the first (time based) still performed?
-
In this situation, would blockcache_alter do any good? Or is block caching disabled anyway?
And if node_access prevents any block from being cached at all, what are best practices for this type of site at the Drupal level? (I'm not talking about backend accellerators like xcache/apc or memcache). I would really appreciate some in-depth views on these workings, as there is surprisingly little information to be found on these topics.
Comments
Drupal doesn't allow block
Drupal doesn't allow block caching because the block system can't tell who has permission to view the block (The block could be listing some nodes that only some people have access to). But you the site builder know which blocks are safe for caching and which aren't. You can use the Block Cache Alter module to enable block caching and manually set the cache settings for each block. Block Cache Alter also gives you more fine-grained control around cache expiry.
As for Views' cache settings, the per-block cache settings are just the settings for the standard Drupal block cache. Unless you use Block Cache Alter to turn block caching on it will have no effect.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
clarification. only the
clarification. only the og_access module disables block cache. many og sites don't use that part of og.
your bet bet is to implement own caching for expensive blocks. the cache api is really simple. cache_get and cache_set and cache_clear_all()
in d7, we have some more techniques. see render_cache_by_query
Right, so blockcache_alter
Right, so blockcache_alter sounds pretty good in this case.
I'm curious what extra options/performance I could get by implementing my own caching through the API, in comparison to blockcache_alter, will look into that, thanks!
Implementing your own caching
Implementing your own caching through the API will not gain you anything in performance. All (almost) Drupal cache activity happens through those three cache functions regardless of what is being cached or what is doing the caching. Using your own custom code will get the cache logic out of the UI which can be a good idea - no need for someone to alter the expiry logic with good intentions but have it increase the load on the site. But on the other hand it's a lot quicker to setup a small module than to write your own custom caching code.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
blockcache_alter seems to
blockcache_alter seems to work well, but it doens't work so well with quicktabs blocks
Canadaka.net
With blockcache_alter in D6,
With blockcache_alter in D6, I believe if any node access module is enabled, you also need to apply the included core patch, blockcache_alter_no_node_grants.patch, to enabled block caching. And then each block cache setting should be configured as appropriate.
--
http://ball.in.th - ชุมชนคอบอลพันธ์แท้, ผลบอล
Just adding the link to the
Just adding the link to the blockcache_alter module http://drupal.org/project/blockcache_alter