Page MenuHomePhabricator

Discussion: Where the range contributions tool should live
Closed, ResolvedPublic


Aside from technical approaches, there have been mixed feelings on where the range contributions tool (T145912) should live, what features the first iteration should include, etc. I'm opening this ticket so we can have a dedicated discussion.

For this let's assume we want all requirements, bells and whistles, to be included in the initial release, even though this may not be true.

Arguments we have thus far regarding where it should live:


  • Separates the advanced functionality (automated WHOIS, geolocation, range calculator, etc., e.g. T152114) from the basic functionality Special:Contribs offers. Users can essentially think of it as a standalone tool for power users, as they do now with XTools.
  • We don't have to rework the Special:Contribs code, meaning we can get this out the door much faster. E.g. ContribsPager.php among others aren't built to group of results with headings like F5013937.
  • We don't necessarily have to include this in core. As a separate extension we could (maybe?) finish this even faster, or at least release it as a proof of concept before considering merging it into Special:Contribs.
  • We presumably can update the CIDR links in the block log to point to Special:RangeContribs. They currently link to Special:Contribs (example).
  • Because of the nice advanced features, wikis might change all their templates and system messages to go to Special:RangeContribs instead of Special:Contribs, and hence new users might get thrown into it without any choice.
  • Logically users would expect ranges to work at Special:Contribs, and not have to go to a separate special page. However, we might redirect to Special:RangeContribs if it is detected they entered a range.


  • This is where users would expect ranges to work. Instead of typing in a single IP you type in a range.
  • In its simplest form, it should not be that hard to allow querying of ranges and show them sorted by date, but we want to keep the advanced features in mind.
  • Eliminates confusion of two Special pages that do the same thing for single IPs.
  • We don't need to update any links across MediaWiki that link to ranges (like the block log).
  • The advanced features will be too "in your face" for most users, such as the WHOIS, geolocation, range calculator, and list of subranges and individual IPs that are blocked within the requested range. We'd have to put all of this behind a preference, and we arguably have too many preferences as it is.
  • Development costs. Having to rework ContribsPager, etc., to meet our needs could add months of work.


Event Timeline

@Legoktm also proposed the idea of an AdvancedContribsPager.php. I think dealing with Special:Contribs itself will still present a challenge, but not having to rework the existing ContribsPager should save us a lot of time.

I can't speak to the underlying technical considerations, but from a user's point of view, and considering your comments, I'd much rather have it at Special:RangeContributions than have to wait possibly additional months for it to be released: given how often the Labs tool goes down, this feature is badly needed in MediaWiki.

If there are concerns about wikis adapting their templatage too soon, it would be reasonable to do something like write a banner at the top of RangeContribs, saying "this feature is experimental and may change or break without warning" and discourage template changes. Likewise potential changes to block logs and MediaWiki messages can be left until a later stage, when the long-term decision about method of integration has been made. Hiding it away for now isn't a big problem because I expect it will be mostly a power user feature anyway.

Thank you for all the work you've been doing on this.

Special:RangeContributions. "Users can essentially think of it as a standalone tool for power users, as they do now with XTools." - yes. Right now all registered editors can use the same tools admins do when calculating ranges and looking at contribs. Most of them don't because they don't want to take the time to understand what they're presented with or they view it as an "admin" job. Don't think this spiffy new tool (thank you, thank you, thank you @MusikAnimal ) will result in a major change in that behavior.

TBolliger claimed this task.
TBolliger moved this task from Older: Team Work to Archive on the Community-Tech board.
TBolliger added a subscriber: TBolliger.

Appears to be resolved and decided in T145912