Closed (fixed)
Project:
Context
Version:
6.x-3.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
15 Feb 2011 at 23:17 UTC
Updated:
31 Aug 2011 at 20:05 UTC
Jump to comment: Most recent file
Comments
Comment #1
timaholt commentedThis is something I had to deal with as well. I've attached a patch for the no_node_grants version of blockcache_alter. This is a safe patch, meaning you can apply it without having blockcache_alter enabled and it should be ok. If blockcache_alter isn't enabled, context behaves as normal. If it is, then the patch functions and blocks are cached.
If you'd like me to roll this for node_grants, I can easily do that. This patch is meant to be applied in the module root directory, and the file affected is plugins/context_reaction_block.inc
Comment #2
nedjoThx for the patch. To avoid having to patch Context I drafted a sandbox project at http://drupal.org/sandbox/nedjo/1087298 providing this functionality in a separate module. Not tested yet. trimsyndicate, I've assigned you full access to the project.
Comment #3
rjbrown99 commented+1, I'd love to have this in place. I may see what I can do about testing as well. I'd prefer the with-node-grants option since you are offering. Working with the sandbox module now, looks good aside from the .info file project name.
Comment #4
rjbrown99 commentedI was having quite a lot of trouble with context_blockcache_alter_reaction_block.inc, specifically this:
Changing it to this works:
It was causing blocks to intermittently not be displayed despite the fact that they were coming back correctly from the upstream cache_get().
There's a patch/sandbox in the issue, so changing status.
Comment #5
nedjo@rjbrown99: thanks!, incorporated into #1088276: Database values for block cache not used.
Comment #6
rjbrown99 commentedNo problem. I'd plop it into the sandbox myself but I seriously need to figure out how to use git with Drupal.org :)
Comment #7
bastnic commentedFYI, the project in nedjo's sandbow now purpose an integration with context_layouts.
Comment #8
tmarly commentedThere is still a problem with cache refresh.
For example, if one of my block is in cache with a refresh policy set on "node added/updated/deleted", and if i update a node, the cache is not cleared.
This is due to this part of code, in blockcache_alter.module:
$result = db_query("SELECT module, delta FROM {blocks} WHERE status = '1' AND cache <> '-1'");The test status='1' will fail when using Context module.
However, at this time, the dev branch of blockcache_alter has changed a little bit this behavior, through this issue: http://drupal.org/node/986366, but it's still not the best solution since we should add most of modules in the variable blockcache_alter_include_modules.
So for now, a quick & dirty fix is to remove the test status='1' ...
Comment #9
dalinFor anyone that arrives here please see
http://drupal.org/project/context_blockcache_alter
Comment #10
ccshannon commentedI've applied the patch in #1. I also made the change to context_blockcache_alter_reaction_block.inc in comment #4.
My Views blocks simply will not cache using Context. They are in the content_top and content region of my homepage. The SQL queries for the Views, one of which takes about 2,300ms because it has to sort on a CCK field, run every single time the page loads.
I have set cache for the Views Blocks at the Views level. I have set it at the Block admin level using Block Alter Cache with Context Block Alter Cache also installed.
None of this has any effect whatsoever on Views Blocks in my content_top and content regions.
Strangely, I have a Views Block sitting in the right sidebar region, with the same cache settings as the Views Blocks that won't cache. That block caches just fine.
I definitely saw performance improvements on my page once I installed Block Cache Alter and Context Block Cache Alter, but not in the content_top or content regions.
I also applied the change from this issue #786722: views / block / caching / ignored by context
I was thinking the issue was with Views, but once I saw the right-rail Block caching, I am now prone to think the issue is with Context.
If I cannot get these Blocks to cache, then I will have to resort to writing all my blocks in my own module and forcing the items to cache no matter what block implementation module is in use, but given the amount of time my company has devoted to building tons of stuff in Views, I'd rather not undertake that initiative.
Any ideas or suggestions are welcome. Thanks.
Comment #11
ccshannon commentedOkay, I found the issue, in Blocks Cache Alter. See #1265662: Context Block Cache Alter has no effect on Views Blocks for the fix, if anyone else is having the same problem I'm having.