To allow modules like block cache alter the block cache settings to work with context.

Comments

joelcollinsdc’s picture

Status: Active » Needs review
ianthomas_uk’s picture

Title: Allow cache settings in database to be taken » Respect block cache settings from database (including hook_block_info)
StatusFileSize
new750 bytes

domidc's patch was bitrotted by http://drupal.org/node/1154908 which switched the list of columns from a whitelist to a blacklist, joelcollinsdc patch is therefore logically equivalent (it removed from blacklist instead of adding to a whitelist). Here is the same change as a .patch file.

My only concerns about this patch would be:
a) Why johnbarclay in #1154908 thought that context already handled block cache and therefore added this line.
b) If this would break sites who are relying on the current broken behaviour.

dan.munn’s picture

If the permanent placement of a block is changed, then I'm assuming the logic runs along the lines of caching becomes unreliable due to its migrated nature ... That being said, context makes no effort in release to load caching information if the blocks are loaded via hook, without block enabled. The only check that affects cache otherwise would be the isset check that defaults it to CACHE_NONE otherwise; this does however result in every block returning CACHE_NONE. In theory re-enabling the cache in this fashion is not a bad thing, however does entirely rely on the module providing the block catering to the case of non-permanent usage.

tekante’s picture

Status: Needs review » Closed (duplicate)

Duplicate of #2037793: Block caching removed? which has been applied to latest dev. Thanks for the report and patch.