Open main menu
This user account is a bot operated by Rillke (talk). It is not a sock puppet, but rather an automated or semi-automated account for making repetitive edits that would be extremely tedious to do manually.
Administrators: if this bot is malfunctioning or causing harm, please block it.

taskscontribscountlogspage moves block user block logflag logglobal contribsflag bot


How to use it?


It is now possible to transclude your upload count to your user page. This bot will update these statistics every 24 hours.

How can You use it?
  1. Create a subpage in your user namespace. For example, Special:MyPage/top uploads with the following content: {{UploadStats/alive}}.
  2. Wait 24h for the bot updating the page.
  3. Transclude Special:MyPage/top uploads{{User:Example/top uploads}} to your user page.
  1. I created User:Rillke/testpage.
  2. The page was updated by the bot after, at maximum, 24 hours.
  3. Now I could use a fancy userbox, for example
    {{Userboxtop|extra-css=float:right; clear:right;}}{{MyGallery/userbox |1=Rillke |heading='''{{User:Rillke/testpage}}''' uploads }}

Rillke(q?) 07:48, 19 April 2014 (UTC)

More exhaustive explanation

As an experienced user as you are, you know that a file revision can have 3 states, each of them stored in a different table by MediaWiki — because moving files around and updating different tables is so incredibly efficient: We distinguish top revisions [saved in a table called image for what’s worth], old revisions [visible on file description pages but no way including them in articles — old_image table] and archived files [deleted files — filearchive table]. Users interested in showing how much they have uploaded may create a subpage in their user namespace;Tuvalkin created User:Tuvalkin/top uploads, for example. On this page, one of the {{UploadStats/...}} templates can be placed:

If one of the above templates is placed as the only content on a subpage in the user namespace, UploadStatsBot will visit this page every day and update these statistics. To show these statistics on a user page, after the bot came to your page the first time, users just have to include or (technical term) transclude the formerly created page into their user page, e.g. doing this.

UploadStatsBot (talk · contribs)

The first bot on Commons driven by node.js?

Operator: Rillke (talk · contributions · Number of edits · recent activity · block log · User rights log · uploads · Global account information)

Bot's tasks for which permission is being sought:

Automatic or manually assisted: Automatic, running on wmf-labs.

Edit type (e.g. Continuous, daily, one time run): daily, currently at 03:20 UTC

Maximum edit rate (e.g. edits per minute): No throttle, just following mw:API:Etiquette. Sheduled by xcrontab, job submitted to grid engine.

Bot flag requested: (Y/N): N

Programming language(s): JavaScript. Running on Node.js - source code will be available on GitHub soon (it's on labs, /data/project/upload-stats-bot/)

Q & A

But node.js is slow!
True, it isn't the fastest but I am not using jsdom. Still, >1G memory is required. The nice part however is that the grid engine can decide when to execute the job. And once node is loaded, it is executing in a comparable speed with other interpreted languages.
Are you running heavy SQL queries?
No. The query getting the upload count takes (execute+fetch) < 0.1s -- This is faster than some queries run by MediaWiki when navigating to special pages.
Can the bot be used to vandalize pages?
First, someone has to insert the template. Then, the bot will replace that page by the template + upload count. However, there are some heuristics to prevent vandalism like checking the page size before and if it's too huge, the page is skipped. In other words users who would be otherwise blocked by AbuseFilter can't use it as a tool for page-blanking.
Is there a limit of pages updated by the bot?
Currently, the bot's execution time is limited to 90s and there is a limit of 500 pages.

Rillke(q?) 23:38, 9 April 2014 (UTC)


Currently suffers from some badtoken errors (so not all pages are updated with every run), I'll have to investigate that. -- Rillke(q?) 23:38, 9 April 2014 (UTC)
Pictogram voting keep.svg Fixed. The issue was that tool-labs has such a fast connection to the servers that, if you request multiple edit tokens, they are not replicated before the next sever is replying to your request, consequently they are all different and only one of them is accepted when it comes to using them. -- Rillke(q?) 08:52, 10 April 2014 (UTC)
Looks OK for me. --EugeneZelenko (talk) 14:21, 10 April 2014 (UTC)

If there are no objections, I think task should be approved. --EugeneZelenko (talk) 14:32, 12 April 2014 (UTC)


  • 2015-12-24: An issue that caused hitting the rate limit early has been fixed. If we hit the rate limit again, we must implement more elaborate editing techiques, e.g. by querying the rate limit in advance and then scheduling a break between every edit. Currently we just wait for one edit to finish, which happens lightning fast when accessing Wikimedia from its own data-center. -- Rillke(q?) 23:18, 24 December 2015 (UTC)