[FS#455] SlimStat problems

Have installed SlimStat and am having some problems.

1. SlimStat for some reason stores the Referrer information in its database, but fails to display it on the webpage.

2. Search strings are derived from the referrer urls in the db and somehow are ’reformatted’ i.e.:

http//search.yahoo.com/searchpPoulKjC3A6rholmpk24chairfrFP-tab-web-t405toggle1copeiUTF-8

Note the missing : after http and all the ’gibberish’ after the / which doesn’t resemble a normal search string IMO.

MODx’s stats also does something weird with referrers and am wondering if these issues are related. Here is another yahoo referrer, but now taken from the MODx stats page:

://http//search.yahoo.com/searchppoulkjaerholmsofaeiUTF-8frFP-tab-web-txwrt

Colons and slashes formatting.. weird. Anyone here now why this is and how to resolve the SlimStat problems?

Thanks.

I don’t know but have run into the same issue with slimstats. Anyone have any ideas?

Looking in the etomite [tt]prefix_log_referers[/tt] in the db, the formatting of the referrer URLs is already wrong. So it seems we have an etomite originated problem at hand.

Might file a bug report about this one, unless someone tells me it is intended behavior.

OK, filed a bug report on this problem.

Have a temporary fix for the Slimstat problem. Somehow PHPs header variable [tt]$_SERVER["HTTP_REFERER"][/tt] is not correct, it is missing the colon [tt]:[/tt] after the [tt]http[/tt] in URLs. This has consequences for the following [tt]parse_url()[/tt] function call, that will fail.

The temporary solution is to replace [tt]http//[/tt] with [tt]http://[/tt] in the referer variable. I know it’s a kludge, but I have no clue about fixing a PHP standard variable bug..

In the Slimstat file [tt]inc.stats.php[/tt] after line 59:

[tt]$stat["referer"] = SlimStat::my_esc( ( isset( $_SERVER["HTTP_REFERER"] ) ) ? $_SERVER["HTTP_REFERER"] : "" );[/tt]

Add this replacement call:

[tt]$stat["referer"] = str_replace("http//", "http://", $stat["referer"]);[/tt]

One might also try to change the [tt]$_SERVER["HTTP_REFERER"][/tt] variable directly in modx, possibly using a plugin, solving the bug system wide.

Why [tt]$_SERVER["HTTP_REFERER"][/tt] is malformed is a mistery to me, ideas anyone?

This ’solution’ only partly fixes the problem, the path is still malformed, so search strings won’t show up in Slimstat yet.

thx

Ok, digged somewhat deeper into this problem.

When I look at [tt]$_SERVER[’HTTP_REFERER’][/tt] at line 50 of [tt]modx/index.php[/tt], so presumably before anything else happens in modx, the referrer URL is already malformed; the colon [tt]:[/tt] missing, etc.

The same variable looked at outside modx is perfectly fine.. how can this be? Does one of the core modx developers have something to say about this? Looking at the nature of the problem, I suspected some regular expression, url_decode or other parser to be the culprit. But this happening at the start of [tt]index.php[/tt] seems very odd..

thx, rnd.

Looks to me like it happens right there, line 53... if I understand the regular expression correctly, anything that is not one of the characters or within the range of characters specified will be replaced with nothing, and I don’t see a colon in that bunch.

Thanks Susan, but the URL malform already happens before that line.. that’s the odd thing. Although I’m not well versed in regular expressions, I don’t see why that one would strip a colon out. The way it is at the moment, referrers in modx are useless and I hope to find a fix.

Thanks again!

rnd

Are you sure? I just tried die($_SERVER[’HTTP_REFERER’]); on line 50 if index.php and the colon was in it’s usual place. However when placing it in a snippet somewhere the colon is missing. So presumably it is being garbled by MODx along the way somewhere. do not have Slimstat installed by the way.

FYI, I added a \: to the search string in the regex that susan identified and slimstat started reporting referrers immediately. Now, how to get it to report search strings is another thing entirely ... perhaps the filtering is still a bit overly aggressive.

From the main index.php, change line 54 from:

To:

Not the added "\:" before the "\/"