Extension talk:Usage Statistics

From MediaWiki.org
Jump to navigation Jump to search

Invalid Argument[edit]

Hi, i've been trying to get your extension going on my wiki, and it's coming up with the following error:

Warning: Invalid argument supplied for foreach() in D:\xampp\htdocs\extensions\UsageStatistics\SpecialUserStats_body.php on line 118

Code line 118:

 foreach ($u[$user] as $d => $v) {

My wiki is tied in with LDAP for all my user accounts, if this has anything to do with it? --Sasdaniels 11:28, 18 July 2008 (UTC)

LDAP is probably the culprit. The reason you are getting the error message is because on lines 83-100, the array of users is generated from the SQL query
$sql = "SELECT rev_user_text,rev_timestamp,page_id FROM " .
$db->tableName('page') . "," . $db->tableName('revision') .
 " WHERE rev_page=page_id";
You will probably have to modify this to make it work with LDAP. If you find a way, please let me know and I will incorporate it into the extension. --Gri6507 13:30, 18 July 2008 (UTC)


Here is the french version of messages:

    'fr' => array(
        'specialuserstats'        => 'Statistiques Utilisation',
        'usagestatistics'         => 'Statistiques Utilisation',
        'usagestatisticsfor'      => '<h2>Statistiques Utilisation pour [[:user:$1|$1]]</h2>',
        'usagestatisticsallusers' => 'Tous les utilisateurs',
        'usagestatisticsinterval' => 'Interval',
        'usagestatisticstype'     => 'Type',
        'usagestatisticsstart'    => 'Date de Début',
        'usagestatisticsend'      => 'Date de Fin',
        'usagestatisticssubmit'   => 'Générer Statistiques',
        'usagestatisticsnostart'  => '* <font color=red>Entrer une date de Début</font>',
        'usagestatisticsnoend'    => '* <font color=red>Entrer une date de Fin</font>',
        'usagestatisticsbadstartend' => '<b>Mauvais format de Date de <i>Début</i> ou de <i>Fin</i> !</b>',

I don't know if i can add that in the main page myself ?!

Thank you for the translation! I have added it to the source code. I also moved the extension into Subversion (see main page for installation instruction changes). --Gri6507 13:50, 7 January 2008 (UTC)


Hi Im getting this error when I load page. Otherwise everything appears to work fine.

"Warning: Cannot modify header information - headers already sent by (output started at /var/www/<sitename>/extensions/SpecialUserStats.php:19) in /var/www/<sitename>/includes/WebResponse.php on line 10"

Cant find that error reported anywhere for SpecialUserStats; please help.

What version of the extension are you using? Version 1.2 only has 17 lines in SpecialUserStats.php, so this warning seems a little odd. Can you please post the contents of your SpecialUserStats.php? --Gri6507 14:53, 20 October 2007 (UTC)

Found out what it was - php.ini still on default settings. Changed it to stop error logging to screen and it is fine now. -- 12:47, 3 November 2007 (UTC)


In your body class, you have hard-coded "wiki_" as the database table prefix. You should use $wgDBprefix instead. Here is a diff.

Index: SpecialUserStats/SpecialUserStats_body.php
--- SpecialUserStats/SpecialUserStats_body.php  (revision 3671)
+++ SpecialUserStats/SpecialUserStats_body.php  (revision 3672)
@@ -75,7 +75,7 @@
   SELECT rev_user_text,SUM(IF(rev_timestamp<\"". date("Ymd",$cur_t) ."000000\",
1,0)) AS _". date("m_d_Y", $cur_t) ." FROM
-    SELECT rev_timestamp,rev_user_text FROM wiki_page,wiki_revision
+    SELECT rev_timestamp,rev_user_text FROM {$wgDBprefix}page,{$wgDBprefix}revi
     FORCE INDEX (usertext_timestamp) WHERE page_id=rev_page
     ORDER BY rev_timestamp ASC
   ) AS totaledits GROUP BY rev_user_text
@@ -92,7 +92,7 @@
   SELECT rev_user_text,COUNT(rev_user_text) AS pages FROM
-    SELECT rev_user_text FROM wiki_page,wiki_revision
+    SELECT rev_user_text FROM {$wgDBprefix}page,{$wgDBprefix}revision
     FORCE INDEX (usertext_timestamp) WHERE page_id=rev_page
     GROUP BY page_title, rev_user_text
   ) AS pageedits GROUP BY rev_user_text
@@ -100,7 +100,7 @@
   SELECT rev_user_text,COUNT(rev_user_text) AS edits FROM
-    SELECT page_title,rev_user_text FROM wiki_page,wiki_revision
+    SELECT page_title,rev_user_text FROM {$wgDBprefix}page,{$wgDBprefix}revision
     FORCE INDEX (usertext_timestamp) WHERE page_id=rev_page
     ORDER BY rev_timestamp ASC
   ) AS totaledits GROUP BY rev_user_text

--Maiden taiwan 15:14, 21 September 2007 (UTC)

A better fix[edit]

From Rob Church:

Actually, you should use the Database::tableName() method to obtain the fully-prefixed name for a table; this also respects shared table settings, e.g. for users.

In general, though, use the Database::select() and other query-builder/wrapper functions to perform queries, if at all possible

  • it does a lot of the work of escaping various bits and dealing with constructing IN ( ..., ... ) clauses, and all manner of options and other fun.
Thanks to both for pointing this out. I know better than to hardcode values into code. It's just that I wrote that extension a long time ago - before I knew anything about prefixes. This has been updated in code v1.1. --Gri6507 16:26, 21 September 2007 (UTC)

Data displayed for all users[edit]


I don't understand the data I get displayed for all users. Here's an example (intervall=day, start-date 09/13/2007, end-date 09/24/2007):

Username, Edits, Pages,09_13_2007,09_14_2007,09_15_2007,09_16_2007,09_17_2007,09_18_2007,09_19_2007,09_20_2007,09_21_2007,09_22_2007,09_23_2007,09_24_2007,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
MediaWiki default,1,1,1,1,1,1,1,1,1,1,1,1,1,1,

