Parsing internal wiki link to footnote generates incorrect URL

[dregad]

Direct link to footnote

• works OK when using the full URL
• with wiki internal link [[#fn__1]] the double underscore __ is replaced by a single one in the generated link so it does not match the actual anchor

Example: https://www.dokuwiki.org/sandbox:footnote_link

[dregad]

This problem still exists today. Here is the root cause analysis.

The link is processed here in \Doku_Handler::internallink()

dokuwiki/inc/parser/handler.php

Lines 880 to 885 in 95078f2

	// internal link
	$this->addCall(
	'internallink',
	[$link[0], $link[1]],
	$pos
	);

resulting in the following stack trace

pageutils.php:126, cleanID()
pageutils.php:251, sectionID()
renderer.php:877, Doku_Renderer->_headerToLink()
xhtml.php:851, Doku_Renderer_xhtml->locallink()
parserutils.php:691, p_render()
[...]

and of course cleanID removes repeated separator characters _, causing the problem

dokuwiki/inc/pageutils.php

Line 160 in 95078f2

$id = preg_replace($sepcharpat, $sepchar, $id);

I'm not sure what the proper fix should be. Since we know that it's an internal link, do we actually need to call _headerToLink() ? After all the input is NOT a header so would it be OK to just get rid of line 851 ? Or am I missing something ?

dokuwiki/inc/parser/xhtml.php

Lines 847 to 852 in 95078f2

	public function locallink($hash, $name = null, $returnonly = false)
	{
	global $ID;
	$name = $this->_getLinkTitle($name, $hash, $isImage);
	$hash = $this->_headerToLink($hash);
	$title = $ID . ' ↵';

[dregad]

Still not fixed in Kaos. If someone who knows better can answer my question, I will gladly submit a PR.

I'm not sure what the proper fix should be. Since we know that it's an internal link, do we actually need to call _headerToLink() ? After all the input is NOT a header so would it be OK to just get rid of line 851 ? Or am I missing something ?

[michitux]

The intended purpose of this kind of link syntax is to link to a heading in the page. The code applies the same transformation as for heading IDs such that the user can simply supply the text of the heading and the code ensures that the link points to the heading.

Other IDs in DokuWiki are intentionally not following the pattern for heading IDs to ensure that they won't conflict with the ID of any heading.

I don't know which IDs would be worth supporting in addition to headings. If footnotes are the only ones, the code could check if the supplied text matches the pattern of a footnote ID and use it directly. I think the double underscore pattern is quite frequent in IDs outside of headings so checking for that could also be an option but this could more easily break a link that should actually point to a heading.

[dregad]

Many thanks for the feedback.

I never realized until you mentioned it that it was possible to make links like [[#this is my header]] to have it jump to the === This is my Header === section... Nice ! For all these years I have been previewing the page, copy/pasting the link from the TOC and inserting the anchor it where I needed it 😕

This feature is probably more important and widely used than my need to reference an existing footnote, and it probably should not be touched.

So if I understand correctly, achieving what I need may require introduction of a new type of links, e.g. footnotelink in the parser (Doku_Handler::internallink()), detecting the /fn__\d+/ pattern, is that correct ? Would that make sense, and is it something that you would consider ?

Alternatively, what about introducing a specific syntax to reference a footnote, like ((nn)) where nn is an existing footnote's number ?

Some text ((this is my footnote)
More text ((1))

Which could render like this

Some text ¹
More text ¹
___
¹ this is my footnote

Let me know what you think.

[dregad]

Note: I am aware that I can do

Some text ((this is my footnote))
More text ((this is my footnote))

And it will generate a single footnote with 2 references

Some text ¹
More text ²
___
¹ ² this is my footnote

What I'm trying to avoid is duplication of the footnote's contents.

[fiwswe]

Whenever you insert or remove a footnote the numbering will be adjusted for all following footnotes. Thus permalinks that contain the number of the footnote are not really very useful (unless they are used and maintained automatically).

What you would need is some (user provided) unique id in the footnote syntax. For example something like this (the exact syntax probably needs work):
((##<myid>## <footnote content>)) I'll call this the defining footnote.
The default id would continue to use the fn__nnn naming system. The manual id would override this for a particular footnote. So the old ((<footnote content>)) syntax would continue to work.
Then you might use that ID in two ways:

• ((#<myid>)) Special case only works if the )) immediately follows the id. Equivalent to repeating the same footnote content from the original footnote. I'll call this the dependent footnote.
• [[#<myid>]] or possibly [[#fn__<myid>]] A direct link to the footnote which assumes that its id attribute is set with this value (and that this value is unique on the page).

Issues:

• Problems might arise when later editing a page. For example when deleting the original defining footnote, what should happen to the dependent footnotes?
  • Similarily when copying sections of one page to another, the original defining footnote might be missed.
• Guaranteeing the uniqenes of the ids is problematic.
  • Conflicts with anchors automatically generated from headers need to be avoided as well.
• What should happen when the defining footnote is placed after a dependent footnote on the page?

[splitbrain]

@fiwswe summarized the challenges pretty well. DokuWiki's default syntax for footnotes is deliberately simple and I would prefer to keep it that way. For more complex footnotes, I used the refnotes plugin in the past.

[dregad]

OK I understand.

Thanks to all for taking the time to reply, and @andi for the pointer to the refnotes plugin, I'll check it out.

[fiwswe]

@dregad I took a brief look at the RefNotes Plugin documentation. While it does not seem to solve all of the potential issues it does allow for named footnotes that don't need to be repeated (see Multiple references and Named notes). So they may solve your basic problem. I have been annoyed by having to repeat footnotes as well, but I could not come up with a good solution.

[dregad]

Thanks for the follow-up @fiwswe, I appreciate it. Looks like this plugin will precisely meet the requirement.