One of the interesting new opportunities - and thus pitfalls until you understand them - is Drupal 6's built in block caching. As a developer, I'm generally used to creating hook_block by just specifying the 'info' data in hook_block, and letting the other options be set by the admin via the blocks page. However, you can't set the caching level there, and more troublesome, you can't change the caching level of a block once it's been put into your site.

That can be a real problem, given that the default for the cache flag is 'BLOCK_CACHE_PER_ROLE'. If the block in question is customized to a user, then Bob's going to see George's data, and that's no good. Additional problems result with javascript or css that are linked to the block - if drupal_add_js or drupal_add_css are invoked in the block, their effects aren't included in the cache.

So what to do? From now on, you've got to plan out your blocks with a little more care than before. Is the block going to change quickly? Is the block using javascript or css that you can't (or don't want to) include as in-line data in the block's returned data? Then you may need to go with BLOCK_NO_CACHE. Is the block's information personal? Then BLOCK_CACHE_BY_USER. On the other hand, if you've got something that shows up on every page and doesn't change much, you might want to go with BLOCK_CACHE_GLOBAL.

But it's important in Drupal 6 to take a few moments when laying out a new block and consider how you want it to be cached, because once you've created it you'll need to dig into the blocks table to change it.

• John Fiala's blog
•