Can somebody explain what those numbers are supposed to mean and if there is another way the data could be formatted?

-- 07:06, 24 September 2007 (UTC) Kate

This data is a Comma Separated Value (CSV) list of all user's usage. The data is listed in rows, where the first columns are:
  1. Username - the name of the user for whom the row of data applies
  2. Edits - the total number of times, including today, the user has edited any page. This should be equivalent to the number of times the user pressed the Save Page button when editing
  3. Pages - the total number of unique pages, including today, the user has edited. The previous column could have a very large number if the user prefers the Save Page button instead of the Show Preview button. In other words, a user can have a large number of edits for a single page. The value in this column will always be less than or equal to the Edit column.
  4. date - the total number of edits (see Edit column definition above) up to and including the date listed in the column heading.
Hopefully that clears things up. --Gri6507 12:08, 25 September 2007 (UTC)



when I try to get a by-day-display for my wiki for a longer period of time (for example start-date: 07/01/2007, end-date: 09/24/2007) I get the following SQL-Error-Messages:

Fehler in der Datenbank
Es gab einen Syntaxfehler in der Datenbankabfrage. Die letzte Datenbankabfrage lautete:
   (SQL-Abfrage versteckt)
aus der Funktion „SpecialUserStats::GetUserUsage“. MySQL meldete den Fehler „1111: Invalid use of group function (localhost)“.

When I try to get the day-to-day statistics for start-date: 09/01/2007, end-date: 09/24/2007, there's no error-message but the wiki seems to hang itself up... I just get the hourglass and nothing more. Stopping the page request via browser doesn't help, restarting the browser doensn't help either. Restarting Xampp works but seems no usable solution. :-(

-- 07:20, 24 September 2007 (UTC) kate

I have been able to reproduce this problem. The issue seems to be that there is a maximum length to the SQL query and in this instance, you are exceeding it. The basic problem is that the extension is written so that the SQL query is written in pieces, where every new date for which statistics is requested increases the length of the query. After a certain number of dates, and unfortunately, I don't know how many that would be, the SQL buffer is overrun and bad things happen. I need to fix this but I'm no SQL guru. It will take me some time to figure out the proper SQL query to avoid this. Perhaps someone can help me on that?
In the mean time, what you can do is split your query into several fragments. So, instead of going from 07/01/2007 to 09/24/2007 in one execution, split that into several like 07/01/2007 to 8/1/2007, then 8/1/2007 to 9/1/2007, and then 9/1/2007 to 9/24/2007. Alternatively, switch to a weekly interval. --Gri6507 12:14, 25 September 2007 (UTC)
This has been addressed in v1.2. --Gri6507 19:41, 29 September 2007 (UTC)

Another Bug[edit]

I tried installing this extension, but it just spews thousands and thousands of lines of errors to the php log, which look like:

[14-Dec-2007 16:46:45] PHP Notice:  Undefined index:  4428 in <snipped>\SpecialUserStats_body.php on line 88

Any ideas/suggestions/etc? I'm pretty sure I followed the instructions carefully...

It looks like this is just a settings issue with your PHP environment, which seems to have an over zealous error reporting setup by default. If you add
error_reporting(E_ALL & ~E_NOTICE);
to either your php.ini or to the beginning of SpecialuserStats.php, you should not get this error message any more. --Gri6507 16:55, 15 December 2007 (UTC)

That fixed it, thanks. A follow-up question: our wiki is tied to LDAP, which means that /nobody/ is allowed to create user accounts. How would I replace that check with (say) a check for sysop or bureaucrat status, when deciding whether to generate the graph for all users? Thanks! --Mbeerman 15:37, 17 December 2007 (UTC)
Glad to hear it worked. To address your access issue, you can change
if (!$wgUser->isAllowedToCreateAccount())
to something like
if (!in_array("groupname", $wgUser->getGroups()))
, then add some new group to your wiki with the proper name, and add some priviledged users to that group. --Gri6507 16:37, 17 December 2007 (UTC)
Last but not least: When graphing data by month, there seems to be a bug where it cuts the leading digit off of October, November, and December (e.g. you see 0/01/07 for October 1st.) --Mbeerman 17:11, 17 December 2007 (UTC)

Installation Trouble[edit]

I have followed the installation steps and am getting no results. No new entry in special pages. I did notice that both SpecialUserStats.i18n.php and SpecialUserStats.php in the SVN are missing closing php tags. Makes me think more might be missing from these files. Help?

The missing ?> tags are actually intentional, so that's not the problem. My first suggestion is to make sure that you have added the call to require_once() inside your LocalSettings.php file. If that is correct, then take a look at your web server error log. Let me know if you are still have problems. --Gri6507 16:31, 15 January 2008 (UTC)

Trouble with MediaWiki 1.11.0[edit]


after upgrading from MediaWiki 1.10.0 to MediaWiki 1.11.0 I get the following error messages when I hit "Generate Statistics":

