Very nice Gadget. However, at german wikipedia we mostly need /17 up to /22, maybe there is some fast way (multiple requests for smaller ranges? bigger requests and postfiltering?). Regards, Codeispoetry (talk) 11:48, 26 March 2008 (UTC)[reply]

That would require rewriting the script to use ajax POST, as the GET request used in the <script> is limited to around 4000 characters (which just fits in a /25). The problem however quickly becomes mathmatical: 255.255.255.255/24 is 3986 characters (even though /24 uses ucuserpreifx, which can only be done meaningfully for /8, /16, /24):

ucuser=255.255.255.0|255.255.255.1|255.255.255.2 ... 255.255.255.255.

255.255.255.255/22 would be 15944 characters, 255.255.255.255/17 would be over half a meg... I don't think supporting down to /17 would be very good. --Splarka (rant) 07:22, 27 March 2008 (UTC)[reply]

Per the copy from my userspace currently here, and with some modifications made to the API, there are some problems with this gadget.

• Some optimizations of ApiQueryUserContributions.php means that it currently sorts by username first, instead of by date. So the first users found will fill up the specified limit before more users are found. Not really a good JS solution, waiting on a solution in the API (such as a dedicated CIDR function).
  • The optimizations have also broken pagination, there is not yet a solution to this. This is fixed in newer versions of the API.
• /25 and /26 ranges may currently be broken, due to a hard-coded limit of 50 parameters (this module performs uneven CIDR ranges using a pipe separated list &ucuser=1.2.3.0|1.2.3.1 ... but the list limit is 50 (the sysop limit of 500 is not applicable, due to the callback method used)). Possibly this could be overcome by rewriting this as an ajax module, but hopefully a CIDR function will be made available.

Really, the best solution is to write in CIDR support into the Special:Contributions page server-side and do away with this gadget ^_^. Caveat emptor: As it is now it is not really useless, but results may be deceptive and not all inclusive. --Splarka (rant) 03:18, 11 May 2008 (UTC)[reply]

See update below. This section might need cleanup after next sync. --Splarka (rant) 11:19, 25 October 2008 (UTC)[reply]

Perhaps someone can explain why Special:Contributions/71.100.0.15's edits are not showing up at Special:Contributions/71.100.0.15/16. This is a bug, if I'm not mistaken. The Evil Spartan (talk) 19:37, 15 July 2008 (UTC)[reply]

Per the above section, they would show if the API were as it was when this script was written, but several changes have made pagination pretty broken (and unsupportable in javascript, actually). It should work if you do something less specific, eg: Special:Contributions/71.100.0.15/28. --Splarka (rant) 07:05, 16 July 2008 (UTC)[reply]

Can't we do this with a toolserver tool?

The query seems to be reasonably simple:

SELECT rev_user_text,rev_title,rev_comment,rev_timestamp FROM revision WHERE rev_user=0 AND rev_user_text LIKE '12.34.%' AND inet_aton(rev_user_text)<some_num AND inet_ntoa( rev_user_text) > some_num;

Werdna 05:12, 28 September 2008 (UTC)

tools:~vvv/rangecontribs.php can show IP range contribs (it accepts 1.2.3 or 1.2), but it says "this tool is temporary disabled for enwiki because of some performance reasons". —AlexSm 03:54, 29 September 2008 (UTC)[reply]

Per rev:42198 it is now possible to accurately continue the query once again. I've rewritten the script heavily in order to take advantage of this, and am testing it now at User:Splarka/contribsrange.js (new permlink but more changes may occur).

New features:

• Redesigned output a bit. Uses DIVs and UL/LI sets instead of text and BR. Also uses progressive status thingy next to spinner.
• Will now query-continue almost forever. It stops after 10,000 edits found unless you bypass this (link provided in abort message).
• Groups them by contributor, similar to enhanced recent changes. If there is only one match, it expands this, else all are collapsed.
  • Tells you by each contributor the number found.

Any objections to syncing this gadget with my copy (after a day or two)? Any suggestions/thoughts on improvements/streamlines? --Splarka (rant) 11:17, 25 October 2008 (UTC)[reply]

