archive_me1Add my vote for this tag create new tag
, view all tags

Bug: Problem when renaming topic

When renaming a topic of name TopicName to the new name NewTopicName all references to topics TopicNamexxxx become references to NewTopicNamexxxx

Test case


TWiki version: 20030201
TWiki plugins:  
Server OS: Linux
Web server: Apache 1.3
Perl version: perl 5.8.0
Client OS: Linux
Web Browser: Mozilla

-- XavierREDON - 28 Apr 2003

Follow up

I can't reproduce it here (tried twice, RenamedTopicTest and NewOldTopicName) and I have never seen this in our installation at work where we have > 10k page changes per month. Could you test again and bring an exact example? Are you running mod_perl?

-- PeterThoeny - 28 Apr 2003

Could you try to rename TopicName? In my setup renaming it to NewTopicName will also rename TopicNamexxxx to NewTopicNamexxxx.

For mod_perl you mean in apache server ? if it is that the answer is no.


-- XavierREDON - 29 Apr 2003

In fact the exact problem was found when renaming ReglIntDocumentArt1 to ReglIntDocumentArtDepartements it also renamed ReglIntDocumentArt10 to ReglIntDocumentArtDepartements0. Could you also try with those exact names ?

Thanks in advance

-- XavierREDON - 29 Apr 2003

I just could verify that there is a problem when renaming TopicName to Sandbox.TopicName, but in a different way then you described: It did not rename the topic from TopicNamexxxx to Sandbox.TopicNamexxxx; it did not rename the reference from TopicNamexxxx to Sandbox.TopicNamexxxx; however, it did rename the reference at the beginning of this topic from Sandbox.TopicNamexxxx to NewSandbox.TopicNamexxxx

Funny that this bug was not noticed before! Needs to be fixed.

I moved your example topic to Sandbox web (first topic ReglIntDocumentArt1, then ReglIntDocumentArt10). Doing so I noticed another related bug: The reference to ReglIntDocumentArt10 got renamed to Sandbox.Sandbox.ReglIntDocumentArt10. Your example topics are now at ReglIntDocumentArt1 and ReglIntDocumentArt10.

-- PeterThoeny - 29 Apr 2003

I have not tried the inter-web renaming. You mean that you tried to rename directly ReglIntDocumentArt1 to something else in the same web and that ReglIntDocumentArt10 has not been renamed ?

-- XavierREDON - 29 Apr 2003

The code in this area is quite hairy - I did attempt to internationalise it back in Nov/Dec last year, but ran into somewhat similar issues that I couldn't resolve. Peter, let me know if you'd like a patch of my changes as they were - best if they are not checked into CVS as is, but quite a lot of work was done in this area.

-- RichardDonkin - 29 Apr 2003

Xavier: I tried the rename in the Codev web to verify, then moved the topic out of the way so that the Codev web does not get cluttered with testing.

JohnTalintyre, could you possibly help out in investigating and fixing this? You probably know more on this code segment.

-- PeterThoeny - 29 Apr 2003

I can and will help.

-- JohnTalintyre - 30 Apr 2003


Hello, i'm currently evaluating a TWiki for productive use and i'm stuck with the same Problem. If this Renaming-Bug remains in TWiki i wont be able to move the Wiki to the productive enviroment.I found this isue to be scheduled for "merge" in the next Release. Now this bug has not been discussed for a very long time.

Can you give me a date when this will be available either als stable or alpha/beta release or as a patch i can apply to a current build of TWiki (4.0 upward) ? I can wait for a few weeks at a maximum bevor switching to another content management system.

Thanx in advance for your replies!

-- ThomasSchmidt - 10 Jan 2007

I wonder what makes you think this is not resolved.

I have not gone back to earlier 4.0.X versions to check. But the current SVN code which becomes 4.1 does not have this bug. And the current shipping TWiki does not have this bug either.

TWiki has recorded bugs at Bugs:WebHome since 2005 and old Codev reports like this one are totally out of date and it is not always that people come back and close them off. Your inout triggered Bugs:Item3420 which I have discarded.

-- KennethLavrsen - 11 Jan 2007


thanx for the quick respond.

