Last modified: 2011-03-13 18:06:09 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 1062 - For admins, a "Move Page" check-box to avoid leaving a redirect
For admins, a "Move Page" check-box to avoid leaving a redirect
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Lowest enhancement with 10 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
: 1063 8308 11214 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-10 20:20 UTC by J. Noel Chiappa
Modified: 2011-03-13 18:06 UTC (History)
7 users (show)

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


Attachments
Adds a checkbox when moving pages which allows the redirect to be deleted (4.87 KB, patch)
2006-12-19 00:53 UTC, Sam Horn
Details
Same as 2900, but with system messages added (5.84 KB, patch)
2006-12-19 01:13 UTC, Sam Horn
Details
Suppress the redirect instead of deleting it afterwards (10.62 KB, patch)
2006-12-19 13:31 UTC, Sam Horn
Details
Changed messages and message names to make more sense (11.25 KB, patch)
2006-12-19 14:15 UTC, Sam Horn
Details

Description J. Noel Chiappa 2004-12-10 20:20:02 UTC
Hi, one thing that would really be appreciated, and 
shouldn't be too much work, would be a check-box on 
the "Move page" confirmation page (which would only 
appear when the user doing the move was a logged-in 
admin) which, when checked, would suppress the usual 
behaviour of leaving behind a redirect from the old 
location to the new one. When swapping pages, 
archiving things to Talk: or User: space, etc, etc I 
spend a chunk of time deleting the "tombstone" 
redirects that are left behind - it would be *so* 
much simpler if I could simply suppress the creation 
of the redirect. Thanks! Noel
Comment 1 Brion Vibber 2004-12-10 22:26:50 UTC
*** Bug 1063 has been marked as a duplicate of this bug. ***
Comment 2 Jason Lee, AllyUnion 2005-03-08 15:23:25 UTC
In Title.php:

Line 1344:
function moveTo( &$nt, $auth = true, $redirect = true )

Line 1380:
$this->moveOverExistingRedirect( $nt, $redirect );

Line 1382:
$this->moveToNewTitle( $nt, $newid, $redirect );

