Item1642: Explicit links should be updated, even within noautolink blocks after move/rename

pencil
Priority: Normal
Current State: Closed
Released In: 1.1.0
Target Release: minor
Applies To: Engine
Component:
Branches:
Reported By: VickiBrown
Waiting For:
Last Change By: KennethLavrsen
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

ItemTemplate edit

Summary Explicit links should be updated, even within noautolink blocks after move/rename
ReportedBy VickiBrown
Codebase 1.0.5, trunk
SVN Range Foswiki-1.0.0, Thu, 08 Jan 2009, build 1878
AppliesTo Engine
Component
Priority Normal
CurrentState Closed
WaitingFor
Checkins distro:150286c656f5
TargetRelease minor
ReleasedIn 1.1.0
Topic revision: r6 - 04 Oct 2010, KennethLavrsen
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy