You will always jump to the headline that occurs first, that is if you click on "Results" for the second experiment you will get the "Results" of the first.

Example:

Experiment 1

Parameters

text text text text text text text text text text text text text text text text text text text text text text text text text text text

Setup

text text text text text text text text text text text text text text text text text text text text text text text text text text text

Results

text text text text text text text text text text text text text text text text text text text text text text text text text text text

Experiment 2

text text text text text text text text text text text text text text text text text text text text text text text text text text text

Parameters

text text text text text text text text text text text text text text text text text text text text text text text text text text text

Setup

text text text text text text text text text text text text text text text text text text text text text text text text text text text

Results

text text text text text text text text text text text text text text text text text text text text text text text text text text text

heading 2

this heading has a hand coded anchor of heading_1, which should be respected, causing the next anchor to be different.

heading 1

-- MD

TWiki never suported that. Reprioritized as Enhancement.

See TWiki:Codev.TocFailsForIdenticalHeadingNames, TWiki:Codev.TocUniqueName, TWiki:Codev.TocBreaksOnIdenticallyNamedSections

-- PTh

Cleaning up old enhancement topics on Codev.

This old enhancement is still valid and has an accepted feature implementation proposal behind it: TWiki:Codev.TocFailsForIdenticalHeadingNames

The proposal topic also describes how it should be implemented to maintain compatibility with old links people may point to from other web pages.

Scope is GeorgetownRelease. Committed developer is Harald

-- KJL 24 Dec 2007

Reported also in Item5205

-- TWiki:Main.MichaelDaum - 04 Jan 2008

also TWiki:Codev.MultipleAnchors.

-- TWiki:Main.SvenDowideit - 11 Jan 2008

I do now know why this became an enhancement bug. They never get looked at.

Setting to Normal

reported again as Item5878

-- TWiki:Main.KennethLavrsen - 04 Aug 2008

I attached a patch which follows the first proposal from TWiki:Codev.FixAnchorHandling (patch_item1607_rev17405.txt) -- still buggy, see below.

It's a quick workaround, but shouldn't break anything that wasn't broken before. Since it will take some time before I'm able to make an attempt to implement the fourth proposal (unless someone else is faster :)), and this issue hasn't been addressed for a long time, maybe this should be committed to trunk in order to force those unhappy with this solution to come up with a better one?

