Page MenuHomePhabricator

Closed, ResolvedPublic


Author: soxred93

On enwiki, the user group rollbackers is enabled. So, a template was created (see URL), because there was no magic word for the amount of rollbackers. SQLBot currently updates it. I have submitted a patch, which updates SiteStats.php and Parser.php, creating that new magic word. I have tested it, and it works. All it needs is to be implemented. Thanks!


Version: unspecified
Severity: enhancement



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:02 PM
bzimport set Reference to bz13471.
bzimport added a subscriber: Unknown Object (MLST).

soxred93 wrote:

Proposed patch

attachment imagediff.txt ignored as obsolete

ayg wrote:

  1. Your patch seems to mix up rollbackers and bureaucrats. It looks as though it will result in a fatal error, since you called a nonexistent function SiteStats::crats().
  1. The word 'rollbacker' must occur nowhere in the patch. We will not incorporate explicit references to usergroups that do not exist in the core software. Generalize this to a NUMBERINGROUP function or something, and it might be committed.

soxred93 wrote:

Better patch

(used wrong patch)

attachment imagediff.txt ignored as obsolete

random832 wrote:

Why not just have [[Template:NUMBEROFROLLBACKERS]] and have people update it manually whenever someone gets it? It worked for Pokémon.

ayg wrote:

It's still not acceptable to refer to enwiki-specific groups like that in core code.

This also may be a performance issue for potentially very large groups like rollbacker. Over time I expect it will grow to tens of thousands or more, and all those index nodes will have to be scanned. If this feature is really desired, another usergroup table could be added to store the size of each usergroup, like the new category table, but that seems pretty excessive.

soxred93 wrote:

Ok, working on {{NUMBEROFGROUPUSERS:rollbacker}} now.

soxred93 wrote:

One thing you might not have noticed: This is for Wikimedia, not MediaWiki.

Corrected component. It should be MediaWiki.

ayg wrote:

Correct. All software changes are filed under either MediaWiki or MediaWiki extensions, because that's where the changes must be made. Wikimedia is only for configuration changes, which this is not. In principle, Wikimedia does not maintain live hacks: everything gets committed to the core software. (In practice some admins do maintain live hacks, which periodically get cleaned up and committed to avoid merge conflicts on svn up.)

ayg wrote:

Um? Any reason for RESOLVED LATER? If someone wants to work on this they can. LATER should usually be used on MediaWiki bugs for when the bug cannot be fixed now for some reason no matter what code we write (for instance, inadequate upstream support for something) but may be fixable at some later date.

soxred93 wrote:

Oh, sorry. I thought that meant like a withdrawal or something.

ayg wrote:

You can un-assign yourself using "Reassign bug to default assignee and add Default CC of selected component". That's not really resolving the issue, though, is it? It doesn't set it to RESOLVED, it sets it to NEW.

soxred93 wrote:

New patch, implementing {{NUMBERINGROUP}} parserfunction

New patch:

Instead of {{NUMBEROFROLLBACKERS}}, it has been changed to {{NUMBERINGROUP}}

Usage: {{NUMBERINGROUP:(group)}}
Raw: {{NUMBERINGROUP:(group)|R}}

attachment my.patch ignored as obsolete

soxred93 wrote:

Sigh, fix spaces