Enable individual footnotes while footer is disabled

Here's the patch for the proposed changes.

Thanks for your contribution to this module! I can understand the use case a bit (though quite edge case perhaps - open to hearing otherwise though).

So I think ideally we consider workaround first. I wonder if there is an option where you e.g. use hook template suggestions for the formatted text field and check node bundle via route match. Then for the node bundles you want to immediately output it, use twig tweak to immediately render the block. Or alternatively you duplicate the text format with the alternative configuration and for the different node bundles, use different formats. Or even add cache context if node bundle and do a conditional config override (not sure if that's feasible). Just spit balling some ideas.

If these do not work as a workarounds then next steps would be:

1. Convert patch to merge request so I can review and comment on the code. If not sure how I can help give you steps to make it easier.
2. Add tests (though I realise this is not doable by everyone so I can also help with that bit, at least pointing in the right direction/pseudo code)

Thanks!

Thanks for your comment Scott. To explain the background for this need. For some node types we have complex structure made up from different paragraphs. Such node type can have text field, followed by slider, then grid of cards, then again another text paragraph etc. - basically a fluid structure. For such pages it's easiest to let FootnotesFilter process() to render individual footnotes groups per each text field automatically. Especially that this is rendered as part of the text field and inherits the styling etc. On the other hand we have some pages we want to specifically order structure and put footnotes always in the same place. In such case, hiding individual footnote groups is ideal in combination with rendering the block with all the footnotes grouped. This is the case where node type structure is not fluid and we don't use Paragraphs or have combination of standard fields with Paragraphs.

Regardless of our use case, original module doesn't allow different behavior per node type which seems a bit limiting to me.

Now it's late for me but I will consider your suggestions, and also when I have time I will try to spend some time converting patch into MR and covering tests. But this makes sense only if you or others too see some sense in my reasoning for this feature request.

Thanks again for the nice module.

Aha I see, so still multiple formatted text on the page, then the first option probably won't work as you are after multiple outputs of the block then. These two options might work though:

Or alternatively you duplicate the text format with the alternative configuration and for the different node bundles, use different formats.

Paragraphs for example lets you select form mode, so you could still share the Paragraph Types and have two form modes, one with text format outputting footnotes immediately, one with text format outputting as a block. Then in manage form display of those node bundles, choose the appropriate form mode. You might need Form Mode Manager module to actually create the additional Form Modes within the Paragraph Type though, not 100% sure.

Or even add cache context if node bundle and do a conditional config override (not sure if that's feasible).

The cache context bit you can avoid in local by disable all cache so you can at least test. I think you would create a config override service like this https://www.drupal.org/docs/drupal-apis/configuration-api/configuration-... → and override based on the node bundle by getting the node from the Drupal Route Match service -> getParameters. Then you can override the text format's config contextually in theory (docs there seem to suggest it should work). Actually this may be enough when caching is turned back on if the service auto-applies that, but if it doesn't you may need to preprocess the field and add a new cache context to the render array of the field. IpCacheContext is an example in Core that could help; and again getting node bundle instead of IP address from the route.

I would suggest you try these options first. I am definitely open to building something into the module, but varying on node bundle is just one particular case, whereas others may want to vary by something else. If the above does not help, then to convert to MR easiest I find is to:

1. cd web/modules/contrib
2. rm -rf footnotes
3. git clone git@git.drupal.org:project/footnotes
4. cd footnotes
5. (run the commands suggested once you click 'Create issue fork' in this issue)
6. wget (link to patch) <- download patch into the root of footnotes folder
7. git apply (patch filename) <- apply patch to the merge request
8. rm (patch filename) <- delete the downloaded patch

Then when you're done pushing the change, you can either leave your local on the branch to deal with further amends, delete the footnotes dir again and run composer install to bring your local back to match. This is normally how I work on contrib modules; I find it easier to work in place of an existing project like this so I can test and build to a real-world scenario. The wget/git apply steps I normally don't do though as I'd go straight to merge request via the create issue fork. Just my own workflow, hope it helps!