Last modified: 2014-04-06 01:19:26 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 45348 - moving a page in a talk namespace with suppressredirect produces misleading message "A redirect has been created"
moving a page in a talk namespace with suppressredirect produces misleading m...
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
1.22.0
All All
: Normal major (vote)
: ---
Assigned To: Nobody - You can work on this!
: code-update-regression
: 45962 53307 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-25 09:00 UTC by Graham87
Modified: 2014-04-06 01:19 UTC (History)
17 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
"A redirect has been created" liar (90.48 KB, image/png)
2013-03-17 11:16 UTC, Nemo
Details

Description Graham87 2013-02-25 09:00:30 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.
Comment 1 Luis Felipe Schenone 2013-03-08 18:16:05 UTC
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?
Comment 2 Graham87 2013-03-09 11:11:21 UTC
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.
Comment 3 Luis Felipe Schenone 2013-03-09 14:13:35 UTC
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.
Comment 4 db [inactive,noenotif] 2013-03-10 17:11:10 UTC
*** Bug 45962 has been marked as a duplicate of this bug. ***
Comment 5 Nemo 2013-03-17 11:16:11 UTC
Created attachment 11947 [details]
"A redirect has been created" liar

Just happened to me while reverting a move.
https://www.mediawiki.org/w/index.php?title=Special:Log&dir=prev&offset=20130314151850&limit=2&type=&user=Nemo+bis
Comment 6 Jens K Andersen 2013-05-04 02:11:53 UTC
I still get the false message "A redirect has been created" at the English Wikipedia, for example in this move:
http://en.wikipedia.org/w/index.php?title=Special:Contributions/PrimeHunter&offset=201305040156&limit=1&target=PrimeHunter

I don't have user rights to test it elsewhere.
I guess it is displaying
http://en.wikipedia.org/wiki/MediaWiki:Movepage-moved-redirect
and should have displayed
http://en.wikipedia.org/wiki/MediaWiki:Movepage-moved-noredirect
Comment 7 Dmytro Dziuma 2013-05-09 22:13:40 UTC
We have the same bug on Ukrainian Wikipedia. At least 3 administrators could reproduce it.
Comment 8 Liangent 2013-06-06 15:14:03 UTC
Confirmed on zhwiki.

Remove tracking bug. It seems a wrong message is used now.
Comment 9 Roman Luts 2013-06-12 15:49:38 UTC
And the same bug on Ukrainian Wikivoyage
Comment 10 Graham87 2013-06-21 08:42:18 UTC
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.
Comment 11 Alex Monk 2013-06-21 19:44:45 UTC
It's going to be on all of the wikis guys, you don't need to confirm it for each.
Comment 12 Thehelpfulone 2013-07-11 23:38:00 UTC
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';
Comment 13 Mormegil 2013-07-13 12:37:43 UTC
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.
Comment 14 Roger W Haworth 2013-08-13 11:39:22 UTC
It was fixed for a while on en.wikipedia but it seems to have recently reverted to bugsy.
Comment 15 Bartosz Dziewoński 2013-08-24 21:37:53 UTC
*** Bug 53307 has been marked as a duplicate of this bug. ***
Comment 16 Gerrit Notification Bot 2013-10-11 15:35:34 UTC
Change 89226 had a related patch set uploaded by Umherirrender:
Clean up old title on move before reset article id

https://gerrit.wikimedia.org/r/89226
Comment 17 Umherirrender 2013-10-11 15:38:18 UTC
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.
Comment 18 Gerrit Notification Bot 2013-10-21 17:45:28 UTC
Change 89226 merged by jenkins-bot:
Clean up old title on move before reset article id

https://gerrit.wikimedia.org/r/89226
Comment 19 Umherirrender 2013-10-22 16:56:31 UTC
(In reply to comment #18)
> Change 89226 merged by jenkins-bot: 
> Clean up old title on move before reset article id
> https://gerrit.wikimedia.org/r/89226

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.
Comment 20 Graham87 2013-12-26 13:33:40 UTC
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.
Comment 21 Andre Klapper 2013-12-26 20:45:13 UTC
(In reply to comment #20)
> I just got this problem today on Talk:Radix

https://en.wikipedia.org/w/index.php?title=Talk:Radix&action=history
Comment 22 Kronf 2014-04-05 23:00:00 UTC
I just moved a page with suppressredirect on de.wiktionary and for the first time didn't get the bug.
Comment 23 Graham87 2014-04-06 01:09:19 UTC
(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:
https://en.wikipedia.org/w/index.php?title=Special:Log&page=User+talk%3AGraham87%2Fsandbox
Comment 24 Bawolff (Brian Wolff) 2014-04-06 01:19:26 UTC
(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:
> https://en.wikipedia.org/w/index.php?title=Special:
> Log&page=User+talk%3AGraham87%2Fsandbox

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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links