In context_reaction_block.inc, the function get_blocks will generate a new list of all the blocks for a given region or load the data from Context's own cache. After this cache is generated, saving a block that is included in an existing context will NOT have the changes show until Context's cache is rebuilt.

Steps to reproduce:

  1. Add a block to a context as a reaction (this block is not cached by default)
  2. Edit the block and change its title, and save
  3. View page w/ context containing block
  4. Block is shown with old title
  5. Either manually flush all caches, or re-visit the context admin page (which triggers a cache flush)
  6. View page again
  7. Observe new title

Note that this also affects modules that implement hook_block_info_alter like blockcache_alter module, which changes the caching of a block before it's saved.

A workaround for this is to clear all caches or trigger a Context cache flush by re-saving a Context or visiting the context admin page.

I think the solution may be to add a submit handler to the block save form which will clear the context block cache.

Thoughts?

CommentFileSizeAuthor
#3 context-2130655-update-block-info-3.patch700 byteseelkeblok
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

bkosborne’s picture

bkosborne
Primary language English
Location New Jersey, USA
CreditAttribution: bkosborne commented
Issue summary: View changes
bkosborne’s picture

bkosborne
Primary language English
Location New Jersey, USA
CreditAttribution: bkosborne commented
Title: Context cache prevents block_info_alter from working without cache flush » Context cache not updated with blocks are saved with new data
Issue summary: View changes

changed repro steps to be more generic

eelkeblok’s picture

eelkeblok
him/his
Primary language Dutch
Location Netherlands 🇳🇱
CreditAttribution: eelkeblok commented
Status: Active » Needs review
FileSize
context-2130655-update-block-info-3.patch700 bytes

I took a stab at solving this. This is the most basic change I could come up with, but I'm wondering if it doesn't make more sense to simply have the get_blocks method of the block reaction listen to and update the rebuild_needed status directly, instead of having to pass it as the rest input and having to follow the call to get_blocks() with a rebuild_needed(FALSE). I can't think of any situations where get_blocks should use the cached block-info even though a rebuild is needed.

BTW, background: rebuild_needed is set through a form alter in context.core.inc when a block is updated, so it serves as a flag indicating block info has changed.
Also, this patch is generated against release 3.3 which happens to be the version my client's site is running. I'm running out of time, but I hope it applies to HEAD as well. If not, I'll reroll at a later time.

kreynen’s picture

kreynen CreditAttribution: kreynen commented

This patch solved the issue for me. Still testing to see if it causes any other issues.

kevincrafts’s picture

kevincrafts CreditAttribution: kevincrafts commented

I also tested this patch on some sites and it solved the issue for me as well.

rooby’s picture

rooby CreditAttribution: rooby commented

Are there any performance implications to this fix? Are the context caches only being cleared when a block has been changed?
(I am not familiar with the code myself)