Item5176: %SCRIPTSUFFIX is added twice in TOC links

The TOC links on my locally installed TWiki 4.2 rc2 on Windows have 2 srciptsuffixes, e.g.

http://localhost/twiki/bin/view.pl.pl/TWiki/WelcomeGuest#What_s_in_a_TWiki

All other links and scripts seem to work fine, configure.pl does not report errors (any more).

I used TWiki 4.2.0 rc2 WindowsInstaller to install TWiki on WindowsXP, but had to do some manual changes.

Maybe I made a mistake??

-- TWiki:Main/MatthiasThullner - 28 Dec 2007

I have the same problem with TWiki 4.2 on a Linux server. The HTML code of the page with the TOC contains the line

base href="http://localhost/twiki/bin/view.pl.pl/TWiki/TWikiVariables" /base

This problem is not limited to the TOC. In the new WYSIWYG editor the "Edit help" link also creates an URL with two scriptsuffixes: http://localhost/twiki/bin/edit.pl.pl/TWiki/TWikiVariables# The corresponding HTML code is:

base href="http://localhost/twiki/bin/edit.pl.pl/TWiki/TWikiVariables" /base

(to keep this item5176 page readable, I omitted the < and > characters of the HTML examples)

I changed the priority from normal to urgent. This bug renders large topics unnavigable because using the TOC creates "error 404 - page not found" errors. This is very confusing for non technical users and not acceptable in a public Wiki. To the normal user it appears like some links work and some don't, because a TOC looks just like any other link.

-- TWiki:Main.MartinMayer - 03 Feb 2008

The problem for TOC is the setting of BASE: base href="http://twiki/bin/view.pl.pl/Sandbox/TestTopic". The edit help link is a twisty, so may be affected by the same thing.

-- TWiki:Main.CrawfordCurrie - 04 Feb 2008

The TabbedNavigationAddon is also affected. The links on the tabs have .pl.pl URLs too and lead to a 404 error.

-- TWiki:Main.MartinMayer - 04 Feb 2008

The following workaround works for me. It is not a clean solution because it does not correct the reason, why the suffix is added twice. But it prevents it from happening, when it is done in error.

lib/TWiki.pm:

unless( defined( $url )) {
   $url = $TWiki::cfg{ScriptUrlPath};
   if( $script ) {
      $url .= '/' unless $url =~ /\/$/;
      $url .= $script;
+     if ((index($url, $TWiki::cfg{ScriptSuffix})) < 0) {
         $url .= $TWiki::cfg{ScriptSuffix} if $script;
+     }
   }
}

-- TWiki:Main.MartinMayer - 09 Feb 2008

Ok, found it. The problem is that base uses %SCRIPTURL{%SCRIPTNAME%}% but this cannot work, as:

• %SCRIPTNAME% returns the script name including the extension
• %SCRIPTURL{...}% appends the extension So we must either:

1. make %SCRIPTNAME% return the name without the extension
2. make %SCRIPTURL{...}% not add the extension
3. create a new %SCRIPTBASENAME% returning the nameswithout ext
4. create a new %SCRIPTBASEURL{...}% not appending the ext
5. make =%SCRIPTURL{...}% = not add the extension if already there (the solution of TWiki:Main.MartinMayer above) I suggest strongly 1 as %SCRIPTNAME% is only used inside %SCRIPTURL{...}% and will implement a fix if there is no objections.

-- TWiki:Main.ColasNahaboo - 03 Mar 2008

Well, after a night sleep, for compatibility, solution 5 is perhaps the best, as 1 implies changing the behavior of a documented function. I now suggest strongly 5

But I would write the code a little more strictly, checking that the extension is actually at the end, like:

if ( rindex($url, $TWiki::cfg{ScriptSuffix}) != ( length($url) - length($TWiki::cfg{ScriptSuffix}))) {

• Solution 1: Item5176.patch: Patch to lib/TWiki.pm for TWiki-4.2.0
• Solution 5: Item5176.patch-5: alternative patch corresponding to solution 5

-- TWiki:Main.ColasNahaboo - 03 Mar 2008

No problem was found with Solution5, thus commited (Committed revision 16496)

-- ColasNahaboo - 09 Mar 2008

This patch seems to have not been applied in 4.2.1 update. The update breaks the patch and the problem it fixes returns. Reapplying the patch fixes the issue again.

-- TWiki:Main.DavidWolfe - 06 Aug 2008

This one got missed because the developer only checked in the fix in trunk and not TWikiRelease04x02 on Subversion.

NEVER EVER close a bug and hope someone will merge it to the release branch. If you cannot merge yourself leave the bug open.

And to the reporters: NEVER think we see a comment in a bug item which is closed or waiting for release. It is pure luck I see this now. Always either reopen the bug item or make a new bug item. Never assume anyone sees a comment added to a closed or waiting for release bug item.

I will merge in the fix now and then it will wait for a 4.2.3 to be in a release.

-- KennethLavrsen - 12 Aug 2008