I like the sound of that. I've had to press "ctrl+f" to find the date of recent edits. Ah, and I'm having some other issues with the way the results are limited to being shown chronologically.

For example, when the CIDR prefix of a range is /20 (like 74.230.96.0/20), then I have to search for Special:Contributions/74.230.96.0/16 so that I don't miss anything. I have to click "next 500" to show the third octet below 74.230.86.x. It does gradually get lower, but it's outdated as well, as you can see in the address bar. Is that solved, or is it still going to be an issue?

Also, I'm wondering if there's a way to make this tool globalized, because the one on toolserver, which doesn't work on enwiki, can be used for other projects. That tool sorts it by date and chronologically but can't navigate to the older edits; it also lacks something that this one doesn't, which is entering queries in CIDR notation (which is used to determine rangeblocks).

Otherwise, I'm fine with it all. I can't say I've tried out Splarka's update yet, but when you can safely say that it's stable (whenever that is), then that's when I might try it out :P I'm sure that it's a great tool and it definitely has a lot of potential. ~ Troy (talk) 19:40, 26 October 2008 (UTC)[reply]

The update solves the 'next 500' issue by ... well, try it out. It will find up to 10,000 (and more if you decide to continue). It is now synched, and there should be no outstanding issues (except possibly with /25s, use /24 if you want to be sure) that I know of. Let the testing begin....? --Splarka (rant) 22:52, 5 November 2008 (UTC)[reply]

Looks like it works out ...but there's one tiny problem. I can't seem to expand them all. Otherwise, it works pretty well. Of course, I can't complain; I would never be able to work these issues myself (what a pity :P) ~ Troy (talk) 05:15, 6 November 2008 (UTC)[reply]

Oops, I never considered stylepath would be non-local. Small tweak may be needed here. --Splarka (rant) 09:23, 18 November 2008 (UTC)[reply]

Had to disable /25 and /26 due to API parameter count restrictions. Use /24 instead. --Splarka (rant) 10:03, 3 December 2008 (UTC)[reply]

The widget preference page says to report any issues here, so (a copy of my comment here):

Broken? http://en.wikipedia.org/wiki/Special:Contributions/46.235.152.24 shows changes that http://en.wikipedia.org/wiki/Special:Contributions/46.235.152* does not - it shows edits by .21 and .41 only - not these edits by .24 ! I have the gadget enabled, and was unable to search using CIDR - my attempts produce "No changes were found matching these criteria."

Yet, the help text states, "You may enter a CIDR range or append an asterisk to do a prefix search."--Elvey (talk) 20:57, 28 May 2013 (UTC)[reply]

See Wikipedia:Village_pump_(technical)#Contribs_from_a_CIDR_range_out_of_date.3F. Change the "year" field to 2014 manually to work around this for now. --Splarka (rant) 21:18, 28 May 2013 (UTC)[reply]

For anti-vandalism purposes, this would be much more useful if it could give results since rather than before the date. Better yet, the ability to sort results by most-recent use. An ip-hoping vandal often hops shortly after a block, a pattern that should be easily detected.LeadSongDog come howl 16:14, 27 May 2009 (UTC)[reply]

Using since or even a narrow date range is possible with this specific API query, but not with the Special:Contributions UI. This would involve creating UI elements which is also possible but cluttery and possibly confusing to the interface. Sorting by date in the query is not possible, because of the method used to return the results (which sorts by user first, then by date). It could only sort the results by date upon completion of /all/ queries, which, if it were many thousands, could freeze the browser for several seconds or minutes. This would be best done with a toolserver tool, probably. --Splarka (rant) 07:35, 28 May 2009 (UTC)[reply]

I must be missing something. How, exactly, is a "since" query possible? LeadSongDog come howl 16:10, 9 September 2009 (UTC)[reply]

