Extension talk:UserSnoop

Suggestion
Saw your quick fix for the UserPageViewTracker and it worked for UserSnoop too (Super thanks!!). Do you think you could make it so that you can either search the user list (ajax would be great) or pick users from a drop down list?

Since the UserSnoop does what the UserPageTracker does, are you going to just continue one of them and improve it?

Also you might want to take a look at http://firestats.cc/ your plugin would be great if you could integrate that into a full blown statistics system.

SellFone 07:30, 4 December 2007 (UTC)


 * Thanks! I am thinking about continuing the UserSnoop extension and add more functionality to it going forward. I have considered extending it all the way to a full wiki stats extension but, haven't really had the time to dedicate to it. My paying job takes precedence :) Perhaps over the holidays. --Kimon 18:14, 4 December 2007 (UTC)
 * Great extension, i think you should extend it to a full statistic extension. I would like to request a feature: I would like to see a special page showing all external links of the wiki, with total of clicks of each external link. Will be interesting too, if we have an option to show this information between specifics periods. What do you think? Lleoliveirabr 02:02, 9 December 2007 (UTC)
 * Thanks for your kind words! I'll give it a try --Kimon 02:13, 9 December 2007 (UTC)
 * I think we could have a statistic extension, this could log everything, and real live statistics. like this examples: http://www.getclicky.com/ and http://feedback.phpmyvisites.net/feedbacks/2630-last-n-visitor-details-config-info-path-etc look the comments. Could have an option to search an IP and see all activity of the user or IP user in the wiki.
 * Better: As phpmyvisites statistic program is now http://piwik.org/ i think you could help in development and try to port it to Mediawiki, Add more features and so on.. What do you think?

SQL
I get following error when trying to run UserPageHits.sql (in phpMyAdmin).

for the right syntax to use near 'VIEW `user_page_hits` AS SELECT `u`.`user_name` AS `user_name`, `u`.`' at line 1
 * 1) 1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version

--Mopster 20:00, 5 December 2007 (UTC)


 * Hmmmm.... I just copy & pasted this into my test DB and it worked fine. I'm running on MySQL 5.0.41-community. What version are you running? (Execute "select @@version"). --Kimon 20:26, 5 December 2007 (UTC)

Mediawiki 1.7.1? (Debian stable version)
Can you make this extension work with Mediawiki 1.7.1? That's the Mediawiki version that Debian Etch uses.

I get:

Warning: require_once(/var/lib/mediawiki1.7/includes/Pager.php) [function.require-once]: failed to open stream: No such file or directory in /var/lib/mediawiki1.7/extensions/usersnoop/UserSnoop.php on line 489

The file Pager.php does not seem to exist in Mediawiki version 1.7.1.

Todu 00:17, 6 December 2007 (UTC)


 * Pager.php is a required file for this extension. I don't know when this was introduced to MediaWiki (I'll have to do some research) but, without it, you won't get the pagination of the results. Would it be possible to upgrade to a newer version? --Kimon 01:20, 6 December 2007 (UTC)
 * I need to stay with 1.7.1 for security reasons. My policy is to stay with whatever version is included in the current Debian stable distribution. That way I get a very secure installation with the obvious drawback of not getting the latest features. Is there a possibility for a workaround? I could live with less functionality of your extension if needed. Btw: I'm the same guy commenting on your BreadCrumbs extension implementation. Todu 14:23, 6 December 2007 (UTC)
 * I know :) - sent you an email in response.
 * I'll try to do some research into what is not available in 1.7.1 and what workarounds I can come up with. BTW, is your wiki public? --Kimon 14:30, 6 December 2007 (UTC)
 * [OT] Thanks. I have two wikis. The first is a personal wiki only localhost can access that I use as a form of diary/notepad. The second wiki I use for work. We are four coworkers who often get insults from our boss about us forgetting stuff he has told us. He emails us stuff that we are supposed to remember. But it's so much stuff now that we need to document how we work or we will keep forgetting. One of us asked the others if anyone knew of a system we could use to help us remember. I suggested and demonstrated a wiki and the other three coworkers all wanted one. So I try to install extensions that would make our job even easier. I installed your Breadcrumbs extension because we work with customer support over the phone and need to switch between more or less related documentation as we speak to the customer. It's quite stressful and a breadcrumb function would help us toggle between pages that are related to a particular issue we are having with the current customer we are talking to.


 * As our wiki is new and none of us has ever worked with one (we tried to remember everything without documentation) I figured this extension would help us find differences in how we use the wiki. And that would lead to a discussion about "tricks" one of us uses but the others do not. We could also see if we should reorganize our pages depending on the statistics UserSnoop could provide for us. So what I want from this extension is the function to be able to see who has watched what page, how many times. If there are differences there, then we would know that we work differently. Lets say one of us has very many hits on a page that the others have almost no hits to. Then we could ask the person with many hits what is so useful with that page that he keeps reloading it so often. The built in counter only reports per page hit counts, not per user per page hit counts. Maybe your UserPageViewTracker would be easier to make work with Mediawiki 1.7.1 since it has only that particular function? I haven't tried to install that extension yet. It says it's only been tested with v1.10 Todu 00:01, 9 December 2007 (UTC)
 * Do you run any public wikis? Todu 00:02, 9 December 2007 (UTC)
 * As this is not relevant to the extension, let's continue this on my talk page or in email.
 * Specifically on the implementation of this extension on 1.7.1.... I don't see a good solution without backporting Pager.php
 * What I would suggest to get what you want would be to use UserPageViewTracker without implementing the special page. This way the data will be updated/stored in the db and you could then query the data via whatever db client you want. The alternative is to generate a LONG list with the data. I know there is a QueryPage.php file which may do the same but, it may take a while to figure out what the differences are --Kimon 01:15, 9 December 2007 (UTC)
 * Ok thanks I'll try to do that as soon as our wiki grows a little. Hopefully someone will have made an extension to make this easier by then. We have just started using it. I updated your talk page regarding the OT part of this conversation. Todu 17:26, 9 December 2007 (UTC)

