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.Activating one of my context-placed blocks for ESI whisks it right off the page. I followed this to an implementation of esi_context_context_load_alter() which I thought had a minor chance of causing friction, so I tried to smooth out some rough edges. Moving on, I found the problem appears to be the block system not knowing about the ESI block that is being used as a substitution.
I've created hook_block_info() as a simple relay of a statically cached registry populated by esi_block_register_block(). It works for my context use case as patched, though would not be ideal for sites using lots of ESI-enabled blocks.
Setting to needs work because the patch does not account for the needs of core block or panels, though in theory that should be an easy addition if this direction is suitable.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 2089341-3_esi-block_vanishes.patch | 3.29 KB | Grayside |
| esi-esi_block_fail-add_registry.patch | 1.87 KB | Grayside |
Comments
Comment #1
Grayside CreditAttribution: Grayside commentedOriginal title predates identifying the problem.
Comment #2
Grayside CreditAttribution: Grayside commentedThis approach does not propagate block caching settings, not to mention being touchy. Reworking the registry into a scanner of existing block settings.
Comment #3
Grayside CreditAttribution: Grayside commentedOkay, after several hours of wrestling with this, I'm forced to take the bad solution and move forward.
I can't tell if it's a bug in ESI Block, a weird probably with core block, or a local caching problem, but no proper solution I tried resulted in actually setting the cache mode of the ESI block properly. My suspicion is that all my various attempts were overridden by database data, but I was thoroughly purging it, so I do not know how that could have happened.
The attached patch resolves one warning with the original approach, and adds hook_esi_block_info_alter() to the top of esi_block_url(). This allows for a final override of any block settings before the URL is prepared, such as forcing the cache mode to be the setting defined in the original blocks info declaration.
Comment #4
aangel CreditAttribution: aangel commentedI'm experiencing the same thing with the panels implementation...changing the setting to ESI doesn't seem to do anything. Starting to investigate...
Comment #5
geerlingguy CreditAttribution: geerlingguy commentedI'm having the same issue as well; contexts lose their ESI-enabled blocks.
[Edit: I can confirm that the patch at least lets blocks appear within contexts again, so that's good. Are we still at needs work (because it's a messy/imperfect solution), or should this be needs review or RTBC since it's the only solution that anybody can think of at this time?]/