Last modified: 2011-03-13 18:05:46 UTC
It is not currently possible to move a page if a redirect exists where the page is to be moved. This is sane in most cases. However, if the redirect already points to the page to be moved, there is less reason to suspect that deleting the redirect and moving the page as instructed will have a bad effect. I therefore suggest that when pages are being moved to their own redirects, the redirecting page be automagically deleted (and a redirect created where the page was moved from, as per usual, and the message given about double redirects, also as usual).
Note, however, that this mechanism could be abused to delete pages; I propose two safeguards against this:
1) The editor creating the redirect and moving the page must be two different users/IPs.
2) Redirects younger than x minutes may not be deleted in this way. I propose x=60 as a default.
I've read Title::moveTo() and its helpers pretty closely lately, and moving A to B is possible if B is a redirect to A. If you have an example of a page where this isn't possible, please post the link here. Resolving as WORKSFORME for now.
Make sure you're not an administrator (not sure what happens if you are), and try moving (had to find a public example, whimsical though it may be...)
Definitely doesn't work for me.
The error message reads,
"The page could not be moved: a page of that name already exists, or the name you have chosen is not valid. Please choose another name, or use Requested moves to ask an administrator to help you with the move. Do not manually move the article by copying and pasting it; the page history must be moved along with the article text."
The way I see it, the redirect page that you want to move the current page to has non-trivial history. That means that there is some history on http://en.wikipedia.org/wiki/Bigfoot_Field_Researchers_Organization. Both administrators and regular users experience an "error message". Namely, regular users are told that the page cannot be moved to the desired destination, while administrators get a different page, where they are shown an option to delete the target page (i.e. its non-trivial history) so that the new page could be moved there.
I'm leaning towards WONTFIX-ing or INVALID-ing this, because this is the desired behavior, AFAIK. When there is no "meaningful" history of the target page, the move goes flawlessly both for admins and regulars.
I disagree. I've made valid suggestions how the behaviour can be fixed. If the end result is going to be that the "meaningful history" has to be deleted by an administrator, why not let a normal user do this (as above, after a significant delay, and by an editor who did not put the redirect in place), and only use administrators if something goes wrong and needs to be *un*deleted? My feeling is that administrators should be required to perform as few trivial tasks as possible.
By implementing this, anyone with move permissions could delete any page they wanted:
1. Change A's content to #REDIRECT [[B]]
2. Move B to A
3. Move A back to B
A's content is now #REDIRECT [[B]], but its history has been deleted (although it's still preserved in the undelete pool).
Imagine the following situation. User:UpToNoGood1 blanks article [[Foo]] and turns it into a redirect to e.g. [[Bar]]. If no one notices this, no one is going to revert it. After some time, User:UpToNoGood2 (remember, sockpuppets are technically very possible) moves [[Bar]] to [[Foo]] and without any warning or notice, the whole history of [[Foo]] is wiped by a normal user. This cannot be good.
Deletions should be left to administrators and *only* non-trivial deletions should be left to regular users, among others. While the example above is pretty unlikely to happen (that might be debatable, though, but that's a different topic), we mustn't make hazard where it's unnecessary. Undeletions shouldn't be used as a means for fighting vandalism!
I believe I stated that problem very clearly in the initial report, and suggested two solutions for it - there may be others. The vast majority of vandals don't plan ahead in the way you suggest, and if such a deletion were to occur, it would presumably show up in logs. If nothing else, the error message needs to be changed to something meaningful, such as a link to requested moves (WP:RM on the English Wikipedia), and it should state that the reason the move isn't possibly is not because the page exists, but rather, because the page wasn't always a redirect.
To get back to the particular example, this is the only revision of the page before it was made a redirect:
Any usability expert would say that the current behaviour of MW is a phenomenal failure. The software fails to acknowledge that the content of the cited revision is garbage and merits no preservation. Specifically, the content is nothing but a failed attempt by the user to create a redirect. I will open a separate bug for this issue.