I noticed on D6 that once a given block was set to a given cache value, you couldn't change it at all without hacking the blocks table. This change adds a select list of possible cache values that the admin can select from, and writes them to the blocks table. Since updating a block runs cache_clear_all() by default, that means that the next time someone views that block it will be properly re-cached under the new cache value.

First patch for core - be gentle!

While I was working on this, I discovered a problem with simpletest not accepting empty select controls in forms, so I'm about to submit that as a bug. This ticket depends on that bug for the tests in this ticket to all pass.

CommentFileSizeAuthor
block-add-cache-control.patch9.35 KBjcfiala

Comments

jcfiala’s picture

jcfiala commented

As an update, the patch to simpletest is at this issue: http://drupal.org/node/255944.

boombatower’s picture

boombatower commented
Status: Needs review » Reviewed & tested by the community

Wrong post area.

boombatower’s picture

boombatower commented
Status: Reviewed & tested by the community » Needs review

Revert.

yched’s picture

yched commented

For most blocks (hardcoded in modules), caching granularity (per user, per role, site-wide...) is determined by the nature of the content of the block, so it's the module author that knows how its blocks must be cached, site admins should definitely not be allowed to mess with this.

Custom blocks (core's "boxes", views-generated blocks...) are an exception to this, though.
So maybe the way to go is to add a 'BLOCK_CACHE_CUSTOM' cache mode, and display the cache granularity options only when the defining module has explicitely set this flag for the block.

chx’s picture

chx commented

I tend to agree with yched. While I might have information of some sorts about the content that the block displays generally I think this is not a good idea. A contrib maybe? Looks like doable. On the other hand if the programmer changes the cache information and that's not picked up then it's a bug and it needs a fix.

yched’s picture

yched commented
Status: Needs review » Closed (won't fix)

On the other hand if the programmer changes the cache information and that's not picked up then it's a bug and it needs a fix.
True, *that* issue is http://drupal.org/node/235673. I currently have absolutely no time to work on a patch, unfortunately.

About 'custom blocks' :
It seems Views just gained cache settings for its blocks (that are probably going to be bitten by the above, BTW...). Which only leaves user-defined 'block.module' blocks - and only those that execute PHP code could possibly want to change from their current BLOCK_NO_CACHE. Not sure this is enough of a use case - if you need custom caching for those, embed them in a module.

Won't fixing this, then.