All footnotes available as block for Layout Builder / Paragraph / ...

@PhilY Thanks for reporting this issue. We will fix it shortly.

In this patch footnote block and a filter configuration were added.

In this patch I slightly modified the footnotes block: added paragraph processing(to add a paragraph to the footnotes block you need to specify a field in the content type and paragraph field(s) in the next textarea), slightly changed the logic of link generation (but it needs be improvement), refactored the code.

Patch allows you to group links, but the numbers in each field start at 1 (this is a problem I haven't been able to solve yet), if there are any ideas or suggestions on how to do this, I would appreciate

Hi! I'm not new to applying patches, but I'm unable to make it work. I have this error message :
error: patch failed: src/Plugin/Filter/FootnotesFilter.php:4
error: src/Plugin/Filter/FootnotesFilter.php: patch does not apply

Any idea of what can cause this?

Thanks PhilY and Tolyan4ik!

As previously said, there is a remaining problem : the numbers in each field start at 1.

Did someone has been able to solve this?

I can't get the block field to be displayed using layout builder and i don't know where is the issue, help appreciated.
Also i think you need to add some help text or description to clarify where and how to use this block

@yasmeensalah This patch creates CUSTOM BLOCK with id = "footnotes_block" and admin_label = "Footnotes block", this is not a field. You can place it in admin/structure/block or in layout builder like other blocks.

@PhilY

Hi, Did you find a solution #4. I don't know whitch terms I have to put in..
My content type is "Document" (machine name document). Inside I have a field "Paragraphe" (machine name field_paragraph). Inside "Paragraphe" I have a field "Texte" (field_text)

Many thanks for your help !

I found !
Thank you

I've struggled with this a bit, finding it particularly difficult to ensure my paragraph entities are all properly matched. Can I suggest a different approach that I think makes this much simpler:

1. Have a FootnotesGroup service that stores the matches.
2. Provide an option to disable the footnotes footer.
3. Provide a simple Block to allow output of the footnotes template.

I've attached a patch. This includes the fix in https://www.drupal.org/project/footnotes/issues/3169299 so that this is testable in D9 and can return the theme render array for the footnotes. I've created a separate version that shows just the code change proposed in this.

So:

• footnotes-all-footnotes-one-block-WITH-D9-FIX-3098138-16.patch - Test in your local copy with this
• footnotes-all-footnotes-one-block-WITHOUT-D9-FIX-3098138-16-do-not-test.patch - Code review with this as this doesn't contain this fix

Now that #3169299 is committed, updated patch.

We tried #18 but we had problems when rendering is not straightforward:

• Sometimes we trigger a render of a field but we don't display it on the page (for example, because we want to use it in a meta tag), so we don't want its footnotes to be added to the block.
• Sometimes fields can be rendered after the block (with lazy builders, for example) so the block will not have their footnotes.

As a workaround, we started working on a module that does the same thing with JavaScript : https://www.drupal.org/project/footnotes_all_block
(It detects the footnotes in the page, then moves them to the block.)

On a whim, I tried applying the patch provided by @scott_euser in #18 to v3.0.0 of the module. I applied the patch through composer. The patch applied successfully and the module appears to work as needed when footnotes are created inside paragraphs. i have not tried this with nested paragraphs. However, I think the work from #18 a great step in the right direction. I really like how it's optional; the module can work as originally intended or using the Footnotes Group. Thank you very much for this!

Just to share that I am having an issue with this related to the render cache.

Locally when I have:

$settings['cache']['bins']['render'] = 'cache.backend.null';

it works fine, but when I comment that out, it will show the content of the block on first page load when logged in, but on subsequent refreshes of the page (when logged in) the block comes back empty.

Things work fine when I don't use the block, so believe it has something to do with the service being cached somewhere. When buildFooter() runs for the block, on the first run I can see it has values, but subsequent runs it is empty.

I will continue investigating, but wanted to share in case someone else had come across this issue too.

I believe all future work is going into v3.

It might be worth splitting service and output refactoring into a separate issue, then leverage that in the block.

I can replicate the cache issue as #21. When cache is disabled all footnotes appear as part of the block correctly but with cache on, blank footnotes block or a totally irrelevant footnotes block duplicated from another page that previously showed footnotes.

I tried adding cache contexts to the footnotes builder function from the group block plugin, but no luck. It seems like the issue is with the filter plugin caching the note matches? Any one found a solution for this?

FWIW my coworker built a variation of this which uses an "extras" field on the node in #3252527: Add "extra" field to display all footnotes.

After spending several hours trying different cache tags and contexts, setting cache max age to 0 from the block plugin has only solved the issue related to #24. Patch and Interdiff are attached.

this patch add the current node tag and route context to block plugin to solve issue described in #21

Hi y'all -- this patch is working swimmingly for me but then I'm running into the issue that for nodes with many paragraphs it gets cumbersome to ensure that all footnotes are numbered sequentially. I ended up handling this with a node_presave hook, which is working pretty well although right now it has field names and paragraph types hardcoded so it's too specific to turn into a patch. Just wanted to share in the comment thread in case it's useful for anyone else to adapt for their own purposes..

/**
 * Implements hook_node_presave().
 *
 * Tweak footnote values in paragraphs field to ensure sequential numbering.
 */
function MYMODULE_node_presave(NodeInterface $node) {
  $field_definitions = $node->getFieldDefinitions();

  // Loop through fields and ID first paragraph field,if any.
  $paragraphs_field = FALSE;
  foreach ($field_definitions as $field_name => $definition) {
    if ($definition->getSetting('handler') === 'default:paragraph') {
      $paragraphs_field = $field_name;
      break;
    }
  }

  if (!$paragraphs_field) {
    return;
  }

  $footnote_count = 0;

  // From FootnotesFilter.php in footnotes module.
  $footnote_pattern = '|<fn([^>]*)>(.*?)</fn>|s';

  foreach ($node->$paragraphs_field as &$paragraph_reference) {
    if ($paragraph_reference->entity->bundle() === 'basic_text') {
      $body = $paragraph_reference->entity->field_body->value;
      $this_item_footnote_count = preg_match_all($footnote_pattern, $body) ?? 0;

      if ($this_item_footnote_count && $footnote_count > 0) {
        $starting_number = $footnote_count + 1;
        $replacement = "<fn value=\"{$starting_number}\">$2</fn>";
        $replacement_body = preg_replace($footnote_pattern, $replacement, $body, 1);
        $paragraph_reference->entity->field_body->value = $replacement_body;
        $paragraph_reference->entity->save();
      }

      $footnote_count += $this_item_footnote_count;
    }

    elseif ($paragraph_reference->entity->bundle() === 'image') {
      $body = $paragraph_reference->entity->field_credit_line->value;
      $this_item_footnote_count = preg_match_all($footnote_pattern, $body) ?? 0;

      if ($this_item_footnote_count && $footnote_count > 0) {
        $starting_number = $footnote_count + 1;
        $replacement = "<fn value=\"{$starting_number}\">$2</fn>";
        $replacement_body = preg_replace($footnote_pattern, $replacement, $body, 1);
        $paragraph_reference->entity->field_credit_line->value = $replacement_body;
        $paragraph_reference->entity->save();
      }
      $footnote_count += $this_item_footnote_count;
    }
  }
}

Resetting footnotes start number to 0 should be removed to auto increment the numbers in sequence regardless of the different paragraph entities where the content is coming from. This patch solves the issue #28.

Hello,
I have tried the last patch in #29, and this works perfectly, even if the number of the footnote is not put when the footnote is added. Thanks !

But it looks like there is a block cache issue because when I updated a node, the footnote group block is not updated.

Adding the following code in FootnodeGroupBlock.php should correct the cache issue of the block displayed on a node.

  /**
   * {@inheritdoc}
   */
  public function getCacheTags() {
    //With this when your node change your block will rebuild
    if ($node = \Drupal::routeMatch()->getParameter('node')) {
      //if there is node add its cachetag
      return Cache::mergeTags(parent::getCacheTags(), array('node:' . $node->id()));
    }
    else {
      //Return default tags instead.
      return parent::getCacheTags();
    }
  }

  /**
   * {@inheritdoc}
   */
  public function getCacheContexts() {
    //if you depends on \Drupal::routeMatch()
    //you must set context of this block with 'route' context tag.
    //Every new route this block will rebuild
    return Cache::mergeContexts(parent::getCacheContexts(), array('route'));
  }

Re-rolling the patch in #29 with the suggestion in #31

@mgaskey https://www.drupal.org/files/issues/2022-04-06/footnotes-all-footnotes-o... doesn't work because

use Drupal\Core\Cache\Cache;

is missing from the "/src/Plugin/Block/FootnotesGroupBlock.php" file.

I fixed https://www.drupal.org/files/issues/2022-04-06/footnotes-all-footnotes-o... with

use Drupal\Core\Cache\Cache;

.

Thanks for the new patch.
Unfortunately, I get this error ParseError: syntax error, unexpected end of file, expecting function (T_FUNCTION) or const (T_CONST) in footnotes/src/Plugin/Block/FootnotesGroupBlock.php on line 50.

} is missing at the end of FootnotesGroupBlock.php

