Item1642: Explicit links should be updated, even within noautolink blocks after move/rename
Priority: Normal
Current State: Closed
Released In: 1.1.0
Target Release: minor
Applies To: Engine
Component:
Branches:
Explicit links should always be updated when a Topic is moved/renamed.
<noautolink>
means no AUTO linking. It does not mean no linking.
Yet explicit
[[...]]
enclosed links are not being updated following a Move or Rename of a page. This is inappropriate behaviour.
The code is here:
forEachLine
(in lib/Foswiki/Render.pm) has the following logic:
unless( $options->{in_pre} > 0 && !$options->{pre} ||
$options->{in_verbatim} > 0 && !$options->{verbatim} ||
$options->{in_literal} > 0 && !$options->{literal} ||
$options->{in_noautolink} > 0 && !$options->{noautolink} ) {
$line = &$fn( $line, $options );
}
And
In lib/Foswiki/UI/Manage.pm (_updateReferringTopics)
my $options =
{
pre => 1, # process lines in PRE blocks
oldWeb => $oldWeb,
oldTopic => $oldTopic,
newWeb => $newWeb,
newTopic => $newTopic,
};
To Test
Is it sufficient to either remove noautolink from that logic OR to add
noautolink => 1, # process lines in noautolink blocks
to UI::Manage (_updateReferringTopics)? Is the rest of the code smart enough to bypass
WikiWords that are not within =&091;[...]] (if not, that's a different bug)
(Bug Filed for TWiki as well:
http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item6268)
Co-worker has apparently looked at code and says:
"It's more difficult than just adding
noautolink = 1 because of the
WikiWords outside of
[[]]
."
"IMO the correct fix involves passing a parameter to
_updateReferringTopics
to say whether or not to rename bare
WikiWords."
I'm working on getting this fixed for 1.1
--
GeorgeClark - 06 Aug 2010