spreadBlock
Probably a bad idea. This just blocks the user who calls it. What you want is something like what Block::doRetroactiveAutoblock does. Werdna 23:20, 9 December 2007 (UTC)


 * Hmmmmm  didn't happen when I was testing....  will have to check it out. But, admittedly, I don't use that button, I just block. Thanks for pointing it out.--Kimon 01:24, 10 December 2007 (UTC)

Slight edit to UserSnoop.php for lazy users !!
I found it a bit of a hassle to always type the user's name exactly as it was registered, mainly with a First letter as capital and the rest as lowercase ...

In my Wiki, its aimed at Radio Amateurs (Hams) who 'usually' use the callsigns as usernames. (e.g ZS6RO, W1AW) .. These get transformed to 'Zs6ro and 'W1aw' .. For the lazy Ham, this a real pain !!

So, in line 146 of UserSnoop.php I changed this line from $this->targetUser = isset($par) ? $par : $wgRequest->getVal( 'username' ); to -- $this->targetUser = isset($par) ? $par : ucfirst(strtolower($wgRequest->getVal( 'username' )));

This solved my problem - A user can type a username in any mixture of lower or/and uppercase ..

I'm assuming this won't cause any 'bugs' to raise their respective heads ??

--Dick 08:01, 8 January 2008 (UTC)


 * Cool! But, I can't see this happening on a wider variety of wikis since usernames are case sensitive on purpose. Great contribution though for those who want to avoid case sensitivity in user names. --Kimon 13:30, 10 January 2008 (UTC)

Database prefix
Hey there,

All of the tables in my database begin with wiki_. When running th SQL queires I've modified the FROM field on the second one to read:

FROM ((`wiki_user` `u` JOIN `wiki_page` `p`) JOIN `user_page_views` `v`)

...I've also tried to create the tables as wiki_user_page_views and wiki_user_page_hits. The initial page (Special:UserSnoop) loads and I can pull up user info such as Username, Real name, E-mail, New talk, etc.

But when I pull up "Page Views" it just refreshes the screen, nothing comes up. When I try to pull up "Watchlist" I get the error:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "IndexPager::reallyDoQuery (UserSnoopPagerWatchlist)". MySQL returned error "1146: Table 'itwiki.page' doesn't exist (localhost)".

When I try to pull up "New Pages" I get:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "IndexPager::reallyDoQuery (UserSnoopPagerWatchlist)". MySQL returned error "1146: Table 'itwiki.page' doesn't exist (localhost)".

What a mess!! Does anyone have any suggestions? It seems like the extension wasn't written to take into consideration database prefixes. Any thoughts? Thanks!!

Acook 18:18, 17 January 2008 (UTC)


 * As a side note, when I create the table wiki_user_page_views, it seems like it's updating rows, where as user_page_views does not get updated. And neither wiki_user_page_hits or user_page_hits is getting updated at all.  Acook 18:20, 17 January 2008 (UTC)