Last modified: 2014-04-06 01:19:26 UTC
While doing a history merge of the article "Extreme programming" on the English Wikipedia, I had to use the "suppress redirect" right often while moving the page. However, when I did so (for example while moving the page from "Extreme programming/Temp2" to "Extreme programming", I got the message that said "A redirect has been created" rather than the normal message that says "The creation of a redirect has been suppressed". This was extremely confusing. I also got the same incorrect message when moving my sandbox at "User:Graham87/sandbox". I presume this bug is fairly recent because I have never encountered it before.
I was unable to replicate the bug. Also I found out that a related bug (Bug 37209), has been solved recently, and that the code at Special:MovePage that seemed relevant to this bug has changed quite a bit since this bug was first reported. Thus, I think that the bug may already be solved. Could you confirm this, Graham87?
The bug is still present in the English Wikipedia. I don't have any special user rights on other wikis that would allow me to test it on them, but I'll take your word for it that the bug can't be reproduced on the latest WMF version of MediaWiki.
Ok, but don't close the bug report yet, let us wait until Wikipedia uses the latest version of MediaWiki. There is still the chance that my being unable to reproduce the bug is due to some misconfiguration on my local wiki.
*** Bug 45962 has been marked as a duplicate of this bug. ***
Created attachment 11947 [details]
"A redirect has been created" liar
Just happened to me while reverting a move.
I still get the false message "A redirect has been created" at the English Wikipedia, for example in this move:
I don't have user rights to test it elsewhere.
I guess it is displaying
and should have displayed
We have the same bug on Ukrainian Wikipedia. At least 3 administrators could reproduce it.
Confirmed on zhwiki.
Remove tracking bug. It seems a wrong message is used now.
And the same bug on Ukrainian Wikivoyage
On the English Wikipedia, I got the correct message when moving a page without a redirect in the article namespace when I moved the article Port Arthur massacre (Australia), but got the wrong message telling me the redirect had been *created* when I moved the talk page.
It's going to be on all of the wikis guys, you don't need to confirm it for each.
I believe this is because it's transcluding [[MediaWiki:Movepage-moved-redirect]] below [[MediaWiki:Movepage-moved]] instead of [[MediaWiki:Movepage-moved-noredirect]]. I would have thought this was a simple fix, but line 550 of SpecialMovepage.php already has
$msgName = 'movepage-moved-noredirect';
OK, I believe I got this tracked down, and it is (obviously) a real problem in the code, reproducable not only on any Wikimedia wiki, but also locally, with the help of $wgAllDBsAreLocalhost.
The problem is that even though Title::moveToInternal does call $this->resetArticleID( 0 ); to mark the current (old) title as nonexisting, during the following WikiPage::onArticleDelete, InfoAction::invalidateCache is called, which needs the current revision number for the supplied title, for which it needs to ask a database slave, which does not yet know about the move, so that it reloads the title with the old article ID. So that the $ot->exists() check in SpecialMovepage returns true in that case, which (after Gerrit change #38532) is the only used way of detecting whether the redirect was suppressed.
I guess a correct fix would involve some cluster magic like ensuring InfoAction::invalidateCache asks the master or something like that, I don't have the required knowledge.
An interim solution might be to change the check in SpecialMovePage from "if ( $ot->exists() )" to "if ( $createRedirect && $ot->exists() )", which fixes the bug, even though it leaves the link to the original page blue. (Or, change it to "if ( $ot->exists() && $ot->isRedirect() )" which might (?) work after Bug 37209 was fixed, even though this still has the wrong-blue problem.)
Or, an even patchier, but seems-to-be-working fix would be to execute $this->resetArticleID( 0 ); once more after the call to WikiPage::onArticleDelete( $this ); in Title.php.
It was fixed for a while on en.wikipedia but it seems to have recently reverted to bugsy.
*** Bug 53307 has been marked as a duplicate of this bug. ***
Change 89226 had a related patch set uploaded by Umherirrender:
Clean up old title on move before reset article id
Due to Mormegil comment 13 I have moved the call to WikiPage::onArticleDelete before the reset of the page id, that should fix the slave problem.
Change 89226 merged by jenkins-bot:
Clean up old title on move before reset article id
(In reply to comment #18)
> Change 89226 merged by jenkins-bot:
> Clean up old title on move before reset article id
Should be fixed now, will go live with version 1.22wmf23 (see [[mw:MediaWiki 1.22/Roadmap]])
If you can reproduce this on a wiki where version 1.22wmf23 is live, please reopen. Thanks.
I just got this problem today on Talk:Radix; I'd moved the talk page without a redirect but it said the redirect had been created. This occurred on all the page moves I'd performed in the talk namespace.
(In reply to comment #20)
> I just got this problem today on Talk:Radix
I just moved a page with suppressredirect on de.wiktionary and for the first time didn't get the bug.
(In reply to Kronf from comment #22)
> I just moved a page with suppressredirect on de.wiktionary and for the first
> time didn't get the bug.
Which namespace was it in? This bug only applies to talk namespaces now (I've changed the summary accordingly). I just tried it with my user talk sandbox, and it still produced the misleading message:
(In reply to Graham87 from comment #23)
> (In reply to Kronf from comment #22)
> > I just moved a page with suppressredirect on de.wiktionary and for the first
> > time didn't get the bug.
> Which namespace was it in? This bug only applies to talk namespaces now
> (I've changed the summary accordingly). I just tried it with my user talk
> sandbox, and it still produced the misleading message:
If we're talking about a slave lag related bug, that's probably a coincidence - it would more matter how busy the servers are when you happened to move the page.