Feature Proposal: Renaming links is currently too greedy on what it changes

Motivation

This is a retrospective documentation of a changed behavior of moving topics between webs. The change was caused by a code change by MichaelDaum to prevent a full scan of all topics of a target web for each topic of the source web thus resulting in a serious performance problem. See also Tasks.Item11929.

Description and Documentation

There are two kinds of links that are in question to be rewritten as part of the rename/move operation:

• incoming links: links from other topics to the topic being renamed
• outgoing links: links to other topics part of the content of the topic being renamed

When renaming a topic, the user is presented with a list of incoming links that may be affected by the operation. The user might sanction these topics by clicking the checkboxes of those topics that are okay to be processed. This list is passed in a second step to foswiki to process it accordingly.

There are still links in the topic being renamed pointing to content in the source web or the target web. This content might consist of relative WikiWords and absolute WikiWords. Relative WikiWords are links to topics relative to the location where the WikiWord occurs. Absolute WikiWords point to a topic independent of where this WikiWord is used.

Example:

• relative WikiWord: HelloWorld
• absolute WikiWord: MyWeb.SomeSubWeb.HelloWorld

The change under consideration now is affecting relative WikiWords only. Note that these are the ones used most often.

Before, these have been rewritten in an effort to preserve the link target location even though the topic has been moved. So when the topic being renamed contained a relative WikiWord OtherTopic, it would have been rewritten to SourceWeb.OtherTopic while the topic is being moved to TargetWeb.

The intention is to leave these links untouched to preserve the relative nature of the WikiWord.

For example a link to WebHome should be left untouched instead of rewriting it to point to the SourceWeb.WebHome when the topic then will reside in TargetWeb. The link should effectively point to TargetWeb.WebHome.

This conclusion is based on observed practice; relative wikiword links that are not qualified with a web name are expected to be relative to the containing web, and should not be locked to the first topic they happen to match to.

A second aspect is that current behaviour downgrades absolute links in the moved topic that point to the target web. For example, if Thisweb.Topic contains a reference to Thatweb.OtherTopic before it is moved, then the code will rewrite that link as OtherTopic, removing the web specifier. This assumes a symmetry between relative and absolute wikiword links that simply doesn't exist, and should be removed.

Impact

People may experience a different behavior of renaming topics than before, i.e. when expecting the core will preserve the link target of a relative link to a wiki topic.

People may have experienced a 500 Server Error when the rename script timed out on large wikis, thus leaving behind inconsistent content.

In any case will the rename operation stop scanning the content excessively. That's not required before and after this feature proposal.

Implementation

There are two possible solutions:

• (a) keep the current code fixes as they have been merged to the release branch
• (b) add code to process the content of the moved topic to preserve the link target even of relative links

Opinions

Name	Solution A	Solution B	Comment
MichaelDaum			there are good reasons for both. however, the less the data is rewritten, the lower the probability to do more harm to it than actually doing any good.
CrawfordCurrie			fits most use cases
KennethLavrsen			most logical behavour and will be nice for me in many case where people build apps in Sandbox and move them to their web when it works. Also when people copy apps from other webs
AndreLichtsteiner			Our use cases would profit more from Solution B. But best would be a checklist similar to the backlinks, offering to choose, which links have to be kept unchanged

-- Contributors: MichaelDaum, CrawfordCurrie - 30 Jul 2012

Discussion

Marked as "Under Construction" because it was checked into trunk earlier in the month, under the guise of "fixing" unit tests, and stealth-accepted into 1.1.6 on 29/7/12

---

Actually it was checked into trunk to fix a huge performance issue in rename that has been outstanding / deferred for quite a while now. Tasks.Item10222, which identifies the same issue as Tasks.Item211929. The performance fix broke the test.

-- GeorgeClark - 30 Jul 2012

The fix consisted of removing a big chunk of code totally useless. It only addressed the issue at hand by accident.

-- MichaelDaum - 30 Jul 2012

Actually the removed code was not useless, as it did perform the functions described, albeit inefficiently. That's how the tests passed.

Michael, you propose two solutions above, but it seems to me that only the first is an implementation of this feature, is that right? The second (b) would appear to be a reversion to the previous behaviour (preservation of all outgoing links in moved topics). If not, and there really are still two solutions to be discussed, then consensus has not been reached and the decision in the form is wrong.

-- CrawfordCurrie - 31 Jul 2012

We had a consensus on IRC but not on this wiki page. I documented the two alternatives we discussed on IRC above.

The previous implementation won't come back in any case. Solution (b) however will try to restore the previous behavior by only post processing outgoing links of the content being moved accordingly. As far as I see this is still an option. What do you think?

-- MichaelDaum - 31 Jul 2012

The more I think about, the better option (a) fits the most common use-case.

• Several times I have been caught out because a link to a topic in a moved topic does not link to a topic in the same web. This mostly impacts system topics, like WebHome and WebPreferences, but also impacts other topics.
• It is quite rare to be moving a single topic that refers to other topics in the same web without moving those other topics as well. Topics tend to exist in a clique, and the entire clique usually moves.

-- CrawfordCurrie - 31 Jul 2012

Commenting is disabled while not logged in