Links within footnotes break the footnote

[amphibian]

Describe the bug

When adding links to footnote text, either before or after creating the footnote (turning it into a <sup> element), the links is wrapped in its own <sup>, and any text before and after is wrapped in their own <sup> elements.

Steps to reproduce

1. Add a link to part of a string which you want to turn into a footnote.
2. Turn that text into a footnote.

Craft CMS version

5.7.1.1

Plugin version

5.1.0

Multi-site?

No

Additional context

No response

[engram-design]

I'll see what can be done about this, but I believe it's largely due to how CKEditor handles the sup element and other tags like an anchor tag. Secondly, it's also a little tricky in that footnotes are themselves considered to be links.

We're probably going to have to revise how the footnotes are handled anyway to address this. Rather than relying on using a <sup> element, it'll probably end up being similar to a link node where you can add whatever content you like.

[amphibian]

Thanks for the explanation Josh, sounds tricky. It's too bad CKE handles things so differently, as I was using links inside footnotes without issues in the Redactor version.

[amphibian]

Just discovered on a current project that any inline markup breaks the footnote in the same manner (e.g. bold, italics, etc). Given that things like publication titles are frequently inside footnote/endnote content, and those are routinely italicized, this issue is wreaking more havoc on me than I thought!

[engram-design]

Yeah, I'll need to figure this one out sooner rather than later, and rethink my approach. Will keep you posted (just not going to be a quick fix!)

[mmikkel]

Ran into this too. For now, I chose the nuclear option – a regex that unwraps the <sup class="footnote"> elements:

$html = preg_replace_callback(
    '#<(\w+)[^>]*>\s*(<sup\s+class="footnote">.*?</sup>)\s*</\1>#i',
    function ($matches) {
        return $matches[2];
    },
    $html
);

[d-karstens]

Hi, was there any update on this? Have also just run into the same issue

[engram-design]

Haven't had the chance to look at this, but it's essentially a brand-new implementation I need to look at.

[amphibian]

For others following, the route I've decided on for now is to instruct my clients to use markdown for formatting within each footnote, and then I apply the markdown filter to the footnotes in-template.

[AdamChlan]

Just noting that we recently discovered this is impacting a client site as well. Looking forward to a resolution.

[smonist]

Hey, this issue broke a client website - they were using italic tags inside footnotes all the time. Is there any way to fix this that does not involve going through every footnote individually?

[AdamChlan]

Hello, curious if this is still on the roadmap in 2026?

[engram-design]

Yeah, it's going to need a full plugin rewrite I think, with a whole new UI for managing footnotes. There's plenty I want to improve on this plugin compared to what I've inherited from the previous developer, including the Twig API.

Absolutely on our roadmap this year though.

[engram-design]

We've got a revamped behaviour for the next release. To get this early, run composer require verbb/footnotes:"dev-craft-5 as 5.1.3".

Instead of a simple <sup> element with content inline with the rest of content, and tough to edit, it's now hidden behind an auto-computing number, which is edited in a popover much like a link. It should handle the formatting issues noted in this thread. Rendering of the footnotes in Twig remains unchanged.

It should handle your current legacy <sup> elements automatically, so there's nothing you need to migrate or convert.

[engram-design]

Updated in 5.2.0.