Warning: mkdir() [function.mkdir]: Permission denied in /opt/lampp/htdocs/_fhbwiki/extensions/Gnuplot.php on line 51
Warning: chmod() [function.chmod]: No such file or directory in /opt/lampp/htdocs/_fhbwiki/extensions/Gnuplot.php on line 52
Warning: fopen(/opt/lampp/htdocs/_fhbwiki/images/gnuplot/c8cb7945fb489f395f19d969e165c150.png.tmp) [function.fopen]: failed to open stream: No such file or directory in /opt/lampp/htdocs/_fhbwiki/extensions/Gnuplot.php on line 63
Warning: fwrite(): supplied argument is not a valid stream resource in /opt/lampp/htdocs/_fhbwiki/extensions/Gnuplot.php on line 67
Warning: fwrite(): supplied argument is not a valid stream resource in /opt/lampp/htdocs/_fhbwiki/extensions/Gnuplot.php on line 70
Warning: fwrite(): supplied argument is not a valid stream resource in /opt/lampp/htdocs/_fhbwiki/extensions/Gnuplot.php on line 83
Warning: fwrite(): supplied argument is not a valid stream resource in /opt/lampp/htdocs/_fhbwiki/extensions/Gnuplot.php on line 87
Warning: fclose(): supplied argument is not a valid stream resource in /opt/lampp/htdocs/_fhbwiki/extensions/Gnuplot.php on line 88
Warning: unlink(/opt/lampp/htdocs/_fhbwiki/images/gnuplot/c8cb7945fb489f395f19d969e165c150.png.tmp) [function.unlink]: No such file or directory in /opt/lampp/htdocs/_fhbwiki/extensions/Gnuplot.php on line 95
Warning: mkdir() [function.mkdir]: Permission denied in /opt/lampp/htdocs/_fhbwiki/extensions/Gnuplot.php on line 51
Warning: chmod() [function.chmod]: No such file or directory in /opt/lampp/htdocs/_fhbwiki/extensions/Gnuplot.php on line 52
Warning: fopen(/opt/lampp/htdocs/_fhbwiki/images/gnuplot/8ca75829c0e4cfa36d1add1ebac8a04a.png.tmp) [function.fopen]: failed to open stream: No such file or directory in /opt/lampp/htdocs/_fhbwiki/extensions/Gnuplot.php on line 63
Warning: fwrite(): supplied argument is not a valid stream resource in /opt/lampp/htdocs/_fhbwiki/extensions/Gnuplot.php on line 67
Warning: fwrite(): supplied argument is not a valid stream resource in /opt/lampp/htdocs/_fhbwiki/extensions/Gnuplot.php on line 70
Warning: fwrite(): supplied argument is not a valid stream resource in /opt/lampp/htdocs/_fhbwiki/extensions/Gnuplot.php on line 83
Warning: fwrite(): supplied argument is not a valid stream resource in /opt/lampp/htdocs/_fhbwiki/extensions/Gnuplot.php on line 87
Warning: fclose(): supplied argument is not a valid stream resource in /opt/lampp/htdocs/_fhbwiki/extensions/Gnuplot.php on line 88
Warning: unlink(/opt/lampp/htdocs/_fhbwiki/images/gnuplot/8ca75829c0e4cfa36d1add1ebac8a04a.png.tmp) [function.unlink]: No such file or directory in /opt/lampp/htdocs/_fhbwiki/extensions/Gnuplot.php on line 95

I installed the newest version of the extension from the SVN-directory. I also installed the GnuPlot-Extension and checked its file-content, everything seems fine to me. I didn't reinstall GnuPlot itself as it lives outside the MediaWiki-directory, but there seems to be a permission-problem that did not occur with MediaWiki 1.10.0.

I'm not sure if my request shouldn't rather be posted on the GnuPlot-Extension page, but as I only use GnuPlot in connection with this extension I hope to find help here.

Thanks! --Katwol 14:04, 18 January 2008 (UTC)

Unfortunately, this is 100% related to GnuPlot extension. You are going to have to ask the authors of that extension for help. But it looks like all of the problems stem from Warning: mkdir() [function.mkdir]: Permission denied in /opt/lampp/htdocs/_fhbwiki/extensions/Gnuplot.php on line 51. if you can figure out how upgrading MediaWiki made changed your permissions to cause this problem, the rest should go away. --Gri6507 16:42, 21 January 2008 (UTC)
Thanks for the tipp - after taking a closer look at the code in gnuplot.php I figured out the cause of the problem: I'd forgotten to create a gnuplot-directory in my $wguploaddirectory and set the userrights for that directory to 777. No everything works fine! :-)
--Katwol 07:56, 22 January 2008 (UTC)

Date selection won't work[edit]

Hi again,

another problem I get after upgrading from MediaWiki 1.10.0 to MediaWiki 1.11.0 is that the select-link for entering the start- and end-dates doesn't work anymore. :-( When clicking on the link nothing happens...

--Katwol 14:08, 18 January 2008 (UTC)

This is odd. The code to generate the calendars is plain old JavaScript. Are you sure your browser wasn't changed to disallow JS? When you view the source for the wiki page once it's loaded, do you see the large gobs of Javascript? --Gri6507 16:44, 21 January 2008 (UTC)
I've compared the current (downloadable svn-) version of SpecialUserStats_body.php with the working one from my productive wiki-installation and found the cause of the problem: there are quite a lot of line breaks in the current version that shouldn't be there - after I simply deleted those line breaks and the code in question was in one line again the calendar opens as wished. :-)
There is also a ?> missing at the end of the file, but adding just that makes no difference to the calendars.
Should/could I sent you the working version of the file (and how) or will you take care of it yourself?
--Katwol 09:13, 22 January 2008 (UTC)
You can send me an email with your changes. My contact info is on my user page. --Gri6507 15:35, 10 February 2008 (UTC)
I had this problem, too, with the error message "inputobj not defined". I figured, I had to replace
onClick=\"cal1.select(document.forms[0].start,'anchor1','MM/dd/yyyy'); return false;\"


onClick=\"cal1.select(document.forms[1].start,'anchor1','MM/dd/yyyy'); return false;\"

Same applied to cal2.select. -- --Janboehme 19:45, 22 March 2010 (UTC)

Tranlation to German[edit]


I've tried my hand at a translation to German (even though I had to deactivate the extension on our wiki due to concerns about data privacy):

