Extension talk:Usage Statistics

Invalid Argument
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


 * 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)

Translation
Here is the french version of messages:

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)

Warning
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/ /extensions/SpecialUserStats.php:19) in /var/www/ /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. --86.134.183.173 12:47, 3 November 2007 (UTC)

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

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

A better fix
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
Hi,

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 0.0.0.0,1,1,1,1,1,1,1,1,1,1,1,1,1,1, Kate,12,4,12,12,12,12,12,12,12,12,12,12,12,12, Kremser,3,1,3,3,3,3,3,3,3,3,3,3,3,3, MediaWiki default,1,1,1,1,1,1,1,1,1,1,1,1,1,1, Roddeck,380,18,380,380,380,380,380,380,380,380,380,380,380,380, Studi,3,3,3,3,3,3,3,3,3,3,3,3,3,3, Weinreich,62,7,61,61,61,61,61,61,61,61,62,62,62,62, WikiSysop,26,10,26,26,26,26,26,26,26,26,26,26,26,26, Wolkwitz,475,44,450,450,450,450,450,450,450,452,456,475,475,475,

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

--193.174.68.13 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:
 * Username - the name of the user for whom the row of data applies
 * 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
 * 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.
 * 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)

SQL-Error
Hi,

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. :-(

--193.174.68.13 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
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 \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  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  to something like , 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
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
Hi,

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 . 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
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)

Tranlation to German
Hi,

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):

--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
Hi,

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.

Thanks!

--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
Hi,

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
I just installed the extension on 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:

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  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)

versionig
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
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:

Hi,

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

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

Hope that helps!

Matt

> -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  > // 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 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. > // 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
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 &lt;/div&gt; tags is caused by using AddWikiText instead of AddHtml to add the closing tags. The patch to fix this is:

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.

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. --66.102.80.212 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. --66.102.80.212 19:06, 7 March 2008 (UTC)

Error in code SpecialUserStats_body.php
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.


 * You are absolutely correct. This was a copy and paste error. I have updated the code in SVN to reflect this.

Variables not Initialized
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 07/01/2008 e 07/01/2008

e

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)

New pages statistic
Hi.

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)