Last modified: 2011-03-13 18:05:46 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 11948 - Moving pages to their own redirects should be permitted
Moving pages to their own redirects should be permitted
Product: MediaWiki
Classification: Unclassified
Redirects (Other open bugs)
All All
: Lowest normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2007-11-12 05:27 UTC by phi1ipp
Modified: 2011-03-13 18:05 UTC (History)
2 users (show)

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


Description phi1ipp 2007-11-12 05:27:24 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.
Comment 1 Roan Kattouw 2007-11-12 14:52:24 UTC
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.
Comment 2 phi1ipp 2007-11-12 17:13:38 UTC
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."
Comment 3 Filip Maljkovic [Dungodung] 2007-11-16 10:30:08 UTC
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 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.
Comment 4 phi1ipp 2007-11-16 15:59:59 UTC
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.
Comment 5 Roan Kattouw 2007-11-16 16:10:16 UTC
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).
Comment 6 Filip Maljkovic [Dungodung] 2007-11-16 16:11:42 UTC
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!
Comment 7 phi1ipp 2007-11-16 17:16:41 UTC
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.

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