This was discovered in
TWiki:Sandbox.TagMePluginHyperlinksBroken
If a Plugin produces a
[[TWiki internal URL][label]]
link, it gets rendered as a "non existing Wikiword link", even though the internal link is a regular URL. The bug happens only in webs other than the web of the TWiki internal URL.
How to reproduce:
1. In
WebTopBar add this:
%TESTVAR%
2. In any Plugin, add this to the
commonTagsHandler
:
sub commonTagsHandler
{
$_[0] =~ s|%TESTVAR%|TESTVAR: [[%SCRIPTURL%/view%SCRIPTSUFFIX%/TWiki/WebHome][testing bracket internal URL]], [[http://google.com/][testing bracket external URL]], <a href="%SCRIPTURL%/view%SCRIPTSUFFIX%/TWiki/WebHome">testing HTML tag URL</a>|g;
}
3. Go to any topic in the TWiki web
All links work as expected.
4. Go to any topic in any other web, such as the Main web
The first link is garbled. Output: (with newlines inserted)
TESTVAR:
<span class="twikiNewLink">testing bracket internal URL<a rel="nofollow" href="/cgi-bin/bin/edit/TWiki/http://www/structuredwikis/com/cgi-bin/bin/view/TWiki/WebHome?topicparent=Main.IgnoreTestPluginInclude" title="Create this topic"><sup>?</sup></a></span>,
<a href="http://google.com/" target="_top">testing bracket external URL</a>,
<a href="http://www.structuredwikis.com/cgi-bin/bin/view/TWiki/WebHome">testing HTML tag </a>
Possible causes of the bug:
- TWiki assumes that the internal URL in a square bracket link is a topic
- TWiki is trying to fix a TopicName link to the Originalweb.TopicName link in error (needs to be done for Wikiwords, but not for URLs)
Interestingly, this bug does not happen if
%TESTVAR%
is used in the topic text of a topic located in a web other than TWiki web.
--
PTh
The reason this happens is because of some nasty code called
fixIncludeLinks
that is meant to redirect links in include files to the web the file was included from. The code is not very smart, and prepends the web name to anything that isn't a wikiword .
This code was inherited from Cairo, and therefore I don't think we can treat this as a bug. I imagine this scenario is used pretty often in TWikiApplications, so I think it is high risk to fix it in a patch release.
I have committed the fix to DEVELOP and marked it for Edinburgh.
SVN 9237
--
CC
Sorry, I need to re-open this.
TWiki 4.0 code:
sub _fixIncludeLink {
my( $theWeb, $theLink, $theLabel ) = @_;
# [[...][...]] link
if( $theLink =~ /^($regex{webNameRegex}\.|$regex{defaultWebNameRegex}\.|$regex{linkProtocolPattern}\:|\/)/o ) {
if ( $theLabel ) {
return "[[$theLink][$theLabel]]";
} else {
return "[[$theLink]]";
}
} elsif ( $theLabel ) {
return "[[$theWeb.$theLink][$theLabel]]";
} else {
return "[[$theWeb.$theLink][$theLink]]";
}
}
Code after 9237 fix:
sub _fixIncludeLink {
my( $web, $text, $label ) = @_;
# [[...][...]] link
if( $text =~ /^\s*\w[\w ]+\s*$/ ) {
# Unqualified wikiword, with optional spaces
$text = "[[$web.$text]";
} else {
$text = "[[$text]";
}
$text .= "[$label]" if $label;
return "$text]";
}
This introduces a new bug where =Topic-with-dash" and other special chars do not get prefixed by the web name.
For comparison, here is the properly working Cairo code:
sub fixIncludeLink
{
my( $theWeb, $theLink, $theLabel ) = @_;
if( $theLabel ) {
# [[...][...]] link
if( $theLink =~ /^($regex{webNameRegex}\.|$regex{defaultWebNameRegex}\.|$regex{linkProtocolPattern}\:)/ ) {
return "[[$theLink][$theLabel]]"; # no change
}
# add 'Web.' prefix
return "[[$theWeb.$theLink][$theLabel]]";
} else {
# [[...]] link
if( $theLink =~ /^($regex{webNameRegex}\.|$regex{defaultWebNameRegex}\.|$regex{linkProtocolPattern}\:)/ ) {
return "[[$theLink]]"; # no change
}
# add 'Web.' prefix
return "[[$theWeb.$theLink][$theLink]]";
}
}
It does a NOP for URLs and Wikiword links that have a web prefix.
Please note that the bug
only appears if a Plugin returns a
[[TWiki internal URL][label]]
link in the
commonTagsHandler
. It works properly if you do an INCLUDE accross webs. That is an indication that the bug is not in
_fixIncludeLink
, but somewhere in the Plugin rendering.
--
PTh
Nasty, nasty. When a topic is included, the variables in the topic are expanded. The common tags handler is then called. Then the square bracket links are fixed up. Cairo had an extra call to expand all the tags
again after the handler was called. So you are right, in a sense, it was a problem in the plugin rendering. As such we should take it into the patch.
We could really, really,
really do with a test/testcase for this!
SVN 9257, 9258
CC
Closed with the release of 4.0.2
KJL