create new tag
, view all tags

Bug: specificLink() incorrectly removes underscores from anchors

%TOC% creates anchor names with trailing underscores in many cases. If you make a specific link to these anchors with something like [[#underscoredanchor_][foo]] the underscore will be truncated and the anchor will be useless. This is because specificLink() passes the anchor through internalLink() which then passes it through makeAnchorName() even though it is already a valid anchor. The solution for this is to test for valid anchorness in internalLink() before calling makeAnchorName() (or, even better, having makeAnchorName() return its input if the input is already a valid anchor name). I have fixed this with a hack but wanted to know if there was some rationale for this behavior.

The fix is very simple:

at line 2364 or so:

my $anchor;
$theAnchor =~ /($anchorRegex$)/;
if( $theAnchor eq $1 ) {
      $anchor = $theAnchor;
      $anchor =~ s/^#(.*)/$1/g;
} else {
             $anchor = makeAnchorName( $theAnchor );

instead of just willy-nilly running my $anchor = makeAnchorName( $theAnchor ); I think putting this behaviour in makeAnchorName() would be even better.

Test case

See AnchorBugExample


TWiki version: TWikiRelease01Feb2003
TWiki plugins: DefaultPlugin, EmptyPlugin, InterwikiPlugin
Server OS: N/A
Web server: N/A
Perl version:  
Client OS:  
Web Browser:  

-- ZacharyHamm - 09 Jan 2004

Follow up

Thanks for spotting this - certainly seems that it should be OK to call makeAnchorName just once, by checking the $anchorRegex, but it requires a bit of thought. I had a look at this and added a simple condition, but then decided it needed a lot more testing. A real-life instance of this bug is near the end of InternationalisationEnhancements, where I linked to InternationalisationEnhancements#Localisation_L10N_longer_term_

-- RichardDonkin - 10 Jan 2004

Fix record

I've made a change to makeAnchorName that causes it to be consistent when called upon an already-valid anchor. It produces different results than it did before, but now if you call it on a pre-screened anchor it shouldn't mangle it further. You'll have to adjust your [<nop[#__silly_header_with__lots__of__punctuation]] links to the new results, which will look more like [[#silly_header_with_lots_of_punctuation]]. I believe that was the intended result of makeAnchorName to begin with; at least it makes much more sense to me.

-- WalterMundt - 22 Feb 2004

Update: Fixed a case where one could still end up with trailing underscores, defeating the purpose, thanks to some advice from MS. Based on suggestions from same, I've also put in code that will generate old-style header anchors along with the new ones, so that people using HTML links to get around this problem won't have their content broken. Finally, I've done as you suggested and put this logic directly into makeAnchorName.

-- WalterMundt - 22 Feb 2004

TopicClassification BugResolved
TopicSummary The makeAnchorName function did not produce the same results if called iteratively, resulting in problems trying to link to headers.


AssignedToCore WalterMundt
ScheduledFor CairoRelease

SpecProgress 100%
ImplProgress 100%
DocProgress 100%
Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r4 - 2004-02-22 - WalterMundt
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.