Here is an example. It shows a day of edits for &ucuserprefix=195.229.242. (195.229.242.0/24) using the parameters: &ucdir=newer&ucstart=20070101000000&ucend=20070102000000 . The problem is, this gadget works off of the existing Special:Contributions UI which wouldn't permit such specificity. I could probably add some dummy URI parameters that you could type manually though. --Splarka (rant) 07:44, 10 September 2009 (UTC)[reply]

Oh, I guess I already did. This version allows ucstart and ucend to be supplied manually via URI parameters. It just needs to be synched with the gadget. --Splarka (rant) 08:10, 10 September 2009 (UTC)[reply]

Okay, done. Try a URL like this. Note it has to be done manually. --Splarka (rant) 08:43, 10 September 2009 (UTC)[reply]

Thank you, thank you. That does it. The gadget will be a big help.LeadSongDog come howl 13:57, 10 September 2009 (UTC)[reply]

Seems all the diffs are of the form http://en.wikipedia.org/w/index.php?title=-&curid=2525061&diff=87268322 Which all have an invalid title parameter. Q ^{T C} 22:10, 12 June 2009 (UTC)[reply]

Nevermind, seems to be the Popups gadget not liking having the title parameter and tries to load those revisions of the - article. Since diffs work the same regardless and you're already pulling it from the API why not include the correct title parameter to appease Popups? Q ^{T C} 22:20, 12 June 2009 (UTC)[reply]

It is there because &curid used to only work if a &title parameter was included, even though it was totally ignored. This was fixed after I wrote the script, so it could be removed. I guess I didn't include the full title because it was a bit spammy and redundant. --Splarka (rant) 00:30, 13 June 2009 (UTC)[reply]

Per these changes it should work now. But popups definitely should recognize &curid and ignore &title if present, as well as properly handling &diff=number as &diff=prev&oldid=number and NOT as &diff=next&oldid=number as it seems to. --Splarka (rant) 06:11, 13 June 2009 (UTC)[reply]

Great gadget, but there seems to be a compatability issue with Internet Explorer 8. In IE8, the Expand All button does not work (it works in Firefox on the same computer).

Also, it would be useful to have a Condense All button as well as the Expand All button, especially when doing a /16 search. Thanks. --Zach425 ^talk/contribs 12:59, 30 August 2009 (UTC)[reply]

I don't know how to fix it for IE8, unless it was a recursive template call problem (in which case it should be fixed). I've changed the button to 'toggle all' which should switch all lists to the opposite visibility of the first one (inclusvely). So if the first one is expanded, they will all be collapsed, etc. --Splarka (rant) 08:46, 10 September 2009 (UTC)[reply]

Two issues I'd like to bring up:

• 1) The sort is done in alphabetical order, which is icky for numbers. It would be nice to code in an instance of making it go numerically, if not too processor intense.

• 2) Doing ranges other than /16 /24 or (obviously) /32 would be really nice. And, if you think outside the box a bit, you'll realize it can be done quite easily by just parsing the results on the client end. So a /17 wouldn't necessarily mean 2^15 searches... rather just pruning the /16 result once we retrieve it. Magog the Ogre (talk) 16:04, 19 November 2010 (UTC)[reply]

See Wikipedia:Village pump (technical)#Username with trailing wildcard. DMacks (talk) 18:46, 10 June 2012 (UTC)[reply]