(I have to confess that I didn't look at the existing unit tests long enough to get an idea how to properly test this)

-- TWiki:Main.MarkusUeberall - 11 Aug 2008

NB patch_item_1607_rev17405.txt still has a(t least one) flaw--the generated unique anchor names don't always match because Render.pm 'allocates' them using substitutions ( headerPatternHt followed by headerPatternDa) while TWiki.pm processes page contents line by line, thus processing both regexps 'simultaneously'). I'm currently testing a revised patch.

Update: cf. attached patch_item1607_rev17409.txt -- superseded, see below.

-- TWiki:Main.MarkusUeberall - 12 Aug 2008

The attached third revision of the patch (patch_item1607_rev17409_r2.txt) is optimised w.r.t. TWiki::_TOC and also disambiguates "#WikiWord" anchors. Since the latter are presumably user-defined, they are now converted first in order to retain their original form if possible in case they clash with autogenerated anchors (cf. Render.pm).

This patch introduces Render::makeUniqueAnchorName($anchorName, $compatibility) -> $anchorName (the functionality cannot be added to the existing makeAnchorName(.), because AFAIK it's impossible to ensure that this method isn't called in order to build a reference (which obviously would never match an existing anchor)--or is it?)

-- TWiki:Main.MarkusUeberall - 12 Aug 2008

What the hell? so, this breaks the nightly unit testruns, and thus stops releases from being built, and is marked as commted to the next major release, and yet its been commited to the 4.2.x branch too? ffs.

-- TWiki:Main.SvenDowideit - 11 Sep 2008

firstly, there are 3 Testcases that fail - but I think they point to something more worrying. It looks like if a user intentionally inserts the html for a name anchor, this code will disregard it and change it to whatever it wants (if it finds a conflict - see heading 2, which has html for a name='heading_1' anchor)

• disregards it, but doesn't change it (unresolved anchor clash in 'html case', see below) --mue, 14 Sep 2008

I don't (yet) feel this is a good idea, as hardcoding an anchor would be the way for a user to ensure the long term usefulness of an anchored url.

-- TWiki:Main.SvenDowideit - 11 Sep 2008

I corrected TargetRelease (forgot about that). If a user intentionally inserts an anchor using TML, this is given precedence--unless he uses the same name twice, in which case the change doesn't break anything that wasn't broken before (see the note in the code that he should be informed about it in this case; however, I still haven't had an idea how to do this without ruining the visual formatting).

• apparently this is incorrect. the heading 2 that I added above with an anchor of heading_1 gets changed. (I am not using that anchor twice, and the code seems to me to ignore the user's choice of anchor when ever there is a clash.)- SD

Could you point me to the three testcases in question?

• SemiAutomaticTestCaseTests::test_TestCaseAutoFormatting, SemiAutomaticTestCaseTests::test_TestCaseAutoIncludeAttachment, SemiAutomaticTestCaseTests::test_TestCaseAutoTOC. note that they do not directly show the bug I am talking about here, that I found just while poking the code with a stick.- SD

-- TWiki:Main.MarkusUeberall - 11 Sep 2008

I'm pretty close to reverting the change (in the 4.2 branch) so I can get 4.2.3 out the door with fewer surprises, I've already spent too much time just tracking down and trying to work out if the issue was intentional.

-- SvenDowideit - 11 Sep 2008

I see both the problem and a possible solution, but this is a bit expensive. Basically, inserted HTML code is not inspected for anchors/at all (clearly these won't pass the subroutine mentioned above). This could be done in an extra loop while TML markup is still available (once the page is rendered, there's no way to distinguish user- and plugin-generated html code). IMHO, if one intentionally mixes "raw" HTML with TML, one should better make sure that there's no such clash by using some sort of artificial name prefix (e.g., "user__" or "mue__")--the other way round (always prefixing generated anchors) was frowned upon because that would break existing installations.

(btw, this shouldn't have come as a surprise, because this modification has been discussed in a release meeting, it refers to an accepted proposal that has been around for months and the patch has been made available quite some time before it had actually been committed. The fact that this particular issue keeps getting reported again and again--I actually opened the fourth or fifth bug report--lead to the commit 4.2.x branch to get it out faster; the clash with "raw" HTML anchors is actually the only possible side effect I can think of now after I've seen it).

-- TWiki:Main.MarkusUeberall - 11 Sep 2008

btw, the simplest solution to prevent a clash in your case would be to change the algorithm which generates unique names, but (NB: I misread the example; Sven's point here was not to demonstrate that auto-renamed anchors using the original suffix would easily clash as discussed below (which was the case), but that the change does not prevent name clashes w/ anchors defined in 'raw' html blocks, which is discussed above --mue, 14 Sep 2008)

It's hard to come up with a delimiter nobody uses (underscores may not be the best choice as I saw from your example, though). Maybe we should use "<>" (url-encoded) instead?

• Update: Unfortunately, according to the W3C validator, this won't work w.r.t. the standard (though Firefox doesn't care): character "%" is not allowed in the value of attribute "name"
  My next best suggestion would be to use "_autorenamed" (it's a bit long which means it 'eats' a bigger part of the original name, but nobody should insert this kind of anchor manually, eh?)
  • Update2: Committed the suffix change with TWikirev:17506, TWikirev:17507 --mue, 12 Sep 2008
  • Update3: Changed suffix to "_AN" (cf. discussion on the [TWiki-Dev] mailing list) --mue, 14 Sep 2008

-- TWiki:Main.MarkusUeberall - 11 Sep 2008

I changed to status to "waiting for release". I verified, this is implemented in trunk and 4.2 branch!

-- TWiki:Main.PeterThoeny - 16 Feb 2009

closing this after TWiki 4.3.0 release

-- TWiki:Main.SopanShewale - 06 Apr 2009