Bug: The header anchor name is wrong when a link occurs in the header

DEVELOP branch.

Test case

Create a h1 header with the name of the topic. Part of the link is copied into the anchor text.

Like:

This is a header with a link: HeaderAnchorNameWrongWhenLinkInHeader

Environment

-- ArthurClemens - 05 Jul 2005

Follow up

Same as HeaderRenderingWithWikiWordsBroken. See Bug filed

-- PeterNixon - 05 Jul 2005

Fixed on DEVELOP branch.

-- PeterNixon - 06 Jul 2005

These 2 bugs are not the same. See: http://visiblearea.com/devtwiki/bin/view/Sandbox/HeaderTest (fresh install from SVN 4538).

Something strange also happens with http://develop.twiki.org/~develop/cgi-bin/oops/Bugs/Item72?template=oopsattention;def=mandatory_field;param1=Summary

The h2 header gets rendered as:

<h2><a name="Attention_div"></a><a name="_Attention_div_"></a> <div class="twikiAlert"> <strong>Attention</strong> </div> </h2>

-- ArthurClemens - 06 Jul 2005

I copied your HeaderTest test case into a fresh SVN 4540, and it seems to be rendering correctly; it should have been OK since 4533. Did you have an svn update conflict?

I see a different problem with Item72; the h2 gets rendered like this:

<h1><a name="Topic_Save_Error"></a><a name="_Topic_Save_Error"></a> ---++ Topic Save Error </h1>

Is that what you meant?

-- PeterNixon - 06 Jul 2005

BTW, both problems you're seeing don't appear to be there as of 4540.

-- PeterNixon - 06 Jul 2005

Strange. I did a fresh SVN checkout on 4540. Put it on my server. Still seeing the bug.

-- ArthurClemens - 07 Jul 2005

Is anyone else seeing this behavior?

-- PeterNixon - 07 Jul 2005

I ran configure (for the first time) and that made the bug disappear.

-- ArthurClemens - 07 Jul 2005

I'm seeing the problem now also, after being a bit more careful. The problem is bare WikiWords in headers, not just forced square-bracket links. I dug into it, and noticed that by default TWiki::cfg{Site}{CharSet} is undefined. When it's set, anything in the header that's not TWiki::regex{mixedAlphaNum} is substituted with an underscore (_), so that a header like this: a WikiWord in a header becomes a_WikiWord_in_a_header, so the WikiWord isn't rendered. Looks like configure does that. here's a patch to make sure CamelCase words are prefixed with underscores, regardless of the character settings:

Index: lib/TWiki/Render.pm
===================================================================
--- lib/TWiki/Render.pm (revision 4542)
+++ lib/TWiki/Render.pm (working copy)
@@ -353,8 +353,10 @@
        return substr($anchorName, 1);
     }
 
+    # strip out potential links so they don't get rendered.  Screws up header rendering.
     $anchorName =~ s/\s*\[\s*\[.*?\]\s*\[(.*?)\]\s*\]/$1/og; # remove double bracket link 
     $anchorName =~ s/\s*\[\s*\[\s*(.*?)\s*\]\s*\]/$1/og; # remove double bracket link
+    $anchorName =~ s/($TWiki::regex{wikiWordRegex})/_$1/go; # add an _ before bare WikiWords
 
     if ( $compatibilityMode ) {
        # remove leading/trailing underscores first, allowing them to be

-- PeterNixon - 08 Jul 2005

Also discovered hard-coding links in a header like this:

---+ <a name="some name"></a> A Test Header With An Anchor In It.

causes the TOC not to be built correctly. Here's a patch for that as well:

Index: lib/TWiki.pm
===================================================================
--- lib/TWiki.pm        (revision 4542)
+++ lib/TWiki.pm        (working copy)
@@ -1493,6 +1493,8 @@
             $line =~ s/([\s\(])($regex{webNameRegex})\.($regex{wikiWordRegex})/$1<nop>$3/go;  # 'Web.TopicName'
             $line =~ s/([\s\(])($regex{wikiWordRegex})/$1<nop>$2/go;  # 'TopicName'
             $line =~ s/([\s\(])($regex{abbrevRegex})/$1<nop>$2/go;    # 'TLA'
+           # Prevent manual links
+           $line =~ s/<[\/]?a\b[^>]*>//gi;   
             # create linked bullet item, using a relative link to anchor
             $line = $tabs.'* '.
               CGI::a( { href=>$urlPath.'#'.$anchor }, $line );

-- PeterNixon - 08 Jul 2005

These patches are back in SVN now.

-- PeterNixon - 08 Jul 2005

Fix record

DEVELOP branch seems to be functioning ok. Moving this to ReadyForMerge.

Discussion