Author: ui2t5v002
Description:
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.
Version: unspecified
Severity: enhancement
robchur wrote:
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.
ral315 wrote:
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.
ui2t5v002 wrote:
(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.
ral315 wrote:
(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.
phi1ipp wrote:
Is there a mechanism for voting on bugs? Take this as me voting for this one.
jasonspiro4 wrote:
(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?
ayg wrote:
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.
kovo1 wrote:
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?
(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.
kovo1 wrote:
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.
fearow00 wrote:
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.
phi1ipp wrote:
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:
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.
ral315 wrote:
(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:
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.