Item1307: Moving a web does not correctly update links to the moved web

The case where I see the error is as follows

Start with a web called Myweb in which you have a WebHome with links in the formats (note the . vs /). Both formats are correct TML and the html link is plain normal syntax.

• Newrenamedweb.Subtestweb
• Newrenamedweb/Subtestweb
• http://merlin.lavrsen.dk/foswiki10/bin/view/Myweb/Newrenamedweb/WebHome

You have another web called Newrenamedweb and below this a subweb called Subtestweb

We now move the Newrenamedweb below Myweb so that Newrenamedweb becomes a subweb and Subtestweb becomes a sub-subweb.

What should happen in WebHome of Myweb is that the two links you have a Myweb/ or prefixed.

The result is (see in raw view)

• Myweb/Newrenamedweb.Subtestweb
• Myweb/Myweb/Newrenamedweb/Subtestweb
• http://merlin.lavrsen.dk/foswiki10/bin/view/Myweb/Myweb/Newrenamedweb/WebHome

The two last links get one Myweb/ too many

This is just ONE case. I am sure there are more. These regexes needs careful study. I fear the problem stated with a refactoring where normalizeWebTopicName was used instead of hardcoded regexes but I am not sure about this as the root cause. But it has created other similar errors.

-- KennethLavrsen - 16 Mar 2009

I just added test_renameWeb_1307 to RenameTests.pm in an attempt to reproduce what you report, but.... it passes. Could you review the testcase and see if you can spot what is different (apart from the names of the webs, obviously), because I can't

Thanks

-- CrawfordCurrie - 16 Mar 2009

How about just trying what I describe? It is easy to reproduce in real life. I have described the entire scenario.

I am starting off with a perfectly working set of webs and subwebs with perfectly working links. And after a rename I end up with it all broken.

And it should work. If I have working links before I should have working links after. It is that simple.

And Web/Subweb.Topicname is as valid TML as Web.Subweb.Topic.

It is easy to proof. Just look here

Where does your broser say these links point?

• TopicName
• TopicName

Two valid TML links!

If I moved Web below Othersubweb users expect these links to still work and not one broken and one working. Otherwise moving a web will be a disaster to a site where people have working links and expect them to be working after a web move. I know we cannot catch advanced cases where the webnames are generated by a CALC or SEARCH etc or otherwise calculated or convoluted or encoded in searches with squarebrackets etc. But straight forward hardcoded links like these must survive a web move. They do in the simple cases where you rename a web but moving below subwebs does not work. I also tried in TWiki 4.2.4 and it has same issues.

What happens is that the Myweb webname gets duplicated. It adds it twice when you move from root web to subweb.

To ease the reproduction I attach a zip with two webs.

• Staticweb
• Movingweb

Both are root webs. Check that links are working between the two webs.

To reproduce go to Movingweb and move it below Staticweb. You now see broken links in both webs. And if I remember also in subwebs in some cases once you start moving more around.

The unit test test_renameWeb_1307 does not follow my initial test description. It creates two subwebs and move one subweb below another.

This works also in a browser. But when you follow the initial bug report and also the attached testcase you are moving a root web below a subweb and this is where the name of the parent web gets repeated twice in some cases depending on the chosen link syntax (/ or . as web separator).

-- KennethLavrsen - 16 Mar 2009

OK, interesting. My testcase still has value, as it reflects a different scenario that must also work, and proves that your error only occurs when renaming root webs; so we end up with two complementary testcases. Excellent.

Hmmm. What happens is this. Web references are renamed in two stages; first, free-standing web references, such as Web.Topic, are renamed. Next, URL fragments are renamed. What happens in this case is that the first stage generates a string that matches the second stage, because of the use of the / separator.

• Newrenamedweb/Subtestweb.WebHome

matches /\bNewrenamedweb(([\/.]:upper:[[:alpha:][:digit:]_]*)*.:digit:+)\b/ and so gets mapped to

• MyWeb/Newrenamedweb/Subtestweb.WebHome

this is a valid URL fragment, which matches the second RE, /\/Newrenamedweb\//, resulting in

• MyWeb/MyWeb/Newrenamedweb/Subtestweb.WebHome

I strongly suspect this problem has been around since the invention of subwebs. Ideally we would detect "real" URLs in the way it is done during rendering; unfortunately this is impossible, because URLs can be generated by expansion of macros.

So what we have here is a tradeoff between sometimes double-renaming webs, and sometimes missing them completely. I don't think there is a full solution, though we may be able to treat the symptoms somewhat.

-- CrawfordCurrie - 17 Mar 2009

You are probably right that we always had this bug.

At least it is in current (tm)wiki.

As long as the simple straight forward hard coded web/subweb.topic and web.subweb.topic links get updated I think we should be pleased.

The URL links are close to hopeless. We actually always did this wrong too. A URL to some different site also gets updated. There we have to accept some glithces. It is the stright forward static text TML links we should focus on as you also conclude.

-- KennethLavrsen - 17 Mar 2009

I found a simple fix.

-- CrawfordCurrie - 17 Mar 2009