Footnotes 4.x does not work with the cache enabled.

Hi! Have you tried these options:

1. 'Current entity context for caching' within block config as per module homepage
2. 'Group footnotes using JavaScript' option within block config

Hi!. I enabled both options

settings:
  id: footnotes_group
  label: 'Footnotes Group'
  label_display: visible
  provider: footnotes
  context_mapping:
    entity: '@node.node_route_context:node'
  group_via_js: true

I must set the max-age=0 for the build of the node entity to work.

Please let me know if I am missing something.
Thanks.

Can you debug that the js is actually being called because it should build with whatever is rendered since it's js

If you're having to set max age 0 it means you're still rendering footnotes with PHP/Drupal

I'm not sure if it has something to do with the custom block "FootnotesGroupBlock.php" within this code:

    ...
    if ($entity = $this->getContextValue('entity')) {
      assert($entity instanceof EntityInterface);
      // Using placeholder rendering requires providing the cache keys.
      $build['#cache']['keys'] = array_merge(['footnotes_group'], $entity->getCacheTagsToInvalidate());
      $metadata = $metadata->merge(CacheableMetadata::createFromObject($entity));
    }

    $metadata->applyTo($build);
   ...

Looks like it is taking the metadata from the entity and this is what the block ends up using versus the setting within the footnotes_group block. This block is also utilizing `#lazy_builder` so that could have something to do with it as well? I got around this temporarily by forcing the max age of this block to be set to "0":

    $metadata->applyTo($build);
    $build['#cache']['max-age'] = 0; // Forcing the max-age after the entity metadata is applied.

    if ($this->configuration['group_via_js']) {
      $build['#attached']['library'][] = 'footnotes/footnotes.group_block_via_js';
    }

Once I did this the footnotes_group block is loading every time, but it is basically ignoring the settings within the block. Currently the users settings on the footnote block isn't changing the cache setting for the block. The OP's possible solution might actually work as a better fix, or maybe also check the timing of when the users settings for caching actually get applied versus the entity settings?

I am able to reproduce this while using footnotes with layout builder.

Disabling the cache in footnotes filter plugin seems to have fixed the issue for me but I'm unsure if it's the best solution.
(FootnotesFilter.php)

if (!empty($this->settings['footnotes_footer_disable'])) {
      $result->setCacheMaxAge(0);
    }

Found an old issue releated to same #3098138 📌 All footnotes available as block for Layout Builder / Paragraph / ... Fixed .

I've added more details to the homepage about how to configure (within installation) + added test coverage to show that 2nd load still shows the expected footnotes when using the JS version.

Leaving this as 'maintainer needs more info' as the issue summary does not make it clear how to reproduce this, and I still suspect its just not being configured as expected.

If you have contents that are lazy loaded, you necessarily need to use the JS version as it has to react to changes on the page. Once enabled you should not experience the issue (and if you do, please debug the JS file to check if its kicking in correctly)

Max age 0 is definitely not what you want as that will turn off caching for the entire page wherever the footnotes block appears (and assuming that is most pages you're effectively turning off caching on your site).

scott_euser → changed the visibility of the branch 3500819-footnotes-4.x-does to hidden.

We've been struggling with this as well and have yet to pinpoint a cause. I tried to write a failing test to illustrate the issue but haven't had luck yet.

I see now. This was fixed in https://www.drupal.org/project/footnotes/issues/3475513 🐛 Block - #lazy_builder content is empty for admin user on refresh Needs review but that is unreleased so my test failed locally on 4.0.0-beta5 specifically but passes in CI on 4.0.x. Requiring the 4.0.x branch could be an option for people before a new release is put out.

Like was mentioned in https://www.drupal.org/project/footnotes/issues/3475513 🐛 Block - #lazy_builder content is empty for admin user on refresh Needs review , the dynamic page seems to work although interestingly, enabling render cache debugging → reports a miss for some reason. I don't understand that though as there seems to be an entry in the cache_render table.

Oh I see that makes sense! Apologies for not getting that in a release early then, will do that shortly! Thanks for adding the test coverage - much appreciated, I am sure it will save future us some headaches.

(Note I merged manually because the MR was marked as draft, granting credit manually - thanks!)

New release made, thanks!

Automatically closed - issue fixed for 2 weeks with no activity.