• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 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.

Inconsistency in current Dakar code:

  • SCRIPTURL creates URL with protocol & domain
  • SCRIPTURL{param} creates URL sometimes with, sometimes without protocol & domain (which is a bug 1)
  • SCRIPTURLPATH creates URL without protocol & domain
  • SCRIPTURLPATH{param} creates URL sometimes without protocol & domain, and without param (bug 2)

Bug 1 and bug 2 are inconsistent and confusing (discovered by adding a comment to Item1190). As the names imply, SCRIPTURL should return the full URL, and SCRIPTURLPATH just the URL path.

Test case:

If I recall correctly, a while ago many %SCRIPTURLPATH%/view%SCRIPTSUFFIX% have been changed to %SCRIPTURL{view}% instead of %SCRIPTURLPATH{view}%. (IMHO this was an invasive change that could have been avoided during code freeze.) This required to make the code "smart" on when to produce a full URL and when to produce a URL path. I do not think that the code can anticipate reliably which one to use. It is much safer to let the template authors and TWiki application writers decide if to use SCRIPTURL or SCRIPTURLPATH.

All templates that have %SCRIPTURL{something}% need to be reviewed and changed to %SCRIPTURLPATH{something}% in case the original text was %SCRIPTURLPATH%/view%SCRIPTSUFFIX%.

-- PTh

I am changing this to requirement since this bug breaks many things. Latest example is Item1199 where WebChanges had a broken [[%SCRIPTURL{"search"}%/...][...]] link (Antonio did a workaround by using an HTML anchor tag.) Another example is a broken image in TWikiDocGraphics.

-- PTh

As described in documentation, in the bug reports and in the checkin notices, this fix was done to eliminate the difference between %SCRIPTURL and %SCRIPTURLPATH, which has always been confusing and poorly understood, in most cases unneccesary, and broke load balancing approaches that rely on relative URLs.

The whole point was to replace PATH url variants with a single %SCRIPTURL{"script"}% (and later %PUBURL%) that would intelligently generate relative or absolute URLs on demand, instead of relying on the template author to always get it right (because historically they clearly haven't). The only places where an absolute path should be used in the templates is in the BASE statement in the header. All other URLs should be relative. For this reason, and for backward compatibility, I made %SCRIPTURL% generate an absolute URL (again, as documented). Item1199 occurred because the URL parser that handles square bracket links in included topics is crap. Rather than reverting to an absolute URL (which will break those sites that use load balancing servers) it should have been fixed by correcting the parser. So I have reopened Item1199, and am discarding this report.

CC

Please do not discard this usability issue and bug just to push out the release. This is a design issue that is biting us now and will bite us later, so better to fix it. We can't change the semantics of SCRIPTURL and SCRIPTURLPATH.

There are related issues, such as the inability to specify a link to an attached image, e.g.:

Or, if you simply want to link to a script:

-- PTh

It also breaks the compatibility with %TOPICURL%

In Cairo in TWikiPreferences TOPICURL is defined as

      * Set TOPICURL = %SCRIPTURL{"view"}%/%WEB%/%BASETOPIC%
And in Dakar it has been changed to
      * Set TOPICURL = %SCRIPTURL%/view%SCRIPTSUFFIX%/%WEB%/%BASETOPIC%

The result is that TOPICURL is no longer a URL.

I agree 100% with Peter that the behavour of SCRIPTURL must always be the URL including http etc. And SCRIPTURLPATH should always be the path only. We keep on running into compatibility issues because of the unpredictable behavour.

We use TOPIC url on all our ISO documents like this (using %TOPICURL%)


This document is available at the Quality System Internet Site

http://svn.twiki.org/do/view/Bugs/Item1197

Any paper copy of this document is an uncontrolled copy.


So it is actually useful often to be able to show the entire URL when you so desire. And as you can see in the above example Dakar does not produce the URL but a relative and in this context useless path.

-- KJL

TWikiSkins#ActivatingSkins has a demo link that doesn't work because of this

-- WN

This bug was introduced by Item910, SVN r7429, r7555, r7557, r7714, r7723, r7726, r7738

-- PTh

Clearly we are not going to be able to eliminate the need for users to know the difference between absolute and relative URLs. That's a shame, as it makes template writing a lot more compllicated, and makes other features such as load balancing and host hopping much harder to do as well. Oh well, it seemed like a good idea at the time.

SVN 8034

CC

Thanks Crawford.

-- PTh

ItemTemplate
Summary Inconsistencies in SCRIPTURL{param} and SCRIPTURLPATH{param}
ReportedBy PeterThoeny
Codebase

SVN Range Wed, 14 Dec 2005 build 7851
AppliesTo Engine
Component

Priority Urgent
CurrentState Closed
WaitingFor

Edit | Attach | Watch | Print version | History: r15 < r14 < r13 < r12 < r11 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r15 - 2006-01-03 - PeterThoeny
 
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