/** Deutsch (German)
* @author Katharina Wolkwitz
$messages['de'] =array(
  'specialuserstats'           => 'Nutzungs-Statistik',
  'usagestatistics'            => 'Nutzungs-Statistik',
  'usagestatisticsfor'         => '<h2>Nutzungs-Statistik für [[:user:$1|$1]]</h2>',
  'usagestatisticsallusers'    => 'Alle Nutzer',
  'usagestatisticsinterval'    => 'Zeitraum',
  'usagestatisticstype'        => 'Berechnungsart',
  'usagestatisticsstart'       => 'Start-Datum',
  'usagestatisticsend'         => 'End-Datum',
  'usagestatisticssubmit'      => 'Statistik generieren',
  'usagestatisticsnostart'     => '* <font color=red>Start-Datum eingeben</font>',
  'usagestatisticsnoend'       => '* <font color=red>End-Datum eingeben</font>',
  'usagestatisticsbadstartend' => '<b>Unpassendes/fehlerhaftes <i>Start-Datum</i> oder <i>End-Datum</i> !</b>',

--Katwol 14:29, 18 January 2008 (UTC)

Some corretions added - now it should be usable directly from this page. --Katwol 08:36, 22 January 2008 (UTC)
Thank you. I have added the German translations into the i18n file. --Gri6507 15:50, 10 February 2008 (UTC)

Making the Usage Statistics anonymous[edit]


as I said in my earlier post, I cannot use this extion in our wiki anymore, because of concerns about data privacy.

The problem is, that this wiki is used in a workplace-environment and it is not wanted/legally allowed to be able to monitor what any single member of staff is doing. By showing the list of data for all users this extension is doing exactly that.

If there were a possibility to make the list anonymous or suppress it (or at least the data for users who are not the logged-in-user), I would ceartainly like to use this extension again.


--Katwol 14:38, 18 January 2008 (UTC)

I think that this feature already exists. The complete listing for the entire wiki are only available for the users with DELETE priviledges (typically only the sysops have that). If you try to view the same page when logged in as a regular user, the only thing you'll see are your own statistics and no one else's. --Gri6507 16:45, 21 January 2008 (UTC)
You're right, of course - I guess I have to learn to try out new features with another user with less privileges than my own. ;-)
--Katwol 07:57, 22 January 2008 (UTC)

Translation of selectable parameters[edit]


after adding my own German translation to SpecialUserStats.i18n.php I noticed that there are a few places/words that should be translated/translatable as well:

  • the selectable parameters for intervall (e.g. Day, Week, Month)
  • the selectable parameters for type (e.g. Cumulative, Incremental)
  • the linktext for activating the calendar (e.g. select)

--Katwol 08:42, 22 January 2008 (UTC)

Thank you. I have updated the extension. The new version 1.3 which is already in SVN has the necessary changes. Of course, you will have to provide additional i18n content in order for these changes to work. --Gri6507 15:51, 10 February 2008 (UTC)

Issues with 1.12alpha[edit]

I just installed the extension on betawiki: per installation instructions to get more of a sense of what all the messages are used for so I can add translation hints. I ran into a few issues:

  • calendar selector does not work. Firebug is giving me the following errors, immediately on load of Special:SpecialUserStats:
    • CalendarPopup is not defined (twice)
    • getCalendarStyles is not defined
    • unterminated string literal

Clicking on the first or second calendar selector gives the following error:

  • cal1 (or cal2) has no properties

If I manually enter a date range, like "01/01/2008" and "31/01/2008" I have to wait a while before getting an empty page returned. My php error log shows PHP Fatal error: Maximum execution time of 10 seconds exceeded and a lot of entries (about 44.000) similar to the following:

[17-Feb-2008 11:41:57] PHP Notice: Undefined index: 67206 in /var/www/w/extensions/UsageStatistics/SpecialUserStats_body.php on line 88

Is this me installing the thing incorrectly or is something wrong? I have disabled the extension for now... Siebrand 11:50, 17 February 2008 (UTC)

What is the contents of your wiki? How big is it in terms of pages? The undefined index 67206 error and the timeout of 10 seconds errors only make sense if the SQL query to iterate through every page is either failing or is running so slowly that the server times out. On line 76 of SpecialUserStats_body.php is the creation of the $sql string. Can you print that out before running the query? Then, try to run that query directly in MySQL and see what you get.
As for the calendar issues, I'm not too sure what's going on there. --Gri6507 14:15, 17 February 2008 (UTC)
betawiki:Special:Statistics tells me the wiki has more than 163k pages. That is medium sized, I guess. The query SELECT rev_user_text,rev_timestamp,page_id FROM `bw_page`,`bw_revision` WHERE rev_page=page_id executes in 0.88 seconds and returns 215908 rows.
Sidenote: PHP Strict Standards: Non-static method SpecialUserStats::loadMessages() cannot be called statically in /var/www/w/includes/Hooks.php on line 113
Siebrand 15:06, 17 February 2008 (UTC)
163k pages may still be the problem. Once the query is executed, the extension iterates through every row and counts the pages by date. Can you perhaps add a print statement for the timestamp in the loop? It may be a good idea to only print once every, say, 1000 rows of data. If the loop takes too long then that's the cause of the problem. --Gri6507 16:39, 17 February 2008 (UTC)
OK, I have results now. I disabled error logging and set 'max_execution_time' to 70s. I had the for loop output $j every 1000 iterations. Between 216000 and 217000 were done. It took between 50 and 70 seconds to get the output. I guess I'll not install this :) Thanks for the help. Siebrand 10:08, 18 February 2008 (UTC)
If you can think of a faster way to generate these statistics while still allowing for the granularity of a daily time interval, I would be very happy to implement that. Of course adding a new table with pre-generated statistics would be nice, but I just don't know how to structure it to allow the flexibility that this extension currently provides. --Gri6507 15:17, 18 February 2008 (UTC)
Nope, sorry, cannot help there. IANP... (I Am No Programmer). The out I did get this one time did look nice. So for me it's a candidate for installation if a method is found to speed this monster up :) Cheers! Siebrand 23:23, 18 February 2008 (UTC)


With the current limitations and issues at hand, do you mind if we mark this extensin as "beta" or "alpha" instead of "stable"? Huji 21:44, 20 February 2008 (UTC)

Which limitations are you referring to? --Gri6507 01:03, 21 February 2008 (UTC)

Copyright violation[edit]

It seems like this extension violates copyright: The file SpecialUserStats_body.php contains a javascript library by Matt Kruse, which clearly states in its license terms:

// You may *NOT* re-distribute this code in any way except through its
// use. That means, you can include it in your product, or your web
// site, or any other form where the code is actually being used. You
// may not put the plain javascript up on your site for download or
// include it in your javascript libraries for download.

The file is however linked from SVN: http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/UsageStatistics/SpecialUserStats_body.php . If I understand this issue correctly, making the file available that way is not legal. I also think that these license terms are incompatible with the GPL. So the javascript should either be removed ASAP, or maybe the author can be convinced to license the files under a free, GPL compatible license. Comments, suggestions? --Tbleher 09:32, 5 March 2008 (UTC)

This point has been brought up before. That is why I contacted the original author of the code because I thought there was some discrepancy between the license of his code on his website and the header of the code itself. This is his reply:

You can use this new disclaimer, which I now include with all my new

 * Copyright (c) 2008 Matt Kruse (javascripttoolbox.com)
 * Dual licensed under the MIT and GPL licenses.

Hope that helps!


> -----Original Message-----
> From: Paul Grinberg [mailto:gri6507 TA yahoo TOD com]
> Sent: Thursday, January 10, 2008 7:03 AM
> To: matt TA mattkruse TOD com
> Cc: huji.huji TA gmail TOD com
> Subject: License for Javascript Calendar code
> Hello Matt,
> A while ago I was looking for a javascript calendar routine and I
> stumbled across yours. Ever since then, it's been used (with full
> credit given you you, of course) in a MediaWiki extension
> http://www.mediawiki.org/wiki/Extension:Usage_Statistics. The problem
> is that recently, there has been some concern that your license (see
> below) does not explicitly state that it is a GPL or an equivallent
> copy-left license as is apparently required for MediaWiki. I was
> wondering if you could amend the license on this piece of software.
> Many thanks in advance,
> Paul Grinberg (author of the MediaWiki Extension using your code)
> P.S. Here is the license under which your code was released:
> //
> // Author: Matt Kruse <matt@mattkruse.com>
> // WWW: http://www.mattkruse.com/
> //
> // NOTICE: You may use this code for any purpose, commercial or
> // private, without any further permission from the author. You may
> // remove this notice from your final code if you wish, however it is
> // appreciated by the author if at least my web site address is kept.
> //
> // You may *NOT* re-distribute this code in any way except through
> // use. That means, you can include it in your product, or your web
> // site, or any other form where the code is actually being used. You
> // may not put the plain javascript up on your site for download or
> // include it in your javascript libraries for download.
> // If you wish to share this code with others, please just point them
> // to the URL instead.
> // Please DO NOT link directly to my .js files from your site. Copy
> // the files to your server and use them there. Thank you.
> //
I forwarded this information to the original MW user who brought it to my attention, but I guess I forgot to update the extension code itself. Thank you for pointing that out. I will be doing so next. --Gri6507 13:14, 5 March 2008 (UTC)
Very cool! Thanks for your quick reply and for contacting the author! --Tbleher 13:37, 5 March 2008 (UTC)

broken html/table formatting[edit]

On http://cy.uncyclopedia.org.uk/wiki/Arbennig:SpecialUserStats if the 'viewsystemstats' privilege is enabled for all, the extension seems to break the HTML formatting of the rest of the page - as if a table or div somewhere were being opened but not closed properly.

It looks like you may not have followed all of the instructions. You need to make sure to install a copy of MediaWiki:Common.js and MediaWiki:Common.css in your wiki. You can get those from Wikipedia. --Gri6507 17:49, 7 March 2008 (UTC)
Um, no... The problem with the un-closed </div> tags is caused by using AddWikiText() instead of AddHtml() to add the closing tags. The patch to fix this is:
<         $wgOut->AddWikiText("<pre>$csv$csv_edits</pre></div></div><br />");
>         $wgOut->AddHtml("<pre>$csv$csv_edits</pre></div></div><br />");
<         $wgOut->AddWikiText("<pre>$csv$csv_pages</pre></div></div>");
>         $wgOut->AddHtml("<pre>$csv$csv_pages</pre></div></div>");

The javascript calendar (at least under Firefox3beta3) abruptly closes as soon as one attempts to choose some other month from the pulldown lists - this control only works properly to pick dates in the current month.

I just tested this extension in Firefox3 and no issues. Are you using FF3 under Windows or Linux? --Gri6507 17:49, 7 March 2008 (UTC)
I tried a WinNT2000 computer to see if this is browser-dependent: indeed it appears to be so. Firefox3/Windoze closes the calendar box as soon as an attempt is made to pick another month from the pulldown boxes but that "e" browser which came with the compooper seems to handle this particular bit of javascript correctly.
I have just tried this with Firefox 3.6 on Windows XP and the issue still exists. As soon as I try to change the year, month, or click a date, the calendar will close. The only thing that is working is the "Today" link at the bottom.--Dafallus 16:02, 5 February 2010 (UTC)

And yes, the code is too abysmally slow to be usable on any but the smallest of wikis. The status of this extension does need to be changed back to 'experimental' until some of these issues are resolved. -- 07:00, 7 March 2008 (UTC)

The code is slow, but that does not mean it the extension is in the "experimental stage". The extension does exactly what it needs to do and quite well. The problem is that in its current implementation is may not be applicable to larger sites. But that should not be held against this extension any more than installing other extensions that are not application to your wiki. --Gri6507 17:49, 7 March 2008 (UTC)
The `revision` table does have indices on various combinations of page_timestamp, user_timestamp, usertext_timestamp which would make it possible to find all contributions for one user in a given timeframe without having to retrieve the list of every revision to every page in its entirety. Use them, please. -- 19:06, 7 March 2008 (UTC)

Error in code SpecialUserStats_body.php[edit]

Have I downloaded old code Revision 33778: /trunk/extensions/UsageStatistics?

I does not make sense below. It should be <= 7 not 12 because we are talking about days not monthes.

       $daynames = '';
        for($i = 1; $i <= 12; $i++)
            $daynames .= "'" . $wgContLang->getWeekdayName($i) . "',";
        for($i = 1; $i <= 12; $i++)
            $daynames .= "'" . $wgContLang->getWeekdayAbbreviation($i) . "',";
        $daynames = substr($daynames, 0, -1);
You are absolutely correct. This was a copy and paste error. I have updated the code in SVN to reflect this.

Variables not Initialized[edit]

In the SpecialUserStats_body.php I assume the variable e, p, edits and pages should be initialized outside the loops just incase no pages or edits have been performed.

I add the initialization to line 118,119 amd 167,168. My WikiSysop had no edits for the month of July and the gnuplot file was showings dates with nothing after it. There should be zeros after the dates.

set terminal png
set size 0.5,0.5

set output 'D:\InetPub\wwwroot\wiki/images/gnuplot/a7e9f5f45be1246bfd6743f0e2764a42.png'

set xdata time
set xtics rotate by 90
set timefmt "%m/%d/%Y"
set format x "%D"
set grid x y2
set title 'cumulative usage statistics'
set ylabel 'edits'
set y2label 'pages'
set y2tics
set key left top
plot '-' using 1:2 t 'edits' with linesp lt 1 lw 3, '-' using 1:2 t 'pages'  with linesp lt 2 lw 3 axis x1y2

plot '-' using 1:2 t 'edits' with linesp lt 1 lw 3, '-' using 1:2 t 'pages'  with linesp lt 2 lw 3 axis x1y2
        $gnuplot_pdata = '';
        $first = true;
        $e = 0;
        $p = 0;
        foreach ($u[$user] as $d => $v) {
plot '-' using 1:2 t 'edits' with linesp lt 1 lw 3, '-' using 1:2 t 'pages'  with linesp lt 2 lw 3 axis x1y2
        $gnuplot_pdata = '';
        $first = true;
        $pages = 0;
        $edits = 0;

--Wolcott 15:56, 28 July 2008 (UTC)

Sorry for the long delay, but I have finally incorporated your bug fix into the main line code. It is available in v 1.9. Thank you for this correction. --Gri6507 12:53, 21 August 2008 (UTC)

New pages statistic[edit]


Another interesting statistic is how many pages a person has created over a time period. We would use this statistic to determine how well our wiki is being used. We would like to know how many people are participating in the creation of pages (not just editing existing pages). If it is low, then we need to do a better job of training our people. It would be nice if this extension provided this information (at a minimum via the CSV file would be great). Thanks. --Vtgrog 14:26, 11 August 2008 (UTC)

Isn't that what the pages graph supposed to be showing? --Gri6507 12:41, 21 August 2008 (UTC)
No, it is not! What he means is how many new pages have been created by a user over a period of time (pages which did not exist before). I think this information would be very useful, since we are facing the same problem with our wiki.
I would spend my 2¢ for this feature. I propose that, instead of the number of pages edited, the graph (and the raw data) display the number of pages a user created. Or, perhaps better, a third series of data with this value is shown. DonPaolo 22:20, 19 December 2009 (UTC)

No such special page[edit]

I'm getting this message when trying to access Special:SpecialUserStats

No such special page

You have requested an invalid special page. 

A list of valid special pages can be found at Special:Specialpages.

The funny thing is that Usage statistics is listed at Special:Specialpages, and following that link gives me the above message.

I'm using MediaWiki 1.11.1 --CrazyTerabyte 16:48, 13 August 2008 (UTC)

It is worth noting that the default language of my wiki is not english, but portuguese. --CrazyTerabyte 20:32, 26 August 2008 (UTC)
See similar topic below for info Wolcott 17:39, 4 September 2008 (UTC)
I've just updated to 1.13.1, and I don't experience this bug anymore. --CrazyTerabyte 23:34, 15 September 2008 (UTC)

Undefined offset in SpecialUserStats_body.php line 217[edit]

This error gets thrown in MediaWiki 1.13 when doing monthly, cumulative statistics as wikisysop:

[Fri Aug 15 22:01:00 2008] [error] [client nn.nn.nn.nn]
PHP Notice:  Undefined offset:  11187 in
<path>\\UsageStatistics\\SpecialUserStats_body.php on line 217,
referer: http://server/wiki/Special:SpecialUserStats

The line is:

$totals[$pageid] += $numedits;
Was this wiki by any means modified on the database level? That's the only reason I can imagine this type of an error occurring. You may want to modify the code to dump out the contents of the entire $totals array and email it to me so I could take a look. --Gri6507 12:49, 21 August 2008 (UTC)

Another weird thing is that the CSV data for all users does not get displayed. This is with version 1.8 of the extension. You get the 2 graphs and the line "Individual user cumulative edits statistics". However, the CSV data is being generated in the HTML source, but inside a div with style="display:none". Is this accidental or by design?

--Maiden taiwan 02:07, 16 August 2008 (UTC)

Are you sure you followed all of the instruction steps? In particular, I'm talking about Step 4. --Gri6507 12:49, 21 August 2008 (UTC)

Hi, with debug mode enabled and MW 1.13 I receive the following messages after generating the graphs, for different interval-type combinations:

Notice: Undefined index: 3 in .../mediawiki-1.13.0/extensions/UsageStatistics/SpecialUserStats_body.php on line 96
Notice: Undefined index: 4 in .../mediawiki-1.13.0/extensions/UsageStatistics/SpecialUserStats_body.php on line 96
Notice: Undefined index: 4 in .../mediawiki-1.13.0/extensions/UsageStatistics/SpecialUserStats_body.php on line 96
Notice: Undefined offset: 9 in .../mediawiki-1.13.0/extensions/UsageStatistics/SpecialUserStats_body.php on line 184
Notice: Undefined offset: 13 in .../mediawiki-1.13.0/extensions/UsageStatistics/SpecialUserStats_body.php on line 184
Notice: Undefined offset: 14 in .../mediawiki-1.13.0/extensions/UsageStatistics/SpecialUserStats_body.php on line 184
Notice: Undefined offset: 8 in .../mediawiki-1.13.0/extensions/UsageStatistics/SpecialUserStats_body.php on line 221
Notice: Undefined offset: 12 in .../mediawiki-1.13.0/extensions/UsageStatistics/SpecialUserStats_body.php on line 221
Notice: Undefined offset: 17 in .../mediawiki-1.13.0/extensions/UsageStatistics/SpecialUserStats_body.php on line 221

I didn't change the database and Extension:Usage Statistics is running without problems. If I can help you in any way, please let me know. --KMax 01:22, 6 September 2008 (UTC)

This is fixed in v1.10 --Gri6507 21:23, 2 October 2008 (UTC)

No such special page[edit]

I am using mediawiki 1.12 and I have successfully installed the extension. But it is giving "You have requested an invalid special page.A list of valid special pages can be found at Special:Specialpages."

The Usage Statistics is shown in the Special pages.

Kindly help me out.

I can't run it either. I followed the installation steps. The Gnuplot extension is working. A link is automatically produced in the Special Pages page. When I click it, however, I am asked to supply the content. I have no clue what is going wrong.

Apache's error log does not give a clue either. The Apache error file is clean. The access file looks okay to. I can also get input from an echo if I place it in the SpecialUserStats.php, so it calls it somehow.

Any help?

I have not seen this type of problem. Let me set up MW 1.12 on my setup first and I'll try to reproduce this issue --Gri6507 12:37, 26 August 2008 (UTC)
I am using 1.11 and I also have this problem. Take a look at #No such special page (which I've created some days/weeks before another user added another section with the same name). By the way, feel free to merge these two duplicate sections whenever you want. (I've also deleted the apache log, since I don't think it helps; anyway, it is available at this talk page history) --CrazyTerabyte 20:37, 26 August 2008 (UTC)

I to have this same issue. We are running 1.12 Mediawiki. i downloaded and installed the very latest even and still cant get this to work. i to get the "You have requested an invalid special page.A list of valid special pages can be found at Special:Specialpages.". i have installed many other extensions with out any issues. this would be an awesome page to have for us.

We're also running into this issue, gnu is running correctly and all files have been set up correctly. However, the error "You have requested an invalid special page.A list of valid special pages can be found at Special:Specialpages." appears when the link is clicked from the list of special pages...

I also get this problem on 1.11.2. The Gnuplot plugin is working fine.-- 19:28, 3 September 2008 (UTC)

I am having the same issue in using the extension V1.9 in MW 1.12. The issue is in SpecialUserStats.php. Why did you change the last line from
Version 1.7
$wgSpecialPages['SpecialUserStats'] = 'SpecialUserStats';
Version 1.9
$wgSpecialPages['UserStats'] = 'SpecialUserStats';

Wolcott 16:56, 4 September 2008 (UTC)

This has been resolved in v1.11.1. --Gri6507 21:39, 3 October 2008 (UTC)

broken html/table formatting (Still)[edit]

Like the user mentioned above I am having formatting issues. Once I change two AddWikiText to AddHtml everythin looks great.

In Version 1.9 I change Line 243 and 249 to addHtml

<         $wgOut->AddWikiText("<pre>$csv$csv_edits</pre></div></div><br>");
>         $wgOut->addHtml("<pre>$csv$csv_edits</pre></div></div><br>");
<         $wgOut->AddWikiText("<pre>$csv$csv_pages</pre></div></div>");
>         $wgOut->addHtml("<pre>$csv$csv_pages</pre></div></div>");

Wolcott 17:03, 4 September 2008 (UTC)

Hi, I'm using MW 1.13 and run into the same broken html. Here are two figures whitch show how it looks with and without the changed lines.

Usage stat right.png
Usage stat wrong.png

, KMax 00:56, 6 September 2008 (UTC)

This is fixed in v1.10 --Gri6507 21:21, 2 October 2008 (UTC)

Arrays not initialized[edit]

Here is one more set of initialization issues

<                    if (!isset($u[$row[0]][$d])) $u[$row[0]][$d] = array();
<                    if (!isset($u[$row[0]][$d][$row[2]])) $u[$row[0]][$d][$row[2]] = 0;
<                    $u[$row[0]][$d][$row[2]]++;
>                     $u[$row[0]][$d][$row[2]]++;
<                    foreach ($u[$usr][$d] as $pageid => $numedits) {
<                       if (!isset($totals[$pageid])) $totals[$pageid] = 0;
<                       $totals[$pageid] += $numedits;
<                       }
>                     foreach ($u[$usr][$d] as $pageid => $numedits)
>                       $totals[$pageid] += $numedits;
<                     foreach ($u[$usr][$d] as $pageid => $numedits) {
<                        if (!isset($totals[$pageid])) $totals[$pageid] = 0;
<                        $totals[$pageid] += $numedits;
<                        }
>                     foreach ($u[$usr][$d] as $pageid => $numedits)
>                        $totals[$pageid] += $numedits;

Wolcott 17:37, 4 September 2008 (UTC)

Thanks, I've incorporated this is fixed in v1.10 --Gri6507 21:22, 2 October 2008 (UTC)

Untitled Issue[edit]

I have posted earlier about the display of no such "I to have this same issue. We are running 1.12 Mediawiki. i downloaded and installed the very latest even and still cant get this to work. i to get the "You have requested an invalid special page.A list of valid special pages can be found at Special:Specialpages.". i have installed many other extensions with out any issues. this would be an awesome page to have for us." i have found the problem in the specialuserstates page......change the following...

Version 1.7
$wgSpecialPages['SpecialUserStats'] = 'SpecialUserStats';
Version 1.9
$wgSpecialPages['UserStats'] = 'SpecialUserStats';

I now have a new problem....it wont let me select a date range so i put one in manually and it tells me wrong/bad start and end date.

This has been resolved in v1.11.1. --Gri6507 21:38, 3 October 2008 (UTC)

Errors when no data to be displayed[edit]

This extensions throws some errors in two conditions:

--CrazyTerabyte 00:22, 16 September 2008 (UTC)

I believe both of these issues have been addressed in the latest release (v1.10) --Gri6507 13:55, 2 October 2008 (UTC)

A humble feature request[edit]

Hi and thanks for such an awesome and well developed extension!

I have but one feature request: a tag which would enable calling the extension within syntax and inserting the generated image to any page. The tag could have simple parameters for start/end date and an optional parameter for showing user specific stats or global stats. Also an option in the sources to localize date output to another than mm/dd/yyyy :-) --Piksi 21:45, 4 January 2009 (UTC)

Both of these are excellent ideas. I will take a look at implementing them sometime this week and will post here with results. --Gri6507 13:45, 5 January 2009 (UTC)

Thank you![edit]

Thank you for this very nice extension!


Fatal error: Maximum execution time of 30 seconds exceeded[edit]

I can never get this extension to work.

Fatal error: Maximum execution time of 30 seconds exceeded
in ...../extensions/UsageStatistics/SpecialUserStats_body.php on line 165

This is v1.11.5 running on MediaWiki 1.15.1. Our wiki has 28,000 pages and 200,000 edits. I tried getting daily statistics for 2 days, and monthly statistics for 1 year. Both produced this error. Maiden taiwan 21:07, 14 July 2009 (UTC)

Have you try adding a LIMIT to the sql query?

In SpecialUserStats_body.php:


$sql = "SELECT rev_user_text,rev_timestamp,page_id FROM " .
$db->tableName( 'page' ) . "," . $db->tableName( 'revision' ) .
" WHERE rev_page=page_id";

change to

$sql = "SELECT rev_user_text,rev_timestamp,page_id FROM " .
$db->tableName( 'page' ) . "," . $db->tableName( 'revision' ) .
" WHERE rev_page=page_id" .
" LIMIT 5000";
This of course will limit the extension, you should test to find out what limit is affordable. See also: Debugging. --almaghi 22:37, 14 July 2009 (UTC)

PHP 5.3 related error[edit]

The top of the page is printed following notices:

Deprecated: Function split() is deprecated in /var/www/wiki/extensions/UsageStatistics/SpecialUserStats_body.php on line 134
Deprecated: Function split() is deprecated in /var/www/wiki/extensions/UsageStatistics/SpecialUserStats_body.php on line 136

--Mrl586 04:11, 15 July 2009 (UTC)


I am looking for an extension that will give me a bit more page-level statistics. Something like Google's Analytics. Does something exist like this?

p.s. sorry if this is in the wrong place. please don't bite --Boy.pockets 14:24, 21 August 2009 (UTC)

Can I limit this to specific Categories?[edit]

I'd like to track my wiki's growth more granularly across a group of pages. Is this possible? --Torley 21:39, 22 September 2009 (UTC)

Disable single user statistics?[edit]

In our concern it's not allowed to collect statistic material about a single person. Is there a possibility to deactivate this part and use only the statistics about "all users"?

Wrong Call Function in require_once: SpecialUserStats.php doesn't exist![edit]

Hi all,

I'd like to advise you that the lastest trunk doesn't have a SpecialUserStats.php as required in statement

require_once( "$IP/extensions/UsageStatistics/SpecialUserStats.php" );

The functional call needs to read:

require_once( "$IP/extensions/UsageStatistics/UsageStatistics.php" );

Thanks and keep up the dedecated work!

--Stoettner 20:29, 29 June 2010 (UTC)

Any way to check individual statistics for other users?[edit]

Hi all,

the title says it all: i'm admin of my wiki and would like to be able to generate similar stats for users i chose. Is there an easy way to do that or should i rewrite part of the extension?

Thanks! --Augustin, 11 Oct. 2010

Augustin, have you figured it out? I would like to know as well. --A. M., March31/2011

Add in Views to graph?[edit]

Very nice extension! Would it be possible to add a third graph line, showing page views? The existing graphs show edits & new pages- it would be nice to also track the lurkers who are using the wiki, yet not editing.

Thanks! - mitch at mitch ross dot com

bad formatting[edit]

i have installed the extension without problems, but when i try to populate some statistics it gets to small to see the data ( pic here).

Can anyone tell me how i can correct this?

Hi, I had the same error, I solved it by editing the Gnuplot.php in $IP/extensions/Gnuplot/ . I changed the gwGnuplot DefaultSize to 'set size 1.8,1' what looks nice in my opinion.

Still active? Available?[edit]

The download link leads to nothing. Is this module still available and functional? I need something that can graph usage statistics of Mediawiki.--Pashdown (talk) 18:36, 9 July 2012 (UTC)

you can download it from here, --Erkan Yilmaz (talk) 16:31, 10 July 2014 (UTC)
So err... any reason you're not fixing the link on the page? (or fixing the download system?) -- Harry Wood (talk) 11:30, 12 October 2014 (UTC)
Hi, the download link on the extension page (still) doesn't work and the above alternative doesn't either (they both redirect to https://phabricator.wikimedia.org/diffusion/). Also, as that the GNUPlot extension appears to have been removed on security grounds does this extension no longer need that one, or is it now limited to using Google Charts only? Lawpjc (talk) 09:47, 10 August 2015 (UTC)

Is this extension still supported?[edit]

Is this extension supported in wikimedia 1.21.1? The download link is broken.

Is there any other extension to display usage statistic in graphs\charts? from IP on 09:49, 4 November 2013

see above reply, --Erkan Yilmaz (talk) 16:31, 10 July 2014 (UTC)