Page MenuHomePhabricator

Make Special:ActiveUsers controllable by a configuration variable
Closed, DeclinedPublic

Description

https://gerrit.wikimedia.org/r/107988 unconditionally disabled Special:ActiveUsers for all miser mode wikis, including all the small Wikimedia projects who knows how many thousands small wikis where the special page causes no problems.

The active users special page should be enableable via a configuration setting, e.g. $wgEnableSpecialActiveUsers, disregarding the miser mode setting. We can leave $wgEnableSpecialActiveUsers false by default and keep honouring the miser mode flag for now if really needed, as long as it's possible to enable it without disabling miser mode.


Version: 1.23.0
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=41078
https://bugzilla.wikimedia.org/show_bug.cgi?id=60436

Details

Reference
bz60468

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:04 AM
bzimport set Reference to bz60468.
bzimport added a subscriber: Unknown Object (MLST).

I don't think adding yet another global configuration variable is a good idea here.

(In reply to comment #1)

I don't think adding yet another global configuration variable is a good idea
here.

Is there any other existing configuration variable we can rely on? Miser mode is obviously not adequate and, until there is one, WMF devs will keep removing this useful special page from everyone's core just for few WMF wikis' problems.

(In reply to comment #2)

(In reply to comment #1)

I don't think adding yet another global configuration variable is a good idea
here.

Is there any other existing configuration variable we can rely on? Miser mode
is obviously not adequate and, until there is one, WMF devs will keep
removing this useful special page from everyone's core just for few WMF wikis'
problems.

Until Special:ActiveUsers' performance problems can be addressed, putting it behind $wgMiserMode as a temporary measure seems acceptable. For small and medium Wikimedia wikis, we should simply disable $wgMiserMode. :-) Thoughts on that? We could re-purpose this bug or file a separate bug, if one doesn't already exist.

(In reply to comment #3)

Until Special:ActiveUsers' performance problems can be addressed, putting it
behind $wgMiserMode as a temporary measure seems acceptable.

Who said "temporary"? Is someone working on making it more efficient? Also, I don't think it will ever get efficient enough for the English Wikipedia and until it affects en.wiki it's liable to be killed any time for everyone, as we've seen.

For small and
medium Wikimedia wikis, we should simply disable $wgMiserMode. :-) Thoughts
on
that? We could re-purpose this bug or file a separate bug, if one doesn't
already exist.

Sure, worth considering, but definitely another bug. We can't ship a MediaWiki release without Special:ActiveUsers, so this one has a deadline.

I should have replied more directly initially. Let me try again.

(In reply to comment #0)

https://gerrit.wikimedia.org/r/107988 unconditionally disabled
Special:ActiveUsers for all miser mode wikis, including all the small
Wikimedia projects who knows how many thousands small wikis where the special
page causes no problems.

"Unconditionally" seems like a strange wording choice here. It's behind the $wgMiserMode configuration variable now, as far as I can tell. That's not unconditional, that's the opposite. By default, $wgMiserMode is false, so any small wiki will presumably be completely unaffected by this change, I think. Am I misunderstanding or mistaken?

Wikimedia wikis are affected because all Wikimedia wikis set $wgMiserMode to true, regardless of wiki size. A bit of searching reminded me of bug 46098, of course.

(In reply to comment #4)

(In reply to comment #3)

Until Special:ActiveUsers' performance problems can be addressed, putting it
behind $wgMiserMode as a temporary measure seems acceptable.

Who said "temporary"? Is someone working on making it more efficient?

There should be a bug about making Special:ActiveUsers efficient enough (similar to bug 10593). There should also be a bug about ultimately killing $wgMiserMode. I consider it a hack. I don't think we should encourage second-class features. We should either support the features fully in core, kill them, or put them into an extension.

I'm not sure either of these bugs exist yet.

Not really, the special page was killed in core twice already for WMF's sake and the same will probably happen again. But rejection is rejection. :)