Last modified: 2008-07-22 22:46:55 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T6578, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 4578 - Page moves should not create double redirects
Page moves should not create double redirects
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Redirects (Other open bugs)
unspecified
All All
: Normal enhancement with 9 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 5629 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-12 14:23 UTC by Omegatron
Modified: 2008-07-22 22:46 UTC (History)
9 users (show)

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


Attachments

Description Omegatron 2006-01-12 14:23:38 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.
Comment 1 Rob Church 2006-04-16 00:08:19 UTC
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.
Comment 2 Brion Vibber 2006-04-16 07:56:12 UTC
This would be a lovely opportunity for highly damaging 
vandalism.
Comment 3 Brion Vibber 2006-04-18 00:30:29 UTC
*** Bug 5629 has been marked as a duplicate of this bug. ***
Comment 4 Ral315 2006-04-27 21:28:46 UTC
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.
Comment 5 Omegatron 2006-04-27 21:31:40 UTC
(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.
Comment 6 Minh Nguyễn 2006-04-28 06:16:03 UTC
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.
Comment 7 Ral315 2006-04-28 13:45:32 UTC
(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.
Comment 8 phi1ipp 2007-01-27 01:03:27 UTC
Is there a mechanism for voting on bugs? Take this as me voting for this one.
Comment 9 Jason Spiro 2007-03-22 09:10:33 UTC
(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?
Comment 10 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-03-22 16:07:37 UTC
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.
Comment 11 Jonathan Kovaciny 2007-10-09 18:13:24 UTC
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?
Comment 12 phi1ipp 2007-10-10 10:08:02 UTC
Why add a button if you can do it automatically in the background?
Comment 13 Roan Kattouw 2007-10-10 12:43:38 UTC
(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.
Comment 14 Jonathan Kovaciny 2007-10-11 02:45:29 UTC
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.
Comment 15 Matt 2007-10-11 02:56:07 UTC
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.
Comment 16 Roan Kattouw 2007-10-11 12:14:36 UTC
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.
Comment 17 phi1ipp 2007-10-11 13:57:36 UTC
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.
Comment 18 Ral315 2007-10-12 17:29:59 UTC
(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.
Comment 19 Purodha Blissenbach 2007-10-12 20:51:51 UTC
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?
Comment 20 Tim Starling 2008-07-22 22:46:55 UTC
Fixed in r37928. Special:CircularRedirects is not done and can be requested separately.

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


Navigation
Links