Closed (duplicate)
Project:
Context
Version:
7.x-3.0-beta1
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
1 Jul 2011 at 16:02 UTC
Updated:
28 Jul 2013 at 21:07 UTC
Jump to comment: Most recent file
Comments
Comment #1
joelcollinsdc commentedHere is my attempt at fixing this:
http://drupalcode.org/sandbox/joelcollinsdc/1873888.git/commitdiff/d2a97...
Comment #2
ianthomas_ukdomidc'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.
Comment #3
dan.munn commentedIf 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.
Comment #4
tekante commentedDuplicate of #2037793: Block caching removed? which has been applied to latest dev. Thanks for the report and patch.