Last modified: 2014-02-01 01:10:34 UTC
Intention: Most wikipedia users can move a page over a "simple" redirect, defined as one that has had only one edit. That situation is becoming rare as templates are added, double redirects are "fixed". Steps to Reproduce: 1. Wanted to move a page over a redirect but couldn't because User:AvicBot had fixed a double redirect, which brought the total number of edits on that redirect up to 2. 2. Wasted everybody's time getting that fixed and went about it the wrong way, which wasted more people's time. 3. Expected Results: The discussion at Wikipedia:Village_pump_(technical) proposes changing criteria for "simple redirects". Reproducible: Always Discussion at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Streamlining_page_moves_over_redirects.3F
Just flipping a few switches... I don't think this has very high priority, but I agree that moving over redirects needs some attention at some point to figure out what should or shouldn't be allowed.
Where could I find the current guidelines in the codebase, or on a wikipage (URL)? I'm not yet sure why this was filed in the bugtracker and would love to understand. :)
The best documentation I can find for MediaWiki's current behaviour is at [[Help:Moving a page#Moving over a redirect]] on the English Wikipedia. This is in Bugzilla because the restrictions on when a redirect can be overwritten are enforced by MediaWiki. Only a developer can change this behaviour. Bug descriptions should describe the problem, not the solution, so no specific change has been proposed in this bug (see the VPT thread for some specific proposals). Finding a way to ease these restrictions without creating avenues for vandalism is tricky, and we'd appreciate the developers views on this matter. In the code, the rules on when a redirect can be overwritten are implemented by Title::isValidMoveTarget <https://git.wikimedia.org/blob/mediawiki%2Fcore.git/807d510ad7353ae4adee736eb6f4b34890761114/includes%2FTitle.php#L4152>. Perma-link to the current version of the VPT discussion, for when it gets archived: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=592240576#Streamlining_page_moves_over_redirects.3F (note: there might be further edits to the discussion after this point)
Proposal: If a page has always been a redirect (regardless of target), and its earliest revision pointed to the page about to be moved over it, the move is allowed. This means that if two moves are made, two moves are required to get the page back where it was (regardless of whether the double-redirect was "fixed" in the meantime), while minimizing the potential for abuse. Thoughts?
To me, we have two issues; 1) What pages can be moved over the redirect? 2) How do we avoid losing important edit history? Jackmcbam's solution to #1 is a good one. It's about as vulnerable to game-play as the status quo is (you can game the current system if you do a chain of moves and trick an administrator into speedy-deleting one of them, this does not change). As for preserving edit history, how does this sound? 1) Create a way to mark REDIRECTS as "safe to overwrite." "Safe to overwrite" means there is no edit history that would ever need to be kept. 2) Update the MOVE tool, bots, and user documentation to reflect the changes. In almost all cases, the MOVE tool should leave a "safe to overwrite" redirect behind. 3) If the FIRST edit is before some cutoff-date, ASSUME it is "safe to overwrite" if it is a redirect. Otherwise, assume it is "NOT safe to overwrite" unless it is marked as such. 4) Edits that are not redirects are of course not "safe to overwrite." Only allow non-privileged editors to move-over-redirect if every edit is "safe to overwrite." It's an open question if we want to allow the "safe to overwrite" flag to be "set-able" by normal editors or if we want all normal editor's edits to automatically make the page "not safe to overwrite." If possible, make this configurable on a per-wiki basis.
For #2, just cause redirects deleted this way to be stored in the archive table. This avoids all of the complexity of what's safe to delete and what's not.
