Extension talk:Usage Statistics

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)