Last modified: 2011-03-13 18:06:09 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
*** Bug 1063 has been marked as a duplicate of this bug. ***
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
Additional changes will need to be made in SpecialMovepage.php in order to use modifications in the changed function.
I'd really appreciate this function too ! only for admin.
*** Bug 8308 has been marked as a duplicate of this bug. ***
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.
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.
It seems to me that it would make more sense to suppress redirect creation in the first place...
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.
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.
Also, since there's nothing being deleted, should the 'delete' permission still be required?
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.
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.
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
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.
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.
(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.
(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.
(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?
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.
*** Bug 11214 has been marked as a duplicate of this bug. ***
(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.
