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
Environment
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.
Regards
--
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
Hello,
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'
!_abc
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
AutomationGroup
as
IafHome
References to
AutomationGroup
Incorrectly, references to topics containing the same string within the name were also changed.
For example
QAAutomationGroupTestPlans
and
QAAutomationGroupDocumentation
were changed to become references to (nonexistent topics)
QAIafHomeTestPlans
and
QAIafHomeDocumentation
--
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