Bug: TOC Link URI References are not Relative
The links generated by the TOC variable do not use URI references with relative paths.
Although the URI references are relative (not containing scheme or authority
portions), their URI paths are absolute, for example:
<a href="/twiki/bin/view/NCES/NameResolutionViaHTTPProxyInterface#Summary">Summary
instead of
<a href="#Summary">Summary
The links should use relative paths so that those internal table-of-contents
links work in an offline copy of a topic's page.
Test case
Environment
--
DanielBarclay - 05 Dec 2003
Follow up
I tend to agree.
Here is a patch for Twiki.pm
*** TWiki.pm~ Sat Mar 20 04:57:38 2004
--- TWiki.pm Fri Apr 9 03:28:44 2004
***************
*** 2343,2355 ****
$line =~ s/([\s\(])($regex{wikiWordRegex})/$1<nop>$2/g; # 'TopicName'
$line =~ s/([\s\(])($regex{abbrevRegex})/$1<nop>$2/g; # 'TLA'
# create linked bullet item
! # AB change
! # $line = "$tabs* <a href=\"$dispScriptUrlPath/$viewScript$scriptSuffix/$webPath/$topicname#$anchor\">$line</a>";
! if ( $viewScript eq 'view' ) {
! $line = "$tabs* <a href=\"$dispScriptUrlPath$dispViewPath/$webPath/$topicname#$anchor\">$line</a>";
! } else {
! $line = "$tabs* <a href=\"$dispScriptUrlPath/$viewScript$scriptSuffix/$webPath/$topicname#$anchor\">$line</a>";
! }
$result .= "\n$line";
}
}
--- 2343,2359 ----
$line =~ s/([\s\(])($regex{wikiWordRegex})/$1<nop>$2/g; # 'TopicName'
$line =~ s/([\s\(])($regex{abbrevRegex})/$1<nop>$2/g; # 'TLA'
# create linked bullet item
! # MartinGregory: this used to create an absolute URI. DanielBarclay reported this as a bug, and I tend
! # to agree so I got rid of the absolute part...
! $line = "$tabs* <a href=\"#$anchor\">$line</a>";
! # MartinGregory: AB had the following code replacing the old version of the single line above.
! # He didn't say why... it's not clear to me what it is doing. In any case, I added $scriptSuffix in the place
! # where he had missed it out, in case there is a need to use this in the future.
! #if ( $viewScript eq 'view' ) {
! # $line = "$tabs* <a href=\"$dispScriptUrlPath$dispViewPath$scriptSuffix/$webPath/$topicname#$anchor\">$line</a>";
! #} else {
! # $line = "$tabs* <a href=\"$dispScriptUrlPath/$viewScript$scriptSuffix/$webPath/$topicname#$anchor\">$line</a>";
! #}
$result .= "\n$line";
}
}
Note that this patch also has a commented out solution to
TOCDoesntHonourScriptSuffix ... it's commented
out because if this fix is applied then that bug is automatically fixed.
I just noticed that Daniel reported the bug against the production release ...
*my patch is against the 20 Mar 04 beta **
--
MartinGregory - 09 Apr 2004
I do not remember details, but there was a reason for absolute path names. Possibly had to do with INCLUDEs. I changed the TWiki.org code to use relative anchors for TOC. If there are no issues I will take it into
TWikiAlphaRelease. (BTW, the commented out
if ( $viewScript eq 'view' )
smells fishy anyway since the script might be view, view.cgi, viewauth, rdiff etc.
Please help out in testing the relative anchor refs
--
PeterThoeny - 09 Apr 2004
Fix record
Thanks Martin. Fix is now in
TWikiAlphaRelease and at TWiki.org. It also fixes a recent
TOCDoesntHonourScriptSuffix bug introduced by
ShorterURLs.
*** TWiki.pm 7 Apr 2004 12:50:52 -0000 1.314
--- TWiki.pm 10 Apr 2004 23:04:24 -0000
***************
*** 2329,2343 ****
$line =~ s/\[\[(.*?)\]\]/$1/ge; # '[[...]]'
$line =~ s/([\s\(])($regex{webNameRegex})\.($regex{wikiWordRegex})/$1<nop>$3/g; # 'Web.TopicName'
$line =~ s/([\s\(])($regex{wikiWordRegex})/$1<nop>$2/g; # 'TopicName'
! $line =~ s/([\s\(])($regex{abbrevRegex})/$1<nop>$2/g; # 'TLA'
! # create linked bullet item
! # AB change
! # $line = "$tabs* <a href=\"$dispScriptUrlPath/$viewScript$scriptSuffix/$webPath/$topicname#$anchor\">$line</a>";
! if ( $viewScript eq 'view' ) {
! $line = "$tabs* <a href=\"$dispScriptUrlPath$dispViewPath/$webPath/$topicname#$anchor\">$line</a>";
! } else {
! $line = "$tabs* <a href=\"$dispScriptUrlPath/$viewScript$scriptSuffix/$webPath/$topicname#$anchor\">$line</a>";
! }
$result .= "\n$line";
}
}
--- 2329,2337 ----
$line =~ s/\[\[(.*?)\]\]/$1/ge; # '[[...]]'
$line =~ s/([\s\(])($regex{webNameRegex})\.($regex{wikiWordRegex})/$1<nop>$3/g; # 'Web.TopicName'
$line =~ s/([\s\(])($regex{wikiWordRegex})/$1<nop>$2/g; # 'TopicName'
! $line =~ s/([\s\(])($regex{abbrevRegex})/$1<nop>$2/g; # 'TLA'
! # create linked bullet item, using a relative link to anchor
! $line = "$tabs* <a href=\"#$anchor\">$line</a>";
$result .= "\n$line";
}
}
--
PeterThoeny - 10 Apr 2004
Follow-up: This fix introduces a new bug,
TocOnNotCurrentTopicBroken
--
PeterThoeny - 18 Jul 2004
Ah - so "the reason" is revealled.
I wasn't aware of the off-page TOC option.
Given that this exists, then it appears that the original reason for requesting
relative URIs won't hold.
If this fix is going to be reversed out, then the $scriptSuffix fix that is in my comments
above needs to be applied.
--
MartinGregory - 18 Jul 2004
This is now fixed, see
TocOnNotCurrentTopicBroken. Still relative URL if TOC is in current topic, else absolute path.
--
PeterThoeny - 18 Jul 2004
I am getting bitten by absolute URLs at the moment, after we have started to do some documentation in Danish and are using web names with international characters in them.
As far as I can tell, it comes down to the fact that various encodings are in the game, i.e. a URL can have these different encodings:
-
SystemManagement/Overvågning/Nagios/WebHome
- "raw"
-
SystemManagement/Overv%e5gning/Nagios/WebHome
- "iso-8859-1"
-
SystemManagement/Overv%C3%A5gning/Nagios/WebHome
- "utf-8"
Apparently the browsers carry no mechanism for matching these three as being equal, so you "buy" a topic reload when pressing a TOC link (losing POST parameters, etc) - somewhat annoying.
Is there perhaps a global setting available one can use to disable absolute URLs in TOCs?
(Alternatively, there's probably no way around normalizing links to one of the formats internally, so links can appear in the same encoding always?)
--
SteffenPoulsen - 10 Oct 2006
Please have a look at
Bugs:Item2619 - there's a fix available in
SVN which has not yet made it into an official release (4.0.4 is r10807, the checkin was r10995). If you found the error in
SVN, please re-open the bug, maybe the fix isn't complete with regard to international characters (though I wouldn't understand why).
--
HaraldJoerg - 10 Oct 2006
Hmmm, perhaps this isn't a problem with the
%TOC%
code at all.
Looking at generated TOC code from
SVN it looks something like this:
Generated TOC html: ..
<li> <a href="#Test_%C3%A6%C3%B8%C3%A5"> Test æøå</a> <ul>
Header in topic: ..
<h2><a name="Test_æøå"></a> Test æøå </h2>
But STILL there is a browser reload.
I am starting to think that this might have to do with either the base tag, that is in "raw" encoding
<base href="http://twiki-vm/twiki/bin/view/Overvågning/TestÆØÅ"></base>
Or the internal mechanisms in the browsers.
The actual URL seen in Firefox will often be encoded in either "iso-8859-1" or "utf-8".
For Firefox I get a reload when things look like this:
After the reload it looks like this:
And now Firefox will jump along TOC entries happily.
But! - Now using this URL in Internet Explorer, I can't jump - it reverts first time from
- Overv%C3%A5gning/Test%C3%86%C3%98%C3%85 to
- Overvågning/TestÆØÅ#Test_æøå
before TOC links can be used. (It also reverts Overv%e5gning/Test%c6%d8%c5 to readable "raw" format - but on-the-fly, without a reload).
So could it be that this comes down to a different "preferred URL encoding in combination with baseurl"-practise for the two browsers, really?
Looking at i.e. Firefox configuration options and bug discussions for defaults (
http://kb.mozillazine.org/Firefox_:_FAQs_:_About:config_Entries), it definetely looks like this is a rats nest.
Compared to
MediaWiki, it doesn't look like they are using the base-url tag - and it also seems like they are pretty standardized on utf-8-style links, i.e.
http://da.wikipedia.org/wiki/%C3%86sel (never "iso-8859-1" encodings). This is apparently not converted back to "Æsel" by Internet Explorer (like it is with TWiki topics), so something appears to work differently there.
Anyway, TWiki TOC code is fine in
SVN (as far as I can tell) :-).
--
SteffenPoulsen - 10 Oct 2006
Although it sounds like this issue has already been open, closed, reopened and reversed, I just want to log the issue that having non-relative urls is also an issue for the recently implemented
NewsNotify feature. I'm beginning to wonder if the requirement of
TocOnNotCurrentTopicBroken is worth the problems it creates? Of is it time to add an attribute for TOC plugin that gives the option of relative or absolute refs?
--
LynnwoodBrown - 10 Oct 2006
Argh, checking my
configure
somehow I have managed to lose a whole lot of
I18N perl modules on the machine in question. Installing them again has made things work much better.
Sorry for any headaches this might have caused ..
--
SteffenPoulsen - 10 Oct 2006
Would be useful to have separate TOC options for 'TOC to non-current page', since that is clearly only used rarely and would enable use of relative URIs.
As for
MediaWiki etc - probably the simplest and cleanest option is to go for UTF-8 as the site character set for TWiki, in which case the page is using UTF-8 for all URLs as well as page contents, avoiding this issue. However, for alphabetic languages this really means full
UnicodeSupport, which is quite a bit of work including a performance hit for sites that enable it, and would probably require
CGI Accelerators such as
ModPerl and
FastCGI, which appear to pose some challenges at least on TWiki.org currently.
--
RichardDonkin - 11 Oct 2006
Looking at the
TOC variable documentation, it occurs to me that a possible spec for relative vs. absolute url references would be that absolute references are only generated if the
"TopicName"
parameter is defined. Otherwise, it could default to relative references. I'm thinking of submitting a feature request for this change.
--
LynnwoodBrown - 11 Oct 2006