Last modified: 2008-07-22 22:46:55 UTC
When moving a page, redirects to the pre-move page title should be updated to the new title automatically, to avoid creating double redirects. Bug 3747 is related, though apparently different.
Depending upon the number of pages linking to the pre-move title, this could prove to be an expensive and/or long-running operation. It might be possible with the jobs table, however.
This would be a lovely opportunity for highly damaging vandalism.
*** Bug 5629 has been marked as a duplicate of this bug. ***
There could be, say, a 1 hour delay before they actually get changed; an hour of having double redirects isn't necessarily a problem, but allows a revert within an hour to stop the job. Alternatively, job queue entries involving moves could be approved by an admin/bureaucrat.
(In reply to comment #4) > There could be, say, a 1 hour delay before they actually get changed; an hour of > having double redirects isn't necessarily a problem, but allows a revert within > an hour to stop the job. Why? If a human were creating the redirect, they'd change all the doubles by hand immediately.
No, they wouldn't necessarily, despite all the warnings we could stuff in [[MediaWiki:Pagemovedtext]]. Many users of the simple "move" button wouldn't bother, and at smaller wikis with not as many people keeping an eye on Recent Changes, these double redirects could last a very long time.
(In reply to comment #5) >Why? If a human were creating the redirect, they'd change all the doubles byhand immediately. Not necessarily, and they can still do this. What adding it to the job queue does is gives the user the option of doing them manually. However, if they don't (and I'd argue that most don't), then the job queue would take care of them in an hour- altogether, not a bad amount of time compared to weeks or months. Even on large wikis like Wikipedia, I've found double redirects, and there are projects solely to fix double redirects, where thousands of them are found. This would eliminate that.
Is there a mechanism for voting on bugs? Take this as me voting for this one.
(In reply to comment #4 by Ral315) > There could be, say, a 1 hour delay before they actually get changed; an hour of > having double redirects isn't necessarily a problem, but allows a revert within > an hour to stop the job. Alternatively, job queue entries involving moves could > be approved by an admin/bureaucrat. Dear developers, If someone sends a patch to implement double redirect fixing, with one of the two safeguards Ral315 describes, will you consider accepting the patch?
We're almost all volunteers, so there's no guarantee that anyone will review the patch unless you get a personal guarantee from some particular developer. Frankly, though, this seems fairly silly: fix bug 5503 instead, in my opinion. There's no very good reason I've heard to prohibit redirect chains that are, say, up to ten redirects long.
Could there be a "Fix All" link added to the top of [[Special:Doubleredirects]] so that admins could quickly correct all of the problems without the help of a bot?
Why add a button if you can do it automatically in the background?
(In reply to comment #12) > Why add a button if you can do it automatically in the background? > Fixing them in the job queue, as suggested here, looks like the best solution to me as well.
Yes, please add this to the job queue. Then [[Special:Doubleredirects]] could be removed altogether, couldn't it? No need to see the page if the problems are all going to be corrected automatically in the background.
Actually no, as users could edit redirects etc to create double redirects. Or create new ones that are doubles. Ideally that should be made to change as well.
Note that circular redirects (e.g. A->B->C->A->etc.) can't be resolved. The job queue would keep trying to resolve them indefinitely.
Well, thanks for pointing that out Roan. I do feel, though, that "can't" is incorrect, because an implementation could be written to take this problem into account. I'm not sure how circular redirects would currently be displayed by MW. Ways of dealing with the situation include: - deleting the redirects to make them appear as red links - instituting "Special:Double redirects" Additionally, a warning should be given when creation of a circular redirect is attempted, with creation prevented and solutions suggested instead. A separate bug should be opened to track this feature, assuming the proposal has not been made before.
(In reply to comment #16) > Note that circular redirects (e.g. A->B->C->A->etc.) can't be resolved. The job > queue would keep trying to resolve them indefinitely. > Surely circular redirects are useless? A special page similar to [[Special:DoubleRedirects]] could be added to show circular redirects and allow for them to be deleted or retargeted, or they could simply be ignored by the process by detecting whether such a circular reference exists. Or, as said above, a circular redirect pattern could be prevented.
We are running pywikipediabots "redirect double" via cron against some wikis, where long redirect chains may exist as a result of some uncoordinated automated processes, including page renames. The result of running the bot is that, after a while, circular redirect chains are reduced to a single self-referencing redirect. Since these are easy to spot, my suggestion was that, the job queue process could be doing mainly the same. Here is a quick scetch of suggested amendments/additions: 1. On each page safe operation, when the page is a redirect, put it in the job queue for redirects. 2. When processing the job queue, when encountering a redirect: 2.1. determine its redirect target page 2.2. is the target a redirect? 2.2.1. no: done 2.3. determine the target page of the target 2.4. rewrite the source page as a redirect to the target of the target (note: this puts the page back into the job queue according to 1. above) 2.5. done Alternate version: 2.5. is the target = the source ? 2.5.1 no: done 2.6. add page to Special:CircularRedirects 2.7. done Fairly easy, is'nt it?
Fixed in r37928. Special:CircularRedirects is not done and can be requested separately.
