Last modified: 2012-11-14 12:19:27 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 17888 - set $wgMaxRedirects = 2 on en.wiki
set $wgMaxRedirects = 2 on en.wiki
Status: RESOLVED INVALID
Product: Wikimedia
Classification: Unclassified
Site requests (Other open bugs)
unspecified
All All
: Low enhancement with 9 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/w/index.php?o...
: community-consensus-needed
: 18074 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-09 16:59 UTC by Happy-melon
Modified: 2012-11-14 12:19 UTC (History)
11 users (show)

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


Attachments

Description Happy-melon 2009-03-09 16:59:55 UTC
Per the discussion in the URL (http://en.wikipedia.org/w/index.php?oldid=276064013#Double_redirects), there is clear community support for permanently enabling at least double redirects.  Assigning to Brion 'cos the next scap will close the loophole (bug17570, r47512) that currently allows double redirects on all Wikimedia wikis; this config change should be done before or together with the next scap. Severity != enhancement because we've already *got* the feature, we now don't want to lose it! :D
Comment 1 Purodha Blissenbach 2009-03-09 18:04:26 UTC
I suggest to think over setting $wgMaxRedirects=2 (minimum)
on all Mediawiki wikis, if cost warrants it.
The current setting has imho turned out quite nicely
to keep technicalities out of the ordinary users sights
while we are waiting several days before we get a new list of 
5000 duplicate redirects (:only:) which we then can eliminate.

Thus we can count this setting as yet another small step
towards better usability.

Comment 2 Russell Blau 2009-03-11 13:01:56 UTC
Bug 17934 is related to this.
Comment 3 Brad Jorsch 2009-03-21 00:21:04 UTC
*** Bug 18074 has been marked as a duplicate of this bug. ***
Comment 4 ipatrol 2009-03-21 15:10:12 UTC
I think that all the effort, confused readers, and toolserver resources used to fix double redirects is patently pointless. All that needs to be done is to disable all bots used to fix double redirects and change the setting. Triple redirects are very rare and are a bad idea anyway to ever have. However, this isn't a very important problem and if the devs have more pressing matters to work on, let them do those first.
Comment 5 Brion Vibber 2009-03-26 17:18:15 UTC
This is one we probably want to start on test, pre-announce, and have people poke it a bit.
Comment 6 Happy-melon 2009-03-26 17:48:24 UTC
As long as it gets onto the carousel, that's ok.  But I expect some people are going to be unhappy when they realise that the 'Golden Age' of double redirects working on wikipedia is already over... :D

There is some thought on en.wiki about asking for very long chains (eg 10) to be allowed so we have more flexibility in building chains with semantic clarity.  Are there performance and/or security considerations with that, or is it something we can legitimately think about (and potentially ask for)??
Comment 7 Le Chat 2009-03-27 08:27:57 UTC
I'm not sure I understand what Brion is suggesting. Surely this has been tested, since it's a feature of the software, and has in effect been operative on en.wp for some time because of the other bug. Since the community has clearly expressed the will for the change (i.e. for the current effective setting to continue after the other bug is fixed), and making the change presumably takes no effort at all on the part of the devs, I don't see any reason for it not to be done. 
Comment 8 Russell Blau 2009-03-27 13:34:41 UTC
Regarding Comment #4: Triple-redirects are very rare ''because'' bots now fix all double-redirects soon after they are created.  Once double-redirects are allowed, triple-redirects will no longer be rare.  If we allowed septuple-redirects, eventually we would start accumulating octuple-redirects.  Whatever level of redirection is allowed, we still need (a) a mechanism for identifying those redirects that exceed the maximum level, and (b) a protocol for fixing them.
Comment 9 ipatrol 2009-03-30 02:55:36 UTC
(In reply to comment #8)
> Regarding Comment #4: Triple-redirects are very rare ''because'' bots now fix
> all double-redirects soon after they are created.  Once double-redirects are
> allowed, triple-redirects will no longer be rare.  If we allowed
> septuple-redirects, eventually we would start accumulating octuple-redirects. 
> Whatever level of redirection is allowed, we still need (a) a mechanism for
> identifying those redirects that exceed the maximum level, and (b) a protocol
> for fixing them.
> 

We could continue the use of the double redirect bots, which will minimize disruption (as many bots fix double redirects as a side task) and triple redirects. On en.wp, the abuse filter could also be set to disallow moves or edits  resulting in triple redirects, or possibly even both. I still think that as long as we aren't asking for the impractical, consensus and its occasionally twisted logic should be the guiding force.
Comment 10 Kevin Norris 2009-09-03 01:43:16 UTC
Out of idle curiosity, does the zero-one-infinity rule apply to (number of levels of indirection for redirects)?
http://www.catb.org/jargon/html/Z/Zero-One-Infinity-Rule.html
Comment 11 Roan Kattouw 2010-04-19 08:22:32 UTC
Mass-unassigning shell bugs from myself to Rob; I used to do them once, but I
don't have time for them any more.
Comment 12 Rob Halsell 2011-05-13 10:46:17 UTC
Ok, going to ping about this.  We are ok to put it in, but we want to ensure it is still wanted/required as this bug is INSANELY old.

I am putting this in for request, and resolving the bug.  Please do not hesitate to re-open it if it is indeed still wanted.
Comment 13 Nemo 2011-05-13 10:51:19 UTC
I think this is still desired pretty much on every wiki, as pointed out above.
Comment 14 Purodha Blissenbach 2011-05-13 17:18:03 UTC
Not only old. It's outdated. Any number redirects are possible per 
$wg(someting) parameter, and it as been set to 2 on most or all WMF
wikis.
Comment 15 ipatrol 2011-05-13 21:09:11 UTC
I think it's safe to say we're done here. Though the bots will likely continue to fix them, our readers will no longer encounter the pervasive problem with double redirects. With the fix in place, I suggest that if anyone wants to add a comment, they should also reopen this bug.
Comment 16 Nemo 2011-05-14 06:55:49 UTC
(In reply to comment #14)
> Not only old. It's outdated. Any number redirects are possible per 
> $wg(someting) parameter, and it as been set to 2 on most or all WMF
> wikis.

Can someone provide some example? Redirects on [[Special:DoubleRedirects]] are not working on all wikis I checked.
Comment 17 Amalthea 2011-05-14 09:07:08 UTC
(In reply to comment #14)
> Not only old. It's outdated. Any number redirects are possible per 
> $wg(someting) parameter, and it as been set to 2 on most or all WMF
> wikis.

$wgMaxRedirects is still set to 1, see http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/DefaultSettings.php?view=markup

I'm sure increasing the number of allowed redirects is still desired -- at least 2, personally I would like to have it at 3 to allow for some frequent, valid redirect chains.
Rob, do you require another straw poll from the community, or is support here sufficient?
Comment 18 Sam Reed (reedy) 2011-07-08 23:40:20 UTC
Closing per above
Comment 19 Amalthea 2011-07-09 00:39:09 UTC
Reedy: What "above" are you referring to?

$wgMaxRedirects is still set to 1. Double-Redirects do not work. Where does this "work for you"?
Comment 20 Sam Reed (reedy) 2011-07-09 00:40:16 UTC
(In reply to comment #15)
> I think it's safe to say we're done here. Though the bots will likely continue
> to fix them, our readers will no longer encounter the pervasive problem with
> double redirects. With the fix in place, I suggest that if anyone wants to add
> a comment, they should also reopen this bug.
Comment 21 Amalthea 2011-07-09 00:49:04 UTC
Ok, what about comment #16 and comment #17? :) I just tried it again at [[User:Amalthea/rd1]], thinking that I'm missing something, but no, still doesn't work.
Comment 22 Sam Reed (reedy) 2011-07-09 00:52:04 UTC
There's no "consensus" at the moment, so it's not actionable...

Changing the number to fix it is easy enough, when we decide what we want to do ;)
Comment 23 Amalthea 2011-07-09 08:12:56 UTC
Right, you closed it as WORKSFORME though. Whether there is still consensus is a different question, and exactly the one that I asked in comment #17: enWP had a straw poll 28 months ago, when this issue was opened. I've seen no objections here or anywhere  (except maybe that bug 17934 should be worked on first), but if you don't consider this enough, say the word and I'll go ask again at enWP.
Comment 24 Nemo 2011-07-09 10:10:41 UTC
(In reply to comment #23)
> Right, you closed it as WORKSFORME though. Whether there is still consensus is
> a different question [...]

Until we have the answer, let's remove "shell" keyword.
Comment 25 Amalthea 2011-07-12 11:11:59 UTC
(In reply to comment #24)
> Until we have the answer, let's remove "shell" keyword.

Hmm, that will only delay resolution of this issue, someone with shell access will have to say whether the poll we had is sufficient.
Comment 26 Aaron Schulz 2011-08-10 17:22:34 UTC
I can't say that's enough people for a consensus.

What are the drawbacks of this?
Comment 27 Sam Reed (reedy) 2011-09-07 14:58:07 UTC
Come back when this actually needs some action
Comment 28 Nemo 2012-11-14 12:19:27 UTC
Switching from LATER to the second most relevant resolution for fear of information loss. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/65116

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


Navigation
Links