Question

I have just upgraded a site from pre-4.x to 4.0.5, and a users has discovered a change in behaviour that has left him with a bunch of broken links.

The user had previously created (sub)topics representing IP subnet addresses, using links of the form

[[192.168.1.0/24]]

With TWiki 4.0.5, it appears that the slash does not get removed, which leaves a broken link to a topic called 24 in a non-existent web called 19216810 - like this 192.168.1.0/24.

Is this a regression, or an intentional change?

Edit: Well, that's interesting - this version of TWiki changes the periods into slashes too!! I guess I need to go looking for Preferences relating to this...

Edit #2 I figured out that adding / to $TWiki::cfg{NameFilter} (in LocalSite.cfg) works around this problem, but not sure if it's the right solution... ?

Environment

-- IainMacDonnell - 13 Jan 2007

Answer

If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

This came with the new feature called subwebs.

And in your case the syntax for addressing a subweb clashes with the very special use case that you have.

In Cairo and earlier the dots were simply removed. Now the first dot is replaced by a /. And so are the next and the next. And since TWiki4.X only allows one subweb level the result is a link to a web that cannot exist.

So somehow you either need to change practice or do a workaround like you already have done. As I can see it your current hack will prevent use of subwebs - which may be OK for you if you do not plan to use that feature.

Under all circumstances the 4.X code works as it is supposed to and creating the subweb feature - using the dot and / for subweb syntax - is per spec. We do all we can to maintain compatibility. But in this case you have used the Cairo feature of removing illegal characters in filenames in way that clashes with the syntax of subwebs and I cannot see how that could be avoided in this case.

Hope you will find a new way of working around this special case.

-- KennethLavrsen - 14 Jan 2007