However this Bug does not come from a outdated version of TWiki on my installation. I have this bug on a actual 4.0.5 version (TWiki-4.0.5, Tue, 24 Oct 2006, build 11822 ) and on a second test system with a TWiki Debian Image for VM Server ( http://twiki.org/cgi-bin/view/Codev/TWikiVMDebianStable#Accessing_TWiki_VM) which runs a 4.0.4 version preconfigured for deployment.

Both installations run with internationalization activated an set to german language. Might this play a role in this bug, occuring on my system, but not on your system?

I can reproduce the bug 100% of the time. Whenever i rename a topic all other topics which include the exact pattern of the renamed topic are also renamed.

example: i rename topic: Backup to OracleBackup -> other topics like OfflineBackup or RmanBackup change to OfflineOracleBackup and RmanOracleBackup.

This kills the links in my TWiki and makes the topics unaccessible

I found this Bug and it sounds very similar to me. I am also very surprised that such a old bug still occours.

-- ThomasSchmidt - 11 Jan 2007

Thomas I tried the above example in TWiki 4.1, but the defect did not occur. I did not have internationalization turned on, but maybe you could try this on a TWiki 4.1. installation with your internationalization? (I have to confess, when I tried to turn internationalization on for repeating your test, it still showed English. I never tried that, so I probably did something wrong.)

Also, could you please update the bug item in Bugs:Item3420 as we are tracking defects in the Bugs web?

-- ThomasWeigert - 11 Jan 2007

Fix record

I think this problem was introduced with the internationalisation effort. The CVS change http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/twiki/twiki/bin/rename.diff?r1=1.36&r2=1.37 tried to clean up the regular expression matching not an alpha numeric (or underline). However, the appeared assume that nested/serial square brackets work - which they don't appear to. I've done a fix, although it may lack full internationalisation as:

# update pages that refer to the one being renamed/moved
sub updateReferingPages
    my ( $oldWeb, $oldTopic, $wikiUserName, $newWeb, $newTopic, @refs ) = @_;

    my $lockFailure = 0;

    my $result = "";
    my $alphaNum = $TWiki::mixedAlphaNum;
    my $preTopic = '^|[^${alphaNum}_]';      # Start of line or non-alphanumeric
    my $postTopic = '$|[^${alphaNum}_]';   # End of line or non-alphanumeric

    #where alphaNum = "[:alpha:][:digit:]"

changed to:

sub updateReferingPages
    my ( $oldWeb, $oldTopic, $wikiUserName, $newWeb, $newTopic, @refs ) = @_;

    my $lockFailure = 0;

    my $result = "";
    my $preTopic = '^|\W';      # Start of line or non-alphanumeric
    my $postTopic = '$|\W';   # End of line or non-alphanumeric

-- JohnTalintyre - 18 May 2003

Actually, it is quite valid in Perl 5.6 or higher to have an expression such as [[:alpha:]123] - the square brackets around the :alpha: don't denote a normal character class, i.e. they are analogous to a-z, not to [a-z]. See perldoc perlre and search for :alpha: for an example of this. So, given the value of $alphaNum, your new regex means exactly the same as the old regex... Has this change been tested as fixing this bug, and if so, with what TWiki.cfg, Perl version, etc?

I just tested a similar regex again on the command line and it does what I thought it would:

$ echo _abc | perl -ne '/^[^[:alpha:][:digit:]_]/ && print'

$ echo '!'_abc | perl -ne '/^[^[:alpha:][:digit:]_]/ && print'

So I don't think that I introduced the bug with I18N - I did have some additional changes for I18N in this script, not checked in, but I ran into odd behaviour and didn't finish them, which makes me think there were already some issues in this code before I started.

It would be worth getting a copy of TWiki.cfg and some testenv output, as the value of $alphaNum can depend on user input in TWiki.cfg.

-- RichardDonkin - 19 May 2003

At first I wrote a test script that also reached the conclusion that this wasn't the problem. But:

  • Reverting to the old code worked fine
  • When I exactly copied the existing code to a small test program it also didn't work.

-- JohnTalintyre - 20 May 2003

Can you post your test program, Perl version and TWiki.cfg here? Also, testenv output would be useful to capture whether locales are working. Copying the code to a test program may require the BEGIN section at the top of script to be included if you need to use locales.

-- RichardDonkin - 20 May 2003

Here's my (I must admit rather messy) test program.

    $upperAlpha = "[:upper:]";
    $lowerAlpha = "[:lower:]";
    $numeric = "[:digit:]";
    $mixedAlpha = "[:alpha:]";
    $alphaNum = "${mixedAlpha}${numeric}";
    $preTopic = "";
    $postTopic = '$|[^${alphaNum}_]';
    print "$alphaNum\n";
    print "$postTopic\n";
    $t = "OneTwoThree";
    $oldTopic = "OneTwo";
    $t =~ s/($preTopic)\Q$oldTopic\E(?=$postTopic)/$1---/g;
    print "$t\n";
    $t = "OneTwoThree";
    $t =~ s/($preTopic)\Q$oldTopic\E($postTopic)/$1---/g;
    print "$t\n";
    $t = "OneTwo3";
    $t =~ s/($preTopic)\Q$oldTopic\E(?=$postTopic)/$1---/g;
    print "$t\n";

    #$postTopic = '$|[^A-Za-z0-9_]';
    #$postTopic = "\$|[^:alpha:_]";
    $postTopic = '$|\W';
    $t = "OneTwo_A";
    #$t = "OneTwo";
    $t =~ s/($preTopic)\Q$oldTopic\E($postTopic)/$1---/g;
    print "$t\n";

-- JohnTalintyre - 22 May 2003

The commented out line that sets $postTopic is wrong btw:

    #$postTopic = "\$|[^:alpha:_]";
This should be either of the following:

    $postTopic = "\$|[^[:alpha:]_]";     # preferable
    $postTopic = "\$|[^:alpha:]";        # Wrong, but legal Perl RE syntax
However, the earlier code looks OK, which is what matters.

What's your Perl version and platform? TWiki.cfg and testenv output would be useful - you can email them if you prefer.

-- RichardDonkin - 23 May 2003

I just ran into this problem, and I think I have found the answer. Here is a little test script (adapted from the one above):

    $upperAlpha = "[:upper:]";
    $lowerAlpha = "[:lower:]";
    $numeric = "[:digit:]";
    $mixedAlpha = "[:alpha:]";
    $alphaNum = "${mixedAlpha}${numeric}";
    $preTopic[0] = '^|[^${alphaNum}_]';
    $preTopic[1] = "^|[^${alphaNum}_]";
    $postTopic[0] = '$|[^${alphaNum}_]';
    $postTopic[1] = "\$|[^${alphaNum}_]";
    $oldTopic = "OneTwo";

    foreach (qw[OneTwo OneTwoThree OneTwo3 OneTwoa OneTwol OneTwoN OneTwo_A
                ZeroOneTwo 0OneTwo OneTwo. (OneTwo)]) {
        for ($n=0; $n<4; $n++) {
            $t[$n] = $_;
            $t[$n] =~ s!($preTopic[$n/2])\Q$oldTopic\E(?=$postTopic[$n%2])!$1---!g;

        $t[4] = $_;
        $t[4] =~ s/\b\Q$oldTopic\E\b/---/g;

        print join(" ",$_, @t), "\n";

What is happening is that with the original expressions, the single quotes mean that the ${alphaNum} are literal characters in the values of $preTopic and $postTopic, not a reference to a variable. Using double quotes and escaping the first '$' fixes things to be what I think was intended in the old code. If you are going for the word boundary approach, then I think that using '\b' as in the last example in the test script will do what you want since you know that the topic name starts and ends with a \w.

-- OwenRees - 12 Sep 2003

Thanks for spotting this - looking at comments in my version of the test script from earlier this year, I think I had just about reached the same conclusion but ran out of time to validate this. Try the attached patch file - I've tested it quickly at http://donkin.org, and this line does work when used within the test script. Using \b would be an option, but I would prefer to do something based on the more flexible 'definable WikiWord format' approach anyway (introduced for I18N, see WebNameAsWikiName for how this would work).

-- RichardDonkin - 15 Sep 2003

This was fixed some time ago in TWikiAlphaRelease.

-- RichardDonkin - 02 Feb 2004

Re-opening. Sighted in

 TWiki version 01 Sep 2004 $Rev: 1742 $, Plugin API version 1.025

I renamed topic


References to

Incorrectly, references to topics containing the same string within the name were also changed.

For example

were changed to become references to (nonexistent topics)
-- VickiBrown - 30 Jun 2005

This appears to also be a problem on the DEVELOP branch, although I have not seen cases yet where the unrelated references were actually changed. It looks like an artifact of not using the egrep command and appropriate regexes to search for topic references. However, the regexes used for topic name substitution seem to be robust enough for the substitution to work properly.

Changing the $searchString submitted to egrep to look like this ( "\\<$searchString\\>" ) seems to fix the problem. I've checked in a fix on the MultiLevelWikiWebs branch (rev 4480).

-- PeterNixon - 30 Jun 2005

Ah, OK, this fix assumes that \< and > match the empty string at the beginning and end of a word. Merged the fix over to DEVELOP. The equivalent fix should work for Cairo, if anyone can work out the right place to change the code.

-- CrawfordCurrie - 01 Jul 2005

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatpatch rename.patch r2 r1 manage 0.7 K 2003-09-15 - 14:30 RichardDonkin Tested patch to fix this bug, works for I18N
Edit | Attach | Watch | Print version | History: r28 < r27 < r26 < r25 < r24 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r28 - 2007-01-11 - ThomasWeigert
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.