1 spiceygas2 Jul 11, 2010 17:30
3 sam2kb Jul 11, 2010 20:54
Since the database wipes the hitlog on a rolling 15-day cycle
You can change this number on Global settings > Features tab ;)
4 spiceygas2 Jul 11, 2010 21:08
sam2kb wrote:
Since the database wipes the hitlog on a rolling 15-day cycle
You can change this number on Global settings > Features tab ;)
Still wouldn't give the flexibility that's available in excel.
(But yes, I did figure that out)
5 spiceygas2 Jul 17, 2010 15:58
I made a few updates. The excel export now supports referrers and searches. This is probably about as far as I plan to go for now.
The code above is updated. Here are some examples of the graphs you can put together pretty quickly in excel using this extract. These are all pivot charts in excel, so you can quickly tweak filters & sort options, along with creating new charts & tables.
http://cookingwithdoyle.com/media/blogs/plugins/v1_0/01.png
http://cookingwithdoyle.com/media/blogs/plugins/v1_0/02.png
http://cookingwithdoyle.com/media/blogs/plugins/v1_0/03.png
http://cookingwithdoyle.com/media/blogs/plugins/v1_0/04.png
http://cookingwithdoyle.com/media/blogs/plugins/v1_0/05.png
http://cookingwithdoyle.com/media/blogs/plugins/v1_0/06.png
http://cookingwithdoyle.com/media/blogs/plugins/v1_0/07.png
http://cookingwithdoyle.com/media/blogs/plugins/v1_0/08.png
6 tilqicom Jul 17, 2010 19:18
looks great :D
7 spiceygas2 Jul 20, 2010 13:55
I made a few updates to the code above:
1. Identifies google chrome browser.
2. Identifies android OS.
3. Identifies iceweasel browser.
4. Records a couple flavours of linux (certainly not all of them. This will need some improvement in the future).
Also, I had to remove all my data from the excel file linked above because search engines are parsing it and fubar'ing the keywords for my website :( . So now you get a blank spreadsheet with no data and will need to run it yourself to get a sample. (I also blocked the directory in robots.txt)
8 spiceygas2 Sep 06, 2010 19:01
Updated the code in the first post with a couple bug fixes, as well as ability to identify SUSE Linux.
9 achillis Sep 15, 2010 04:46
Is it just me or does b2evo 4.0.0-alpha miss user-agent extension in the stats section?
8|
10 sam2kb Sep 15, 2010 05:05
True.
User agent table was dropped to increase b2evo performance.
11 achillis Sep 15, 2010 05:27
This means that spiceygas2's Stats.php data collection is not going to work, needs some moderation!?
Volunteers?
12 spiceygas2 Sep 15, 2010 13:48
Where did the data get moved that was in the evo_useragent table? Assuming it's still relatively accessible, I can update the code.
I don't have a 4.0.0 alpha server accessible, so I'd need something to test against. I don't have the interest yet in upgrading my website, but would be willing to update the code I wrote.
13 achillis Sep 15, 2010 16:45
The evo_useragent table table is completely removed in b2evo 4.0.0-alpha. This means that you have to reconfigure stats.php to exclude that data collection from the database.
It appears to present the following errors when applying your Stats plug-in hack:
[u]First Area[/u]
Table 'kazaaikc_pj1.evo_useragents' doesn't exist
This error can be found here....
Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /home/somefolder/public_html/stats.php on line 328
mysql_select_db($dbName, $con);
// Loop over agent table and build local array
$result = mysql_query("SELECT * FROM evo_useragents");
while ($row = mysql_fetch_array($result))
{ $agents[$row['agnt_ID']]=$row['agnt_signature'];
$agentTypes[$row['agnt_ID']]=$row['agnt_type'];
}
***
[u]The second [/u]
Error report Unknown column 'ID' in 'where clause'
This error can be found here....
Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /home/somefolder/public_html/stats.php on line 354
startHTML();
while($row = mysql_fetch_array($result))
{ if (includeURI($row['hit_uri']))
{ $data['ID']=$row['hit_ID'];
$data['uri']=$row['hit_uri'];
$data['remote_addr']=$row['hit_remote_addr'];
$data['date']=substr($row['hit_datetime'],0,10);
$data['year']=substr($row['hit_datetime'],0,4);
$data['month']=substr($row['hit_datetime'],5,2);
$data['month_abbr']=getMonthAbbr($data['month']);
$data['time']=substr($row['hit_datetime'],11);
$data['agentType']=$agentTypes[$row['hit_agnt_ID']];
if ($data['agentType'] == 'browser')
{
$info = getBrowserInfo($agents[$row['hit_agnt_ID']]);
$data['browser']=$info['browser'];
$data['version']=$info['version'];
$data['os']=$info['os'];
$data['os-flavor']=$info['os-flavor'];
}
***
You need to change those two fields in order for it to work on 4.0
You will also have to amend your stats.xmls for a 4.0 version to exclude that data collection and projection.
Your code is a hectic move, but a brilliant feature, well done!
It is a excellent tool to have thanks for sharing your work.
B)
14 spiceygas2 Sep 16, 2010 05:04
wow. It's gone entirely in 4.0.0? Thats... stupid. Can't imagine why we'd sacrifice raw data, especially since that single string holds so much information. I'm probably never going to upgrade my production website if 4.0 is missing this information.
But I would like to try and fix the PHP code for the rest of you. I guess I'll need to dust off my old linux box and get 4.0.0 running to see what the database looks like and how tough it'll be to fix this.
Work's busy right now, so it'll be a couple days before I can take a look at it.
15 achillis Sep 16, 2010 22:52
Thanks.
16 bushleaguecritic Sep 17, 2010 16:25
sam2kb wrote:
True.
User agent table was dropped to increase b2evo performance.
I understand the reasoning behind removing the useragent table. The db lookup to determine whether the user agent string was unique before writing the string to the table (and the id of that unique string to the hitlog table) was always a little redundant and unnecessary.
Unfortunately, the performance you gained (on the front end) by eliminating that db lookup is cancelled by the slowness of the php code that has to determine whether the useragent was a (browser, robot, xml, other) before that hit can be logged in the hitlog table. At best a tradeoff, maybe even a step backward for those not using opcode caching.
Basically, you've thrown the baby out with the bathwater.
A better solution would have been to have the hit-logging routines simply throw the useragent string (with no unnessesary lookup) into the hitlog table with the rest of the info, and have the backoffice statistics code determine what kind of useragent it represents. Nobody cares if the backoffice stats page takes an extra second or two to display.
The decision to remove the user agent string from the log data entirely, was a poor one. Boo! ;)
17 sam2kb Sep 17, 2010 16:58
I agree with you. That's the reason why I'm still running 3.3.3 on websites where I need detailed stats.
18 bushleaguecritic Sep 17, 2010 18:02
I hope it didn't seem like I was blaming you personally. The "you" in my post was more of a generic "whoever was ultimately responsible for this decision" kind of "you". ;)
19 sam2kb Sep 17, 2010 18:10
I didn't take it personally :)
20 spiceygas2 Sep 19, 2010 00:54
In this case, performance is a really stupid reason. As you pointed out, if the lookup was really that bad then you'd just move the agent string to the hitlog itself and avoid the extra table lookup. Sure, it'll take more space but most people purge the database every 14 days so the extra space is a moot point.
(actually, now that I've said that, maybe someone should hack up the code in v4.0.0 to add an additional column to the hitlog table and log the agent string. Shouldn't be too tough...)
Or you could just do the sensible thing and index the agent strings. Yep, there's a lot of them and the index will take disk space, but isn't computer science filled with space v. time tradeoffs.
Seems like two possible solutions, either of which would have been better then throwing away vital data.
21 sam2kb Sep 19, 2010 01:17
Why don't you want to make a plugin out of this hack and log any stats you need to a separate plugin's table?
22 spiceygas2 Sep 19, 2010 22:01
sam2kb wrote:
Why don't you want to make a plugin out of this hack and log any stats you need to a separate plugin's table?
That's a decent suggestion. I just installed a bunch of junk and am looking at the framework for writing a plugin. If I can figure it out then I'll do v 3.3.3 first since it's simpler and doesn't require modifying any db tables.
Fingers crossed.
23 spiceygas2 Sep 20, 2010 12:38
Last night I got a basic plugin running on v3.3.3 and extracting the data via the back office. I need a bit more time to do some testing and make sure it is working correctly, and this week is pretty busy at work so it might take a few more days. (If only every day was a weekend)
Once I get it done I'll post it here and then set to work on a plugin for v4.0.0.
I actually didn't realize anyone was even using this hack until someone pointed out that it doesn't work on v4.0.0. I'm glad others are getting some value from the idea.
24 spiceygas2 Sep 25, 2010 15:36
Got v1.0 of the plugin running. This thread is now deprecated.
Plugin is at http://forums.b2evolution.net/viewtopic.php?t=21519
spiceygas2 wrote:
How this forum works wrote:
Guess I'm crap at writing instructions :( .. moving this to plugins and hacks for you ;)
ref @link [url=http://forums.b2evolution.net/viewtopic.php?t=17969]sticky[/url] ;)
¥