View Full Version : Stupid problem: counting page views

11-02-2007, 06:27 AM
Ok... am I going crazy, or does this code sometimes increment by one and sometimes increment by two or three, with each refresh?


The current views are the first number, and the updated views are the second number. The second number should increment by one, and only one, with each refresh.
So the second value should be equal to the first value of the next page load after refreshing. I'm about ready to shove a red hot poker into my cornea.

Can someone else try this for me? I load the page in IE, and it increments by one. I load the page in Firefox, and it increments by two.
Whaaat?!?! Am I totally losing it here? Isn't this PHP thing SERVER SIDE?!?!


$dbc = mysql_connect( 'localhost', '*****', '*****' );
mysql_select_db( '*****', $dbc );

function getViews()
global $dbc;
$sql = 'SELECT `pages`.`viewsTotal` FROM `pages` WHERE `pages`.`id` = 1';
$res = mysql_query( $sql, $dbc );
$row = mysql_fetch_assoc( $res );
mysql_free_result( $res );
return $row['viewsTotal'];

function setViews()
global $dbc;
$sql = 'UPDATE `pages` SET `pages`.`viewsTotal` = ( `pages`.`viewsTotal` + 1 ) WHERE `pages`.`id` = 1';
$res = mysql_query( $sql, $dbc );

echo 'Current views: ', getViews(), '<br />';
echo 'Incrementing views.<br />'; setViews();
echo 'Updated views: ', getViews(), '<br />';

mysql_close( $dbc );


11-02-2007, 07:02 AM
Based on the URL, I would guess that url rewriting is being used.

I recall a problem with a missing trailing slash / in the rules, where two requests end up being made to resolve the actual url. I don't recall the specifics, but it goes something like this - the first request to the server determines that the requested url is not to a folder with a default document, the second request resolves to the actual file.

11-02-2007, 07:10 AM
I hadn't even considered that.

I just loaded the actual file path and the same thing is still happening:

Still incrementing by one in IE and by two in FF.

Maybe I need a nice long night's sleep.

Here's another stumper:

Visit that page.
Click the GO HOME link (index.html) a few times. You will (should) notice the counter in the upper right upping by two (Firefox only??).
Now, click any other button multiple times. You'll notice the views upping by only one.

The same centralized code is obviously being used for each page.

I currently want to rip each and every hair out of my head.

You've got me thinking CFMaBiSmAd, could there be something in the way different browsers handle mod_rewrite... and I've just never noticed it before? I can't recall this ever being an issue in the past.

11-02-2007, 07:44 AM
Other than finding what is triggering the multiple requests, I don't know what is actually causing this, but here is a fix -

Use a session variable to act as a one-shot. If a visitor arrives at a page and a session variable either does not exist or it exists with a value saying they were last on a different page, increment the database counter for that page and set/create the session variable with a value that indicates the current page.

Then, if they refresh, the session variable will say the last page they were on is the current page and the database increment code will be skipped over.

If they browse to a different page on the site, the session variable holding the last page will be different than the new current page and the logic will increment the count for that page.

This logic also works for the case where they browse away from the site but keep the browser open and then come back either to the same last page or a different page.

If they close the browser/close the session and then come back, it will look like a new view of whatever page they go to.

11-02-2007, 07:55 AM
I'd though about that, but I'm keeping that as a last-ditch option. I'm a freak for minimal, efficient code, memory management, etc. I'm definitely not saying that's the least efficient way to go about it, but if they visit the index page a number of times, the session array will essentially generate a new key with each page load. There are obviously ways to keep the size down, but I'd like to figure out why the heck this is happening as opposed to just applying a band-aid. ;)

I can't for the life of me figure out why it would happen on the index page, and every other page is counting fine. I think I'll sleep on it and revisit it after work tomorrow.

11-02-2007, 08:10 AM
Gah, I've figured it out... I sent myself the REQUEST_URI in an email directly beneath the UPDATE query.

In the .htaccess file I was using index.php as the 404 Error Document.

Firefox was automatically trying to locate /favicon.ico (sometimes twice?). It doesn't exist, so it was loading index.php. Now I just have it skipping /favicon.ico:

RewriteRule ^favicon\.ico$ - [F]

Problem solved. Oh man, I can sleep easy tonight. There's a good three hours down the drain.

11-02-2007, 08:22 AM
I think some of your multiple counts are due to multiple visitors (now that these links have been posted somewhere.) However, I believe the issue is trailing slash on the url (try the one in the first post with a trailing slash on the url so that it does not need to figure out that wtf is a folder instead of a file.)

why it would happen on the index pageI think that is significant, as in the web server finding/resolving default documents.

In searching, I found some articles concerning trailing slashes and the redirect that results when there is not one - http://httpd.apache.org/docs/1.3/mod/mod_dir.html and http://httpd.apache.org/docs/1.3/misc/FAQ.html#set-servername

11-02-2007, 08:25 AM
The multiple hits were definitely happening before I posted the address. You may have cross-posted as I posted the solution, but it was just a 404 document reloading index.php. I had no idea Firefox would automatically make a request to favicon.ico. All example are working fine now because I have absolutely cut-off favicon.ico.

11-02-2007, 05:08 PM
favicon.ico's can mess you up like that.

I once had IE come up with Page not Found for a URL that I knew worked.

Looked at the URL and surprise, it was showing the favicon.ico that it attempted to load. Which obviously didn't exist.

I believe IE's implementation of favicon.ico has been criticized before.

But I'm curious, how come a request for a resource file is being processed by your PHP?