Line 1423:
        /* private */ function moveOverExistingRedirect( &$nt, $redirect = true ) {

Line 1453:
# Recreate the redirect, this time in the other direction.
if ( $redirect ) {

Line 1478:
}
# Fix the redundant names for the past revisions of the target page.

Line 1558:
        /* private */ function moveToNewTitle( &$nt, &$newid, $redirect = true ) {

Line 1584:
# Insert redirect
if ( $redirect ) {

Line 1603:
}
# Rename old entries
Comment 3 Jason Lee, AllyUnion 2005-03-08 15:27:01 UTC
Additional changes will need to be made in SpecialMovepage.php in order to use
modifications in the changed function.
Comment 4 iubito (Sylvain Machefert) 2006-04-22 05:49:02 UTC
I'd really appreciate this function too ! only for admin.
Comment 5 Rob Church 2006-12-18 16:30:10 UTC
*** Bug 8308 has been marked as a duplicate of this bug. ***
Comment 6 Sam Horn 2006-12-19 00:53:17 UTC
Created attachment 2900 [details]
Adds a checkbox when moving pages which allows the redirect to be deleted

Carried over from bug 8308 - adds a check-box when moving a page that allows
the redirect to be deleted. If a talk page is present, there is another
check-box to allow that redirect to be deleted also. Check-boxes only appear
for users with 'delete' permission.
Comment 7 Sam Horn 2006-12-19 01:13:39 UTC
Created attachment 2901 [details]
Same as 2900, but with system messages added

In addition to Attachment 2900 [details], this adds the required messages into the
English language file.
Comment 8 Rob Church 2006-12-19 11:47:25 UTC
It seems to me that it would make more sense to suppress redirect creation in
the first place...
Comment 9 Sam Horn 2006-12-19 13:31:03 UTC
Created attachment 2903 [details]
Suppress the redirect instead of deleting it afterwards

Instead of creating the redirect and then deleting it, I used a slight
variation of  the code in comment 2 to simply stop the redirect from ever being
created.

I didn't change the messages from attachment 2901 [details], because although the
redirect isn't technically deleted, it is removed regardless.
Comment 10 Rob Church 2006-12-19 13:33:49 UTC
Change the messages; there is nothing that's being deleted, and it could cause
user confusion. Set it to something like "Don't create redirects" or similar.
Comment 11 Sam Horn 2006-12-19 13:45:34 UTC
Also, since there's nothing being deleted, should the 'delete' permission still
be required?
Comment 12 Rob Church 2006-12-19 13:47:04 UTC
Well, it's more something we'd use when dealing with vandalism. I'd prefer it, I
think, if regular users still left redirects, otherwise Willy on Wheels would
have a field day.
Comment 13 Sam Horn 2006-12-19 14:15:15 UTC
Created attachment 2904 [details]
Changed messages and message names to make more sense

I kept the requirement of the 'delete' permission, and I changed all of the
messages. I also changed and standardised the message names.
Comment 14 Nobody 2007-08-10 01:30:13 UTC
Unless the software checks for links to the page and alerts people 'THERE ARE 500 INCOMING LINKS THAT NEED TO BE REDIRECTED, SUGGEST YOU DO NOT SUPPRESS THE CREATION OF A REDIRECT', then inexperienced, tired, careless, users and admins will use the feature when it shouldn't be used

Posted on behalf of w:User:Carcharoth http://en.wikipedia.org/w/index.php?title=User_talk:Kylu&diff=150299100&oldid=150292621
Comment 15 Rob Church 2007-08-10 18:52:27 UTC
When moving a page, leaving a redirect behind is the sort of thing that's done to ensure that we avoid breaking incoming links from internal and external sources. See also "Cool URI's don't change" at http://www.w3.org/Provider/Style/URI.

There are some very limited circumstances where deleting the redirect is fine, e.g. just after importing a page from another wiki, and in those cases, manual deletion is sufficient.

We don't want to encourage this.
Comment 16 Carl Fürstenberg 2007-08-10 18:56:19 UTC
(In reply to comment #15)
> When moving a page, leaving a redirect behind is the sort of thing that's done
> to ensure that we avoid breaking incoming links from internal and external
> sources. See also "Cool URI's don't change" at
> http://www.w3.org/Provider/Style/URI.
> 
> There are some very limited circumstances where deleting the redirect is fine,
> e.g. just after importing a page from another wiki, and in those cases, manual
> deletion is sufficient.
> 
> We don't want to encourage this.
> 

There are often situations of for example page move vandalism, when you don't want the created redirect to stay behind. Also for hist merges, you have no use for the intermediate redirect.
Comment 17 Rob Church 2007-08-10 19:05:09 UTC
Then deleted the resulting redirect. As for history merges, you almost always want the intermediate page kept, in case something goes wrong.

This will encourage bad practice, specifically, bad web site management.
Comment 18 Filip Maljkovic [Dungodung] 2007-08-10 19:09:39 UTC
I agree with Carl. Most of the times when moving from main namespace to userspace, there shouldn't be a redirect left. Same could go for most other namespaces. Also, there are numerous situations where deleting the redirect can't hurt (making a disambig page by moving "Title" to "Title (meaning)" etc)
Comment 19 Brion Vibber 2007-08-11 13:49:39 UTC
A redirect should always be left; this allows links to continue to function. This is a *REQUIREMENT* for being a good web citizen, and the alternative will never, ever be implemented.
Comment 20 J. Noel Chiappa 2007-08-11 14:26:47 UTC
(In reply to comment #19)
> A redirect should always be left; this allows links to continue to function.
> This is a *REQUIREMENT* for being a good web citizen, and the alternative will
> never, ever be implemented.

Brion et al:

This mechanism is intended for use *only* in cases where the new redirect would be *deleted instantly ANYWAY*. In other words, all these points about "we need to be good netizens" are completely off-base, because we're talking about redirects which would *always* not be there *anyway*. So there's no difference about the outcome: *there will be no redirect left*. The only question is *how* that redirect 'disappears'; is it via deletion, or via never being created?

And if the reponse is "Oh, but people might abuse this mechanism", well, it's only going to be available to people who have delete capability too. So, if they are inclined to do things which are out of policy, and remove redirects they should have left, they can do that whether or not this option exists. Again, this option doesn't materially change the existing situation.

So is there actually any valid argument why this is a bad idea?
Comment 21 Brion Vibber 2007-08-11 14:29:25 UTC
Because it's trivial to delete it if you need to, and those cases are rare ones. Whereas having the checkbox invites abuse without conferring significant benefit.
Comment 22 J. Noel Chiappa 2007-08-11 14:44:43 UTC
(In reply to comment #21)
> Because it's trivial to delete it if you need to, and those cases are rare
> ones. Whereas having the checkbox invites abuse without conferring significant
> benefit.

Clearly, it was a non-trivial amount of work, or I wouldn't have been moved to expend all the effort required to file a request for an upgrade.
Anyway, degree of ease is not a rationale as to why it's a *bad* idea. It doesn't take a lot of
code, or require resources to operate, and so if the savings in effort are minimal, who cares?


Your second point is more facially valid, but it seems to be that by making it easy, we invite abuse. However, this seems to be contradicted by your first point, where you claim it's trivial anyway. If there's no significant difference in effort, then surely there's no barrier to abuse?

If people with delete capability are inclined to abuse it, and delete things out of policy, not having this option isn't going to make it much harder for them. All you're doing my not adding this is making more work for admins who have a legitimate use for it - which was the whole rationale of this request to begin with.
Comment 23 Brion Vibber 2007-08-11 14:46:53 UTC
Because you're more likely to do something if:

1) You have a good reason to do it.

or

2) It's put in front of you with an invitation.

If 1) you've got no problem. If 2) we've got no reason to invite it when it's not required, and would very much prefer not to.

Thus, no invitation.
Comment 24 J. Noel Chiappa 2007-08-11 14:57:53 UTC
(In reply to comment #23)
> Because you're more likely to do something if:
> ...
> 2) It's put in front of you with an invitation.
> ... If 2) we've got no reason to invite it when it's not required, and would very much prefer not to. Thus, no invitation.

Ah. Will we be be removing the "Delete this page" button from the standard page display for admins, then?

I mean, a special 'Delete page' page, where you have to go to that page, and then enter the name of the page you want to delete, would better follow the logic of 'don't put things which might be abused right in front of people', no?




Comment 25 Nobody 2007-08-12 19:29:31 UTC
If you move a page and delete the redirect, the deleted redirect shows up in the deleted revisions for that page. It's still possible to go to the deleted page and find out where its content went.

If the redirect is never made, that information is lost.

I can think of a few positive uses, and a few ways this could be abused:

Recently, I had to remove some personal information that someone decided to put up on their talk page. That user seems to have a habit of this, as there were many, many deleted revisions on that page. So, I move the page after deleting that revision, then restore the deleted revisions, move those to a different page, delete it, then move the original page back over the redirect...

With the automatic creation of a redirect, the original deleted revisions are still findable in the history of the page, since the redirect points to where the old, deleted revisions are even though they're not in the direct history of the page.

If you allow the non-creation of redirects on page moves, it's possible to make it so that the history of a page is no longer traceable. You may as well give all admins oversight permission if you're going to do that. 
Comment 26 Robert Leverington 2007-09-06 17:35:00 UTC
*** Bug 11214 has been marked as a duplicate of this bug. ***
Comment 27 sv:user:Mike 2007-09-07 10:50:12 UTC
(In reply to comment #25)
> If you move a page and delete the redirect, the deleted redirect shows up in
> the deleted revisions for that page. It's still possible to go to the deleted
> page and find out where its content went.
> 
> If the redirect is never made, that information is lost. [...]

That's why I think the use should be "create and then automatically delete the redirect" rather than to suppress the creation in the first place, so that they do show up in the deletion log. And yes, the deletion of a couple of redirects created during a move is trivial to delete, and that is not much work. But the deletion of 100+ redirects from pages such as [[User:Foo lS STUP1D!1!]] is slightly less trivial, or at least pretty monotonous... (unless of course <s>the developers</s> <u>someone</u> would prefer to implement a function, where someone with 'delete' permission has the ability to bulk delete the resulting redirects in another manner).
Comment 28 Carl Fürstenberg 2007-09-09 10:45:30 UTC
Perhaps implement a functionality to prevent creating redirects if a inverse redirect is already in place. For example, if A is redirecting to B, then if B is moved to A, no redirect is made from B to A.

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


Navigation
Links