There was a mistake in footnotes-all-footnotes-one-block-3098138-34.patch. Fixed.

All is OK now, thanks !
Hope this will be committed in the module soon !

I applied the patch on #34, and used twig_tweak to display block, but there is a still the same block being displaying in the footer. If that could go away then it would be good. @mibfire.

EDIT: I was able to display block in template with twig_tweak and not display in default footer area with using {{ drupal_block('footnotes_group') }}. Instead of drupal_entity()

Working with this patch #34 and I was getting duplicate values for footnotes when paragraph templates are included with component templates in twig. Could be an issue with callback, but the array(4) is the footnote that actually ends up displaying on the paragraph and both values will display in the footnote. I ended up removing array(3) that doesn't link anywhere on the page.

3 => array:5 [
"value" => "55"
"text" => "the very first footnote on the page."
"text_clean" => "the very first footnote on the page."
"fn_id" => "footnote55_llhyxob"
"ref_id" => "footnoteref55_llhyxob"
]
4 => array:5 [
"value" => "55"
"text" => "the very first footnote on the page."
"text_clean" => "the very first footnote on the page."
"fn_id" => "footnote55_nbsx6px"
"ref_id" => "footnoteref55_nbsx6px"

At this point in time is it recommended to use https://www.drupal.org/project/footnotes_all_block or try the patches and methods outlined in this thread?

My use case is that I construct content by paragraphs and I would like to have links to footnotes from all paragraphs in the page rendered on the last one that could be a dedicated "references" paragraph type.

This fixes the problem with the current patch as it provides a way of using lazy loading to generate the output after the text runs through the text filters. This is working for me with the patch from #3252527 so that nodes have a footnotes_group structure to show all of the footnotes added through text paragraphs on the node.

One thing I'll say about the patch is that I think the wording and value should be changed to make it more clear. Right now the field is labeled "Disable output of the footnotes footer" and its description is "If disabled, the footnotes will be grouped together. They can be output using the Footnotes Group block, or anywhere using Twig Tweak {{ drupal_block('footnotes_group') }}." It would be better to say something like "Disable normal footnotes footer" and then in the description say "Disabling this will stop the normal footnotes footer from showing at the bottom of the text, allowing it to be displayed through other means, e.g. using the Footnotes Group block."

Also, I wonder if the block's output should also be changed to use the lazy loading from #3252527?

I think some test coverage would also be good for this.

This changes the block output to use the lazy builder too, so it should now work as intended.

I had a specific template to display footnotes with the previous patch #34, now with the patch #44 no more footnotes are shown. Here is the content in this template

 array:2 [▼
  "#create_placeholder" => true
  "#lazy_builder" => array:2 [▼
    0 => "footnotes.group:buildFooter"
    1 => []
  ]
]

How can I display footnotes in my template now ?
I wonder why use lazy_builder, the block needs to be cached by node and only by updated when the node is updated. With lazy_builder, as I understand how it works, the block will not be cached and built on every call ?

@lucuhb: You might try overriding the two templates that come with the module, rather than trying to rewrite the output with your own approach, basically working with the system rather than trying to change it.

In fact the problem is that the title of the block block--footnotesgroup.html.twig is always displayed, even there are no footnotes. And I don't want to display the title when there is no footnote (and I want to display it when there are some !).
Now with the lazy_builder, the content render of the block is never empty (something like <drupal-render-placeholder callback="footnotes.group:buildFooter" arguments="" token="xxxx"></drupal-render-placeholder>) even when footnotes are empty.

So how can I show the block title based on the existence of footnotes ?

Does it work if you remove the twig template for the block?

I succeeded to show/hide block title by :

• removing my block--footnotesgroup.html.twig template
• unchecking the block title displaying in block configuration
• adding the block title in footnote-list.html.twig after checking the footnotes are not empty (by default this template gives always something even there is no footnotes because the existence of footnotes is not checked)
  

  {% if footnotes is defined and footnotes is not empty %}
     <h2 class="block-title">{{ 'Footnotes' |trans }}</h2>   
       <ul class="footnotes"> 
        ....
      </ul>
  {% endif %}

Regardless of the problem of the block title, when I go back to an already visited node and reload it, the footnotes are no more displayed. This occurs for authenticated users.

Renamed the addToFooter() method to simple add() because it shouldn't assume where the output will be placed. Also some minor comment improvements.

We've noticed that if the same footnote is pointed to from multiple locations, i.e. the footnote number is repeated more than once, the output ends up with duplicate footnotes in the footer. I think it would be worth checking in FootnotesGroup::add() that the existing item doesn't already exist before adding it. OTOH maybe FootnotesFilter::findFootnote() should handle that logic? For now we're using this code to remove the duplicates during output:

function mytheme_preprocess_footnote_list(&$variables) {
  $footnotes = [];
  foreach ($variables['footnotes'] as $key => $footnote) {
    $footnote_id = $footnote['value'];
    if (isset($footnotes[$footnote_id])) {
      unset($variables['footnotes'][$key]);
    }
    else {
      $footnotes[$footnote_id] = $footnote_id;
    }
  }
}

I am trying to use these patches on a site and having some difficulty. I was able to apply patch #50 without any issue, and added the "Footnotes Group" block to the bottom of a page that is built with paragraph components, but it is blank. These components contain multiple footnotes provided by the footnotes module, and currently the footnotes are showing up at the bottom of each paragraph.

Is there anything else that needs to be done to get this working?

In order to use the Footnotes Group block you have to update the text filter to enable the "Disable output of the footnotes footer" option.

thank you, that worked!

Should we improve the documentation or UI so people do not miss how this works?

+1 for finishing off this functionality

First off, is this actually released in 3.0.1? or in an upcoming version (if so, what version number to release this is targetted)? The version tag on this issue makes that a bit unclear.

Answer to #55: yes, if the functionality is stable enough to writeup?

My other question is how this patch relates to https://www.drupal.org/project/footnotes/issues/3252527 ? Do both need to be applied, only one, etc?

Happy to contrib testing and possibly some doc writeup time once I wrap my head around where this is at.

Thanks
- DH / HF

Spending some time today to check on this.

Using:
- Fresh local D9.4.5 +
- Paragraphs 8.x-1.14 or 8.x-1.15 +
- Layout Paragraphs 2.0.1 +
- Footnotes 3.0.1 +
- Patch #50 here +
- Theme function #51 here +
- patch from 3252527#10
...

I am still running into the cache issue described here in #21. I.e., the first page load after cache clear gives the collected footnotes in the block, but any refresh without cache clear, the block output is empty. Is there a patch or config item I am missing in my recipe to catch up to state of the art on this module?

Also, I am seeing footnote re-use across separate paragraphs not getting number collapsing (see screenshot). I assume this is not going to be possible with the Footnote Group block + extra field?

Slight update: I did some debugging, and it looks like $variables['footnotes'] is completely missing on second and subsequent page loads after cache clear, when using the recipe in #57. Is it possible that this is less of a caching issue versus $variables['footnotes'] not getting built, and so the "empty" block gets re-cached?

Doing more digging into this today. Debugging not quite complete, but it looks like several functions related to detecting duplicate fn values, fn text, etc are completely unable to find duplicates across various paragraphs, especially with nested paragraphs as is used by the Layout Paragraphs system. I'll edit this when I have more specific findings, recommendations, or a patch.

I'm testing this module + patch #50 with the theme function from #51. I'm not using the extra field patch. No paragraphs, but Layout Builder.
I got all the footnotes from different LB blocks, but they all get duplicated. Even if there is just 1fn, I got it twice.
The cache issue as described in #57 is also present.

Here is #50 modified to remove the caching components. This seems to work well for anonymous users, but the same issues from before persist for logged in users. Not sure if this is helpful!

Using Patch #61 still having caching issues for logged in and anonymous users.

Steps to reproduce
1. Go to a page where footnotes are not appearing (but should be)
2. Clear the drupal cache, footnotes appear
3. Refresh page, footnotes disappear

I noticed that when placing a multiple blocks with references to the same footnote, the footnotes group block generates the footnote multiple times (even though it should only be once). This was because the store_matches and used_value was getting reset with each footnote footer call. By moving them into the 'else' section that is only called when the footnote disabled option is not checked, we are able to persist the used values from one block to the next.

I have also added functional testing for this change to the footnote filter.

I apologize, I missed adding a necessary change. Please do not use the #63, use this patch.

Hi,

Footnotes module is really nice but code wise it could be better.

Anyway, found out that in my case (similar to Petr ) Adding in the list of allowed tags and a value to the footnote will remove the duplicate.

I realized after I slept on it that my changes in #64 do not actually pull in additional footnotes across multiple WYSIWYG fields/blocks. I resolved this by merging in newer footnote references in the FootnotesGroup add function.

We're running into issue that the filter format is caching the data and not passing the footnotes to the FootnotesGroup service on the next request. We think we might need to use addPostRenderCacheCallback() to process the footnotes, but unsure if doing so will be able to pass the data to FootnotesGroup, but maybe it will work since the block is using a lazy builder already.

https://api.drupal.org/api/drupal/core%21modules%21filter%21tests%21filt... provides the current example of a filter using placeholders and then rendering the output in a way that might work for us.

I've tried a few different options to resolve the caching issue without success. The only thing I've found that works is disabling caching the block. I've uploaded a patch for that from an MR.

That's probably not a great long-term solution. Rendering them in JS might be a better option. As previously mentioned, there is a separate project that aims to do that: https://www.drupal.org/project/footnotes_all_block

The caching issue with the footnotes block looks to be due to the cache keys not being set correctly. I've added cache keys, tags and context to the render array built by the FootnotesGroupBlock which fixes the cache issue for me.

This is reroll of the patch file from comment 71 against the latest release 3.1.

Created patch from Merge request 7(https://git.drupalcode.org/project/footnotes/-/merge_requests/7) to use till latest changes got merge and new version release.

Patch #74 is working fine. Hiding mine.

I've been thoroughly testing this change out with and without caching, dynamic page caching, and big pipe enabled or not and confirmed this is working.

Hi,

I'm still experiencing those cache issues with latest patches.

1. Clear caches
2. First load -> Footnotes are there
3. Second load -> Footnotes are gone forever (until next cache clear or invalidation)

After some debugging I have seen that the plugin is not collecting the footnotes after the cache is clear. I have seen in the annotation of the FootnotesFilter.php that there is a "* cache = FALSE," but it seems that the plugin is cached anyway.

I have added a $result->setCacheMaxAge(0); into the process() of the FootnotesFilter.php so it's processed always and not just when we clear caches.

Attached the patch from the MR7 + the cache max-age=0

I was running into an issue with the patch from #79 where the footnotes-multi links would display even on footnotes with one reference. I have updated the patch to only show the footnote-multi links when there are multiple references.

Going to merge this into 4x and created a follow-up here #3413181: Follow-up to all footnotes available as a block to apply to modal plugin to apply to modal plugin to apply it to the new modal version before the old one gets retired. Patches still needed while on 3x until 4x (and its upgrade path are more stable).

I think the $result->setCacheMaxAge(0); is unnecessary and will break page cache. Setting the entity context_definitions in the block configuration seemed like it was required for caching to work properly:

Thanks for the feedback! I believe we have that looking at FootnotesGroupBlock; it attempts to load the current entity as a cache context and merges that meta data into the build. Though since it is not required, perhaps at the very least we should document that that should be selected. I am not sure it makes sense to require it as I imagine there are cases where someone could use Footnotes in a non-node/non-entity context. I made a note of that here: https://www.drupal.org/project/footnotes/issues/3413186

I have left out the merge of setCacheMaxAge(0), and it can be picked up in a follow-up issue if needed, but I agree that it makes sense to cache as much as we can by default as a starting point.