Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I have been having a play with this module and while it displays blocks added to regions from the admin block screen, it does does not output any blocks on the page that are told to display in regions using context.
Comment | File | Size | Author |
---|---|---|---|
#16 | esi-1059036-16-fix-context.patch | 646 bytes | mikeytown2 |
#15 | esi-1059036-15-fix-context.patch | 4.99 KB | mikeytown2 |
#9 | 1059036-esi_context.patch | 4.67 KB | msonnabaum |
Comments
Comment #1
bleen CreditAttribution: bleen commentedsubscribing
Comment #2
kungfuchris CreditAttribution: kungfuchris commentedI managed to find a workaround for this. I am interested in getting some feedback from the Drupal community if this is a correct approach.
Here goes....
Context module specifies that it’s the responsibility of themes implementing theme_blocks() to take advantage of context blocks visibility on their own. But the esi module does not do this. The workaround for this is to alter the theme registry (see snippet 1) by implementing hook_theme_registry_alter() in your module and override the default theme function for theme(‘blocks’).
In your custom theme function for theme(‘blocks’) you can them add the code from the esi theme function for theme blocks, along with the call to context_block_list() which is context alternative for Drupal’s block_list() that retrieves context enabled blocks.
The esi function that handles getting themed HTML for a particular block from an esi tag (_esi__get_block()) in esi.inc also calls the Drupal block_list() which ignores context. An implementation of module_invoke_all() e.g. $blocks = module_invoke_all(‘context_enabled_blocks’, $blcoks, $region), after it calls block_list() would allow our modules to return context enabled blocks . (see snippet 3)
I have found that even though this works to display context enable blocks when using the esi module, there is still a lot more to investigate as context blocks only seem to appear if the context is set to sitewide.
Maybe I am missing something, but hoping this gets the conversation started as there is a lot of buzz about esi happening around various discussion groups but very little case studies of a concrete implementation.
Comment #3
wwhurley CreditAttribution: wwhurley commentedA better implementation would be to use something like the following:
And then have
However to make that work the callback for the block has to change to:
That all works, though you have to be careful about blocks that claim to be BLOCK_CACHE_NO_CACHE when they really don't need to be ... I'm looking at you, Boxes. Which brings me to an interesting question about why BLOCK_CACHE_PER_PAGE is implemented as a hash on the callback but BLOCK_CACHE_PER_USER and BLOCK_CACHE_PER_ROLE are handled as cookies.
We have a working version of this in production on a site. If there is any interest I could probably roll it as a patch to the existing release and/or fork the repo and do it there.
Comment #4
msonnabaum CreditAttribution: msonnabaum commentedHmm, I couldn't get #3 to work, but I'd love to see a proper patch so I know I'm not missing something here.
Comment #5
theapi CreditAttribution: theapi commentedRemoving the function esi_theme_registry_alter(&$theme_registry) got #3 working for me.
Comment #6
wwhurley CreditAttribution: wwhurley commentedThanks for keeping me honest, PeterC. I did completely miss that step. Anyone know anything about the hash for BLOCK_CACHE_PER_PAGE and cookies for BLOCK_CACHE_PER_USER and BLOCK_CACHE_PER_ROLE?
Comment #7
manarth CreditAttribution: manarth commentedThe BLOCK_CACHE_PER_PAGE setting is used to provide a different ESI URL for each page where the block is displayed. This ensures Varnish will cache a different version of the block for each page it's displayed on.
The BLOCK_CACHE_PER_USER and BLOCK_CACHE_PER_ROLE cookies work with a custom vcl_hash routine which splits each block into a separate per-user/per-role cache-bin within Varnish. This means that a per-user block (such as a welcome message saying "Hello Bob") is only displayed to the user, and similarly for role-based block control.
BLOCK_CACHE_PER_PAGE can be implemented as a static hash because the block's contents only changes on a page-URL basis. Blocks which use BLOCK_CACHE_PER_ROLE and BLOCK_CACHE_PER_USER can vary their contents according to the user-session, so Varnish must be capable of varying them by cookie data.
Comment #8
kungfuchris CreditAttribution: kungfuchris commentedHi whurleyf1,
Thanks for your post. It's working with one exception. It only works for blocks that has a sitewide context. Have you managed to get this working on blocks not set to sitewide context?
Comment #9
msonnabaum CreditAttribution: msonnabaum commentedHere's a patch. Seems to be working for me.
Comment #10
AgaPe CreditAttribution: AgaPe commentedTried a patch from #9. I have layouts assigned to pages using context_layouts module, a submodule of context, and using the patch does include an esi tag for the blocks but does not use the proper template chosen using context_lauouts.
Comment #11
mikeytown2 CreditAttribution: mikeytown2 commented#9 is in the 2.x branch. This should be fixed. If I am mistaken please re-open.
Comment #13
askibinski CreditAttribution: askibinski commentedlast -dev results in a fatal error, because context_reaction_esi_block.inc is in the module root folder and should be in /plugins.
Comment #14
askibinski CreditAttribution: askibinski commentedAnd
should be:
or else $type is empty and src won't get build
Comment #15
mikeytown2 CreditAttribution: mikeytown2 commentedThis patch has been committed.
Comment #16
mikeytown2 CreditAttribution: mikeytown2 commentedThis one as well