I hadn't realised, but over time, I'd gradually become "gun-shy" about clicking the links on my own site, and Google Analytics is the reason, but not the cause.

Since setting up my blog a few months back, I've been using BIGSHOT Google Analytics plugin as a convenient way to add the Analytics javascript to my page and although simple, it got the job done.

The only issue I had with Mr. BIGSHOT's effort is the same issue that I had with all the Analytics plugins - they don't distinguish between admin and visitor clicks.

In my case, as a solitary admin, I like to view a page once it's been published, then go back and forth a few times, editing and viewing, to remove all the insults and curse-words. With Google Analytics constantly active, all those clicks on the front-end are counting towards my site's totals for such things as unique visitors, page views and time on site.

That of course throws out the real figures, which over time lead to me avoiding using my own site, and that meant that little problems went unnoticed. Little issues like broken links, categories pointing to nothing, bad font colour choices, RSS feeds in the wrong location on certain pages, etc.

After a few hours of heavy tweaking yesterday, I checked Google Analytics only to discover that I'd apparently been responsible for 50% of my site's page views for the day! Now I've got an indelible "phantom" spike on page views for February 11th that I can't get rid of... enough is enough.

Doing something about it

The first stop was to check the Joomla Extensions site to see if a new plugin had popped up that avoided counting admin clicks. To my surprise, there was new one called WebGuru's Google Analytics for Joomla, proudly boasting that it solved the unsolvable: "Don't track your visits, track your visitors".

I updated the testing installation of my blog to the latest version to try out this bold claim, installed WebGuru's software, and viewed a page. Sure enough, the Google Analytics code was gone.

Aha! A solution, or so I thought.

Trundling off to my online server, I installed the plugin, refreshed the front-end and viewed the page source. No dice, the Google Analytics code stubbornly refused to budge.

WTF? It worked on my test server.

The mystery solved

To cut a long, boring story short, I spent quite a few hours researching what had gone wrong, and it turns out that WebGuru's solution depends on the definition of "logged in".

Joomla is composed of a front end and a back end, both of which can be logged into separately using the same credentials, resulting in separate session cookies. WebGuru's solution relies on examining these cookies, comparing them against the session variables recorded in the jos_sessions table, to see if one of the cookes has a Group ID in the range of the admin user groups. If one is found then an admin user is logged in, so the plug-in simply doesn't add the Google Analytics code to the bottom of the page.

Easy, that is, unless you are logged in through the back-end on a secured web server, which is how I normally am, since I'm just a solitary blogger and I'm always tweaking. The problem here is that the back-end cookie is secured, so it isn't visible from code running on the front-end, which means that the plugin, when run while generating a front-end page, won't see the admin user's session cookie, and so won't know and admin user is logged in.

That's the reason why WebGuru's plugin worked on my development server - I'd disabled most of the security to make it easier to work on, which meant that the plugin could see the admin cookie.

I haven't tested it, but in theory, the WebGuru plugin should work OK if the admin user logs into the front-end whenever they are logged into the back-end.

A workaround

Suffice to say, I tried everything, even time travel, to make it work the way I use Joomla, but to no avail.

I did however come up with a kludge. I altered BIGSHOT's plugin so that when an admin user refreshed the back-end, it would write a list of session cookie ID's that it could see to a table I created in the Joomla database. Then, when the plugin was run from the frontend, it would look at this table to see if the current session id was in it. If it was, then that meant that the back-end could see it, and thus somebody has logged into the back-end, presumably an administrator, Me.

This works because the front-end cookies aren't secured, but it relies on me browsing to my blog first thing to have it create a front-end session, then opening the back-end to put the session into the table. Messy, but not difficult.

I won't be publishing the code for this as it's a horrible hack and I really don't want to be blamed if you start to think your site is underreporting visitors.

In the long run, once the site has settled down enough that I can stop playing around with plug-ins and tweaking settings, I'll have to bite the bullet and start using Joomla as a front-end admin...