Problem/Motivation

It seems on a giant publication (we have one with 1,400+ citations) the random string in the footnote references can diverge from that used in the citations. It appears this came in from the initial 4.x commit and patches leading to that, so is hard to trace back.

Steps to reproduce

Giant content item with huge number of citations

Proposed resolution

  1. Attempt removing the random string, replacing with something deterministic based on the current content.
  2. Get feedback from wider community whether this continues to work fine.
  3. Possibly this could be a configuration option rather than a change to default behaviour...

Remaining tasks

MR

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Issue fork footnotes-3572013

Command icon Show commands

Start 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:

Comments

scott_euser created an issue. See original summary.

scott_euser’s picture

Status: Active » Needs review
scott_euser’s picture

Status: Needs review » Needs work

Seems like legitimate test failures...

scott_euser’s picture

Title: Consider removing citation appended random string from FootnotesFilter » Make citation appended string deterministic instead of random so it is consistent across requests for the same URL
Issue summary: View changes
scott_euser’s picture

Status: Needs work » Needs review

Okay tests passing now

scott_euser’s picture

Status: Needs review » Needs work

Via such a giant report, quite a rabbit hole and dates back to the original footnotes grouping solution to handle multiple formatted text instance originally targeting 3x branch, but converting things to static. Moving back to NW as this is going to need more test coverage for such scenarios as clearly some areas not sufficiently covered.

scott_euser’s picture

Status: Needs work » Needs review

Okay added some more test coverage to this now as well to areas it potentially affects

jan.fetalvero’s picture

Assigned: Unassigned » jan.fetalvero
jan.fetalvero’s picture

StatusFileSize
new158.39 KB
new76.29 KB
new88.54 KB
new2.18 MB

Tested on:

Drupal: 10.x
PHP: 8.x
Branch: 3572013-random-string (MR !96)

Testing process:
Created a test node with 500 footnotes to stress test the fix. Disabled the render cache to bypass Drupal caching so the filter runs on every request.

Node with 500 footnotes:
node

On the 4.0.x branch:
The footnote anchor IDs contain three parts a hash of the content, plus a trailing random string (e.g. rMl0OUTKAU0r) that is different on every single render:id="footnoteref__MTx1WlRHW4R9vYOCTc9ymjiqo14pWER6-cMMosmYo0_rMl0OUTKAU0r"
4.0.x

On the 3572013-random-string(MR !96) branch:
The random string is completely removed. The ID is now built only from the footnote number and a hash of the citation text:
id="footnoteref__MTx1WlRHW4R9vYOCTc9ymjiqo14pWER6-cMMosmYo0_1"
MR96
Running the render multiple times produces identical IDs every time — the citation href and reference id always match.

Automated tests:
34/34 tests pass
5 JavaScript browser tests skipped
0 failures, 0 errors
test

Fix confirmed working. Setting to RTBC.

jan.fetalvero’s picture

Assigned: jan.fetalvero » Unassigned
Status: Needs review » Reviewed & tested by the community
scott_euser’s picture

Thank you very much for the thorough review, I know its quite time consuming, so really much appreciated. Because its quite big will still give it some more time; I'll set a reminder for about a month from now.

  • scott_euser committed 8fbd77ea on 4.0.x
    fix: #3572013 Make citation appended string deterministic instead of...
scott_euser’s picture

Status: Reviewed & tested by the community » Fixed

Thanks again! Will leave this in dev for some time, then beta, then hopefully we can get to a more stable release.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

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