The Preferences page entry for this says that it does wildcard prefix searches, e.g., Splark*. But it also seems oriented towards Special:contribs. So, I just have to ask, being search and prefix oriented at the moment: Do you mean prefix as in the search parameter prefix:? I'm pretty sure I'm off here, but there is documented at Help:Search the prefix: parameter as applies to page names, not users. I was just searching through gadgets for search gadgets, and found four of them, and could not help tripping over yours as a possible fifth one. (Besides that wording there is another: at first the "wildcard prefix" in the example looked like a suffix, 'til I finally got that it meant the name was a prefix.) Cheers. — CpiralCpiral 09:22, 24 April 2013 (UTC)[reply]

IIRC it wasn't as confusing at the time, as the "prefix:" parameter was added to search several months after that description was phrased: [1] vs [2]. I am not sure of a good way to rephrase, maybe "trailing wildcards" or something? --Splarka (rant) 16:43, 25 April 2013 (UTC)[reply]

I'm looking for all contribs from 194.61.160.0/20. I see from the description on the prefs page that /20 is not supported, so I looked for 194.61.162.0/24 to start with: [3]. This yields:

but not 194.61.162.79, even though there are contribs for that address here. I also tried searching for 194.61.162* and got the same results as above. Searching for 194.61.0.0/16 and 194.61.16* yield many more results, but still not 192.61.162.79. —[AlanM1(talk)]— 17:24, 26 June 2013 (UTC)[reply]

There is a bug in the currently deployed version that is fixed in User:Splarka/contribsrange.js. See this explanation as to why it has only recently become an issue. Quick workaround is to change the year to 2014. --Splarka (rant) 09:05, 27 June 2013 (UTC)[reply]

Cool. Do you know of a way I can change the Contributions link that appears in the linklist at the upper right of pages (with Talk, Sandbox, Preferences, Watchlist, Contributions, Log out) to https://en.wikipedia.org/wiki/Special:Contributions/AlanM1?year=2014 to populate the year automatically with the workaround value? —[AlanM1(talk)]— 06:00, 28 June 2013 (UTC) —[AlanM1(talk)]— 06:00, 28 June 2013 (UTC)[reply]

You could do it with a script, but it would probably be easier to find a mod and convince them to test and update the gadget (or just use User:Splarka/contribsrange.js directly). --Splarka (rant) 07:04, 28 June 2013 (UTC)[reply]

((Editprotected)) see [4], fix 'toggle all'. ref. --YFdyh000 (talk) 07:07, 9 January 2014 (UTC)[reply]

That's not the right fix. It will break on older browsers. We should use jquery. —TheDJ (talk • contribs) 18:13, 14 January 2014 (UTC)[reply]

done using jquery —TheDJ (talk • contribs) 18:18, 14 January 2014 (UTC)[reply]

oh, thanks for remind, jquery is a good idea. merely it seems only break for IE6-IE8.--YFdyh000 (talk) 05:38, 16 January 2014 (UTC)[reply]

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Hi!

Could someone apply these updates to the gadget? Thanks! Helder.wiki 20:29, 28 February 2014 (UTC)[reply]

Helder.wiki, what do you mean? Should I simply dump the entire contents of this revision into the page? I don't understand .js at all, so I need to be given very simple instructions. Nyttend (talk) 13:38, 4 March 2014 (UTC)[reply]

Yep! I usually paste the new version of the code in the sandbox to make it easier to copy, and provide a diff between the two pages to make the review easier too. So, Nyttend, in this case, you should replace the content of MediaWiki:Gadget-contribsrange.js by the content of this version of the sandbox. Helder.wiki 13:44, 4 March 2014 (UTC)[reply]

Done. Doing it like this, requiring me to do nothing except for copy/pasting all code from a page, is the best possible way to propose changes. I just wasn't sure if you were wanting that, or if you wanted me to replace part of the page, or something else. — Preceding unsigned comment added by Nyttend (talk • contribs) 22:35, 5 March 2014

• Nyttend, can you undo this change as it seems to coorolate with the issues reported WP:VPT#CIDR range contributions broken?. Helder, can you look into what might have caused this as well... When I try to bring up a CIDR range in Special:Contribs, it returns one result and then seems to lock up (Searching... doesn't go away but it doesn't return any more results). I'll run it again with ?debug=true and try to get some more information for you. — ((U|Technical 13)) ^{(t • e • c)} 00:03, 12 March 2014 (UTC)[reply]

• My comment at WP:VPT. Nyttend (talk) 00:14, 12 March 2014 (UTC)[reply]

As far as I could see by testing the previous version of the script in the console, the error reported on VPT was already happening, so I didn't think it was introduced by these recent changes. When searching for 109.157.154.0/24, this was the message in the console:

GET https://en.wikipedia.org/wiki/&uccontinue=109.157.154.86%7C2010-12-11T21:01:04Z 400 (Bad Request)

Helder.wiki 02:18, 12 March 2014 (UTC)[reply]