Extension talk:Usage Statistics

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

--Mbeerman 22:51, 14 December 2007 (UTC)


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