CCK Blocks appears to be incompatible with block caching

Changing this to a support request. I've been trying to replicate this behavior on an unrelated dev site, and it's not co-operating. Also, the other main admin user reporting that it doesn't happen for him. (I've documented it happening for me with User 2 and with an anonymous user in a different browser. It's definitely real.)

I'll come back with more later. Thinking this might be something to do with session state. I need a more comprehensive test plan to flush that out.

After more testing, I've determined that the problem goes away on this site if block caching is disabled.

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

I'm reopening this as a bug, as I have the same problem. Deactivating other features is not the way, I expect problems to be solved. I suggested the following solution at #425186: upgrading to CCK 6.x-2.2 causes CCK blocks to disappear.:

Add the following line to the blocks, created by this module:

define('BLOCK_NO_CACHE', -1);

I created a patch an uploaded the modified file (for those who don't want use the patch system).

I didn't test this modification, so please try this only on a non-productive website.

Regards,
forschi

I have similar problem, using CCK Blocks 6.x-1.1 and CCK 6.x-2.1 with Drupal 6.9.
I display image field of a node on the sidebar with CCK Blocks.
when Admin is logged in - it seems to be working fine for him.
for other users it works once, and thenafter the same block is displayed even if the user is viewing a different node!
the only way i've managed now to fix it, after reading through the forum, is by disabling the block cach, which is not optimal...

looking forward for a fix

I'm having this exact problem. Any update?

Try this module: http://drupalmodules.com/module/block-cache-alter
Now you have to set Per page caching for each CCK block. It works well for me.

Yes, provoking bug

Subscribing

same bug here. subscribing....
as workaround block-cache-alter works fine.

Here's a patch for the HEAD branch.
Run update.php after applying for the cache setting to become effective on existing CCK blocks.

Committed to DRUPAL-6--1 branch.

Note that this patch takes a "safe" approach by disabling the cache for all CCK blocks, guaranteeing consistent results.

Therefore, using Block Cache Alter is still useful in the sense that you could enable the cache for blocks that you know are okay to be cached.

Correct me if I'm wrong, but doesn't disabling caching on CCK blocks essentially negate the benefit of node caching? Isn't the point of node caching to reduce the number of queries -- and if D has to query for the CCK fields on a node, isn't it making the same number of queries for that page?

I don't know that much about D's cahcing mechanisms. What you stated, sounds correct. But I'd prefer to have a block visible and getting my page a bit slower than having blocks, disappearing randomly.

If you have any suggestions, how to solve our problem without disabling block caching, please let us know.

Btw, it is still possible to activate block caching via the Block Cache Alter Module (see #12).

Note also that the patch has absolutely no impact on page caching. There are many caches in Drupal and this change only disables block caching on blocks provided by the CCK Blocks module.

Earl & David, just trying to understand what this does and doesn't do. For most sites I work on, it's better to have the block; but if the site has moderate to heavy traffic, and assuming that file-based caching isn't an option, it seems to me better to redesign to avoid using a CCK block.

@escoles: Use the aforementioned Block Cache Alter module to enable the caching policy that's most suitable for your CCK blocks (and for any other module's blocks, for that matter).

Hey escoles,

I have no experience with caching, but I just started familiarize with that topic. If you know things about caching that might help me understanding that topic, I'd appreciate it, if you share that information with me.

I understand your concern about the caching topic and I'd love to solve that problem, as I don't wanna have a module with bad performance.

You are the creator of this topic, so I think, you can follow what changed with our new version. Unfortunately, we do not have any response if our solution works and all blocks appear as they are supposed to. Could you please check that on a page with no heavy traffic?

My first idea about that topic is, that node caching covers the data, we are displaying in our block. We do not query the database when displaying the block, but only requesting the data from the node module. So we do not bypass the node cache!

The second idea is about block caching itself. As far as I remember, we didn't set anything for block cahcing in the past. The documentation of block caching tells us, that in this case, the default caching pattern is BLOCK_CACHE_PER_ROLE. Interesting about that option is, what can be found in the code of the block module, but not in the documentation: "Note that user 1 is excluded from block caching". That explains, why you couldn't reproduce this issue with the admin user. I found another pattern, named BLOCK_CACHE_PER_PAGE. The explanation for that pattern sounds, like it covers our interests better, than the BLOCK_NO_CACHE option.

Can you do some performance testing on that on a non productive site? I release a new -dev version with the caching pattern changed to BLOCK_CACHE_PER_PAGE, so you and others can compare that option to the currently released beta1.

Obviously, a block will render faster if it has been cached (through BLOCK_CACHE_PER_PAGE or whatever policy). However, there is no way to we can get back to caching, as that will cause the initial problem to creep back as there are all kinds of fields. For example, the block might contain a view field that won't display new nodes if the block has been cached. Or it may contain a computed field that needs to be updated on each page load. If one finds that block performance is insufficient, then the way to go is to choose the most proper caching policy with the Block Cache Alter module. Knowing how a field is used and how critical it is for that field to show current data, a site admin can choose the right policy.

My suggestion is to simply document this in CCK Block's README, put back BLOCK_NO_CACHE in -dev, and close the discussion. :)

Could you let the user set the caching policy on a per-block basis? You could set all CCK blocks to BLOCK_NO_CACHE by default but let users change it on the "configure block" screen and just put a note there about the implications.

David, thanks for that explanation. As you requested, I did the rollback and close this issue.

If anyone experiences performance issues, that cannot be solved with the block cache alter module, please open a new issue. It doesn't make sense to me at the moment to re-implement, what's already done in this module. Actually, it's much more dangerous to deliver old or wrong information than delivering the correct information with a delay. Everyone who doesn't agree with that can freely change the cache settings for each block.

Could you let the user set the caching policy on a per-block basis? You could set all CCK blocks to BLOCK_NO_CACHE by default but let users change it on the "configure block" screen and just put a note there about the implications.

In case anyone else is as blind as I apparently am, this is precisely what Block Cache Alter module does. [palm to forehead] Thanks zakjan, David Lesieur, and Earl Grey! :P