• Bug 1063 has been marked as a duplicate of this bug. ***

jylee wrote:

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:
}

1. Rename old entries

jylee wrote:

Additional changes will need to be made in SpecialMovepage.php in order to use
modifications in the changed function.

sylvain_machefert wrote:

I'd really appreciate this function too ! only for admin.

robchur wrote:

*** Bug 8308 has been marked as a duplicate of this bug. ***

supersammyfluff wrote:

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.

attachment Changes in SpecialMovepage.txt ignored as obsolete

supersammyfluff wrote:

Same as 2900, but with system messages added

In addition to Attachment 2900, this adds the required messages into the
English language file.

Attached:

robchur wrote:

It seems to me that it would make more sense to suppress redirect creation in
the first place...

supersammyfluff wrote:

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, because although the
redirect isn't technically deleted, it is removed regardless.

attachment Suppress instead of delete.patch ignored as obsolete

robchur wrote:

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.

supersammyfluff wrote:

Also, since there's nothing being deleted, should the 'delete' permission still
be required?

robchur wrote:

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.

supersammyfluff wrote:

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.

Attached:

lilewyn wrote:

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

robchur wrote:

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.

(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.

robchur wrote:

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.

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)

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.

jnc wrote:

(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?

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.

jnc wrote:

(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.

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.

jnc wrote:

(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?

lilewyn wrote:

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.

robert wrote:

*** Bug 11214 has been marked as a duplicate of this bug. ***

mike_wikipedia wrote:

(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).

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.