• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7700 for generic doc work for TWiki-6.0.2. Use View topic Item7703 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

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

ItemTemplate
Summary commonTagHandler garbles square bracket links in WebTopBar
ReportedBy TWiki:Main.PeterThoeny
Codebase

SVN Range my $expanded
AppliesTo Engine
Component

Priority Normal
CurrentState Closed
WaitingFor

Checkins 9237 9257 9258
TargetRelease patch
Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r8 - 2006-04-01 - KennethLavrsen
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback