Jump to content


From mediawiki.org

Changes for Special:AggregateGroups[edit]

These are the fixes that we are aiming at for Special:AggregateGroups

  • Allow aggregate group name and group description to be changed on Special:AggregateGroups. - [Bug 36298]
  • Make Special:AggregateGroups output a special page when permissions insufficient (bug number?)


  • Have an edit button beside the remove button to change the name and description.
  • Implement different display forms for the 2 cases with a parameter in the form which displays the optional parts.

Current progress[edit]

  • Reading up and understanding the code
  • Implemented a method in API to change the name and description.
  • Implemented UI method to use API
  • Bug fixed :)
  • Made Special:AggregateGroups read only when user lacks permissions. Merged :)
  • Finished first patch for performance improvements in Special:AggregateGroups. Replaced group selector by autocomplete input box.

Performance improvements in Special:AggregateGroups[edit]

Working on Special:AggregateGroups performance improvements was kind of a challenging task. The group selector had to be replaced with an autocomplete input box.

Improvement suggested by Nikerabbit. Special:AggregateGroups is too slow when the number of groups is huge. It might be because of so many group selectors.

Try 1 Yes Done
Replace group selector UI with an autocomplete input box for selecting subgroups.

Results: Wiki with 600 groups and 20 pages per group

With old selector Time: 8.06105 Memory: 35.44 MB (Peak: 35.62 MB)

With new selector Time: 4.73612 Memory: 32.44 MB (Peak: 32.62 MB)


  • Made changes in API module to return all translatable pages.
  • Now, read all the subgroups in JS and populated the autocomplete.
  • It was required to remove the already existent groups from the autocomplete, used Jquery to get the list and populate an array which includes all that had to be excluded.
  • Had to use a global array for storing the labels and ids to be able to map easily.

Challenges faced[edit]

It breaks the searching groups using aggregate group id. Now multiple groups can have the same name as well. Is it better to create a new group followed by deleting the old one?

Nikerabbit suggested to have the same group id even on updation
This brings this bug into place, suppose a new group is created with a certain name and then the name is changed. We can never again create a group with the same name. Is it better to use the Copy group and delete existing group way?
Implemented this way- keeping the id as NAME1 automatically if the NAME is a valid aggregate group name but not a valid id.

The error part in mw.Api() doesn't work for me.

Solved with Nikerabbit's help. Need to use as mw.Api().fail( function( error_code, data ) );

There was an issue in using $this->dieUsage() and $this->dieUsageMsg()

$this->dieUsage can be used directly but for $this->dieUsageMsg the message needs to be declared already.

Gerrit patches[edit]


https://gerrit.wikimedia.org/r/#/c/135872 (Merged)

Front end

https://gerrit.wikimedia.org/r/#/c/135874 (Merged)

Read only page

https://gerrit.wikimedia.org/r/#/c/140822/ (Merged)

Performance improvements

https://gerrit.wikimedia.org/r/#/c/142053/ (Merged)