I have created a custom block using:

  if ($op == 'list') {
    $blocks[0]['info'] = t('My custom block');
    $blocks[0]['cache'] = BLOCK_NO_CACHE;
    return $blocks;
  }

With block cache on this block is cached. This option does not do what it says it should do.
After testing this block for quite some time, the first thing I noticed was that the entries in the block table for cache remain at a value of '1' when they should be '-1'. I changed these through phpmyadmin. Once I changed them I ran a debug on the _block_get_cache_id() function in block-module to test for the value of $block->cache. The interesting thing was that on a page with My custom block ALL blocks reported a $block->cache of '-1' even thought most are set to '1'. The debug is as below:

function _block_get_cache_id($block) {
  global $theme, $base_root, $user;

  // User 1 being out of the regular 'roles define permissions' schema,
  // it brings too many chances of having unwanted output get in the cache
  // and later be served to other users. We therefore exclude user 1 from
  // block caching.
  drupal_set_message('block '.$block->module.'-'.$block->delta. ' cache '.$block->cache);
  if (variable_get('block_cache', 0) && $block->cache != BLOCK_NO_CACHE && $user->uid != 1) {
    $cid_parts = array();

it appears that the value for BLOCK_NO_CACHE is not saving to the database and that the value used to test whether or not to cache is somewhat buggy.

Comments

sleamey’s picture

sleamey CreditAttribution: sleamey commented

I confirm that's still not working in 6.19.
And the weirdest thing is that blocks with even $delta are always cached and blocks with odd delta are not!

so, this code:

switch ($op) {
		case 'list':
			$blocks[0]['info']='block0';
			$blocks[0]['cache']=BLOCK_CACHE_PER_ROLE;
			$blocks[1]['info']='block1';
			$blocks[1]['cache']=BLOCK_CACHE_PER_ROLE;
			$blocks[2]['info']='block2';
			$blocks[2]['cache']=BLOCK_CACHE_PER_ROLE;
			$blocks[3]['info']='block3';
			$blocks[3]['cache']=BLOCK_CACHE_PER_ROLE;
			$blocks[4]['info']='block4';
			$blocks[4]['cache']=BLOCK_CACHE_PER_ROLE;
			
			return $blocks;

...and that 

switch ($op) {
		case 'list':
			$blocks[0]['info']='block0';
			$blocks[0]['cache']=BLOCK_NO_CACHE;
			$blocks[1]['info']='block1';
			$blocks[1]['cache']=BLOCK_NO_CACHE;
			$blocks[2]['info']='block2';
			$blocks[2]['cache']=BLOCK_NO_CACHE;
			$blocks[3]['info']='block3';
			$blocks[3]['cache']=BLOCK_NO_CACHE;
			$blocks[4]['info']='block4';
			$blocks[4]['cache']=BLOCK_NO_CACHE;
			
			return $blocks;

...give the same results: blocks 0, 2 and 4 are cached and 1 and 3 are not.

And one more thing: this seems to happen not only with anonymous, but any user except superuser (for which blocks are never cached)

kari.nies’s picture

kari.nies CreditAttribution: kari.nies commented

Subscribing to this issue. I also thought this problem was only with anonymous users and am dismayed to hear that it is a problem for an non-admin users. Looking for a patch or a work-around....

-- Kari

sleamey’s picture

sleamey CreditAttribution: sleamey commented

The problem is obviously not related to user roles 'cause there is something wrong with registering blocks/updating block info for all blocks created using hook_block. Maybe we should rename this issue?

Kari, as a workaround you can manually correct 'cache' field in the 'blocks' table for a problem block.

kari.nies’s picture

kari.nies CreditAttribution: kari.nies commented

Hi Sleamey,

Thanks for the suggestion. I edited my mysql table block entry so that the cache on my block has a value of -1. Now I am getting no cache for registered users, but anonymous users are still caching.

I'd like for it to never cache for any user. Is -1 not the correct setting for that?

Thanks for your help,
-- Kari

Amarjit’s picture

Amarjit CreditAttribution: Amarjit commented

Subscribed.

vurt’s picture

vurt CreditAttribution: vurt commented

I can confirm the bug. It shows only with anonymous users.

@Kari: -1 is the correct setting.

vurt’s picture

vurt CreditAttribution: vurt commented

I feel so stupid... In my case it was the page cache which caches all pages for anonymous users (even if there is a block with BLOCK_NO_CACHE set). So false alarm here.

Anyway, I discovered that you can use the module cache_exclude to prevent selected pages from being cached.

sleamey’s picture

sleamey CreditAttribution: sleamey commented

It seems I've figured it out.
Looks like Drupal doesn't update block cache settings (even on registry rebuild or whatever), but only sets them when the the block is created.

dddave’s picture

dddave CreditAttribution: dddave commented
Version: 6.12 » 6.19
Category: bug » support
Status: Active » Fixed

per #8

NewZeal’s picture

NewZeal CreditAttribution: NewZeal commented

fixed!!?? yeah right.

dddave’s picture

dddave CreditAttribution: dddave commented

If not feel free to reopen.

ransomweaver’s picture

ransomweaver CreditAttribution: ransomweaver commented
Category: support » bug
Status: Fixed » Active

I have views blocks set to nocache in the views UI, and -1 in the blocks table, but they are caching for anonymous users.

interestingaftermath’s picture

interestingaftermath CreditAttribution: interestingaftermath commented

subscribing

ebeyrent’s picture

ebeyrent CreditAttribution: ebeyrent commented

This is problematic because if you have the same block on every page, and it's set to not cache, but you have page caching enabled, you're out of luck unless you disable page caching. I think we can all agree that disabling the page caching isn't a great idea.

Any thoughts?

hey_germano’s picture

hey_germano
she/her
Primary language English
Location Minneapolis, MN, USA
CreditAttribution: hey_germano commented

Subscribing

aharown07’s picture

aharown07 CreditAttribution: aharown07 commented

Are there any modules out there for tuning the cache with more granularity or making anon. behave differently? Haven't found any yet myself.

donkapone’s picture

donkapone CreditAttribution: donkapone commented

No solution yet?

ransomweaver’s picture

ransomweaver CreditAttribution: ransomweaver commented

I suggest http://drupal.org/project/ajaxify_regions. This allows the page to be cached as normal, but the specific dynamic block to load with ajax. I'm using it with a views-based random background image.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

subscribing

robbertnl’s picture

robbertnl CreditAttribution: robbertnl commented
Version: 6.19 » 6.22

Subscribing and confirming this bug still exists in 6.22.
Did somebody found a solution?

mdupont’s picture

mdupont
Primary language French
Location Switzerland
CreditAttribution: mdupont commented
Status: Active » Closed (works as designed)

It works as designed. Blocks with BLOCK_NO_CACHE won't be cached at the block level, but if the page cache is activated, block output will be cached along with the entire content of the page, which makes sense.

If you need different block cache settings, see http://drupal.org/project/blockcache_alter and if you need more granular caching investigate contributed modules like http://drupal.org/project/ajaxblocks