https://bugzilla.wikimedia.org/show_bug.cgi?id=45348
--- Comment #13 from Mormegil <[email protected]> --- 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. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
