Footnote IDs have random strings added since #194558: Non-unique list item IDs in order to avoid duplicate IDs on pages which contain more than one block of formatted text with footnotes.
Since #3572013: Make citation appended string deterministic instead of random so it is consistent across requests for the same URL the IDs are stable as long as the reference text is the same. If the text changes, the anchor link to the reference changes.
In some cases, users are confident that they will never insert new footnotes between other footnotes (thereby changing the auto-number) or are never using auto-numbers, and they would prefer therefore to just have the anchor link match the citation ID or manually inserted citation text.
Add an option to the filter configuration to remove the hashed text portion of the anchor link altogether and just use the citation (or citation with suffix if identical and not collapsed).
New option in filter configuration
N/A
N/A
| Comment | File | Size | Author |
|---|
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
john_b commentedAttached patch adds a checkbox which makes the addition of a radom string to each footnote ID optional. Patch for current dev, does not apply to 3.1.0.
Comment #3
rudolfbykerI also need this. Alternate solution: Use an ID like `node-x-footnote-y` where x is the node ID and y is the footnote's ordinal or value.
Comment #4
scott_euser commentedCan switch away from random as long as its unique, e.g. perhaps as @rudolfbyker noted (though I haven't look in depth at implications). In any case needs MR + test coverage to match. Thanks!
Comment #5
scott_euser commentedComment #8
scott_euser commentedOkay got a chance to hit this issue myself and I I like the suggestion in #4. Since status quo is always random, nobody could yet have a dedicated link to a specific footnote, so I don't think we need to make this opt-in/opt-out. Added comments to the MR to make it clear.
Comment #9
scott_euser commentedOkay this is now ready, let me know if it works for you
Comment #10
dieterholvoet commentedFor me this fixes the issue where links from citations to grouped references at the bottom of the page weren't working anymore.
Comment #11
dieterholvoet commentedNever mind, that doesn't fix it. I now have citations that link to
#footnote1, while the footnote has an ID offootnote1-0. That's on a page with multiple text areas with footnotes and with all of them aggregated at the bottom of the page. This issue might be caused by the fact that the same footnote is referenced multiple times on the same page.Comment #12
scott_euser commentedTo note, in another issue #3572013: Make citation appended string deterministic instead of random so it is consistent across requests for the same URL I have been working on making them deterministic at least; so still having an appended suffix, but reliably the same (unless the content changes). That seems to have sorted a number of issues for us in a publication with ~1400 footnotes here: https://internationalaisafetyreport.org/publication/international-ai-saf... - worth considering for those following this issue? It could render this feature redundant as I think that approach gives best of both worlds BUT it still has the hash of the text which would change if the text changes (but then even with this one, with auto-numbering if you add a new footnote, you'd break links or be linking to wrong thing).
Comment #13
john_b commentedOur problem is that content creators have shared links to footnotes from way back assuming the IDs can be stable. Our old content does not change. A new system of deterministic links would be fine going forward but would be a problem for old links.
Comment #14
scott_euser commentedMaybe another checkbox/option in the Filter config to opt out of it then?
Can have a seperate follow-up issue later to eg group them into fieldsets or something to make the UI. a bit more obvious (e.g. advanced options type thing)
Comment #15
scott_euser commentedOkay I have updated the issue summary to be more clear and reflect the current state + what I'd consider the proposed resolution. Please comment if you agree and for those who are after the feature, feel free to contribute the merge request, I'd be happy to review and check.
Comment #20
scott_euser commentedHere's a quick draft of this, I tested with an auto-value + a set value on a clean install and it worked okay, but it definitely needs a more real-world test.
Comment #21
scott_euser commentedI'd ideally like to get this in the next release. Can one of the followers requesting this please take a moment to review. Would be greatly appreciated!
Comment #22
john_b commentedThis is working on an established site with many footnotes. I looked at the code.
Comment #24
scott_euser commentedThanks for confirming. Also updated to use existing method to avoid regressing on #3590374: Warning when > 26 footnotes on page in this scenario (a - z, aa, ab, etc). Added further test coverage of this via display via block as well in case.