Item8592: Broken TOC link for headings that contain !

On trunk...

TwistyPlugin contains this heading:

---+++ Other use: hide interface parts in case of no !JavaScript

The rendered heading contains this anchor:

<a name="Other_use:_hide_interface_parts_in_case_of_no_JavaScript"></a>

The rendered %TOC% contains this link:

<a href="#Other_use:_hide_interface_parts_in_case_of_no_33JavaScript">

Note the extra 33 before JavaScript in the TOC link anchor name. The TOC link does not work because the link and anchor use different names.

-- MichaelTempest - 21 Feb 2010

I spend a significant part of my life fixing TOCs in (tm(wiki and Foswiki 1.0.

And it works great now in 1.0. Also with escaped wikiwords.

Then someone seems to have refactored the TOC code on trunk and reintroduced some of the bugs that I closed. I can only wonder why it had to be changed? What was broken?

I have a test topic I created for this. It even works in russian.

http://merlin.lavrsen.dk/foswiki10/bin/view/Myweb/TocTest

and same in trunk

http://merlin.lavrsen.dk/trunk/bin/view/Myweb/TocTest

and it seems all the test cases I did pass EXCEPT the escaped wikiword case. So it must be a nont too difficult one to fix.

But what more is broken?

-- KennethLavrsen - 22 Feb 2010

I don't know, and I'm not sure why this report was left open; as unit test test_Item8592 in TOCTests.pm shows, the original problem reported works fine, so I'm closing it. Maintaining unit tests is the way you protect code against adverse effects from refactoring. I have simplified the TOC tests to make that even easier.

-- CrawfordCurrie - 18 Apr 2010

I have reopened the task because there is still a problem with the same TOC link on http://trunk.foswiki.org/System/TwistyPlugin - search for "Other use" (either in the normal rendering or in the HTML source) to see the problem - that text only occurs in the heading that demonstrates the problem.

-- MichaelTempest - 19 Apr 2010

I believe there are related issues to encoding of anchors in trunk. It is especially noticeable with PerlDoc?module=Foswiki::Func. All links with special characters are broken. For example,

branch

getSkin( ) -> $skin encodes to #getSkin_skin

trunk

getSkin( ) -> $skin encodes to #getSkin_40_41_45_62_36skin in the TOC link, but the actual anchor is #getSkin_40_41_45_36skin The &gt - greater-than is omitted from the anchor, but not the link.

There seem to be a number of differences in how anchors with special characters are encoded, resulting in broken links in the toc. For example, both of the below headings create broken TOC links:

---++ Test (){}[]_-+!<>~$  -  TOC:  #Test_40_41_123_125_91_93_45_43_33_60_62_126_36   Anchor: Test_40_41_123_125_91_93_45_43_33_126_36
---++ Test <(){}[]_-+!>~$  -  TOC:  #Test_60_40_41_123_125_91_93_45_43_33_62_126_36   Anchor: Test_40_41_123_125_91_93_45_AN1

I also confirm that ! when used to escape a WikiWord from a heading results in the ! encoded in the link, but not in the anchorl

Wasn't there an objective at one point that anchors should not change between releases if possible - to help preserve permanent links? In branch, all of the specials are simply substituted for a single underscore.

-- GeorgeClark - 26 Apr 2010

I believe I've fixed the primary issue caused by encoding the ! when used to escape a WikiWord. Other issues caused by removing unmatched < from the anchor rather than encoding it still remain. I've added another unit test to separate out encoding of the anchor names from building of the links and references. Remaining problems appear to be in the building of the

 <a name="..."> 

link and not in the encoding of the anchor name.

-- GeorgeClark - 28 Apr 2010

It appears as though when render builds the anchor, the < and > have been already encoded as html entities and are removed from the anchor text, but when the TOC links are built, they are not encoded, so they remain. One possible fix is to convert the & lt and $ gt back to the un-encoded characters when building the unique anchor name, but there may be other consequences. Will commit this fix for testing.

-- GeorgeClark - 28 Apr 2010

I can't comment on the < / > problem, but the ! problem is certainly fixed. Thanks, George!

-- MichaelTempest - 29 Apr 2010

Commenting is disabled while not logged in