Automatic visit count (+/-.5k visits a day)

[Adam Kiss]

Hi Ryan,

I'm thinking of having internal viewpage count for one of my templates (they are shop profiles), because client would like to have 'most favorite shop' feature on the webpage.

So my idea is to modify one value (integer) every time somebody loads the webpage, and check once a month whether there isn't something irregular (so I could bump the hackers down).

What might be the impact of this, if we talk about +/- 500 visits a day? Would it be okay, or could we feel it?

Also, I thought about something more sofisticated (something like IP count, for instance), but I couldn't come up with anything better with session saved array of what was already visited, so the shops can't open up their pages and hit Cmd+R forever (or, worse yet, just so they get a bit higher in the top count, because that wouldn't be flagged as irregularity)

What's your take on this?

Note: we already scratched the like button for shops

[ryan]

I think this would be pretty straightforward to do. Assuming you are recording a per-page count, then you'd want to add a integer field to the page (called 'pageviews' or something like that). Then at the bottom of your template:

<?php
$key = "pageview" . $page->id; 
if(!$session->$key) { 
   $page->pageviews++; 
   $page->save('pageviews'); 
   $session->$key = 1; 
}

You may also need to add a $page->setOutputFormatting(false) above that if PW throws an error. And you might prefer to take it a little further and use an array in your $session var.

The only real problem with this method is that a portion of pageviews on any site are going to be from bots, spiders, etc. You can eliminate nearly all of those by setting up a new template/page that does nothing but record pageviews and hit it with javascript. The example assumes you set this up at /tools/pageview.js (a PW page), and you would paste this somewhere in your template that powers the pages you want to track:

<script type='text/javascript'>
// write the script statement with JS so that spiders don't attempt to include it
document.write('<scr'+'ipt type="text/javascript" src="/tools/pageview.js?id=<?=$page->id?>"></sc'+'ript>');
</script>

Then your template running /tools/pageview.js:

<?php
if(($id = (int) $input->get->id) > 0) {
   $p = $pages->get($id); 
   if($p->id && $p->fields->has('pageviews')) {
       // page was found and it has a 'pageviews' field 
       $key = "pageview" . $page->id; 
       if($session->$key) {
           // pageview already recorded for this page, so skip it
       } else {
           // pageview not yet recorded for this page for this user session 
           $p->pageviews++; 
           $p->save('pageviews'); 
           $session->$key = 1; 
       }
   }
}
echo "// this JS file intentionally blank"; 

What might be the impact of this, if we talk about +/- 500 visits a day? Would it be okay, or could we feel it?

I assume you meant thousands not hundreds. But regardless of the number (or even if it has a couple extra zeros), it should not be a problem. You won't notice a difference in performance. And given that you are just saving one field 'pageviews', rather than the entire page, it'll be especially fast (at least in 2.1).

[Adam Kiss]

Holy Macaroni!

I can save only one field in template? I didn't know that – that's why I was curious about impact between 500–1k visits, because I thought whole pages are saved.

As for bots, I don't care for real pageviews by people – there's always GA set up on the page for the real count, but I assume bots crawl sites fairly equally, so statistics (and therefore selecting top 3) should be rather fair.

[ryan]

Entire pages are rarely saved (except when creating it for the first time). Even when you do a $page->save() without specifying a field, PW will only save the fields that actually changed after the page was loaded.

But if you only need to update a single field, it's still preferable to specify it like $page->save('field_name') because it doesn't have to check any other fields, doesn't have to clear caches (2.1), and doesn't have to do anything else.

As of this week, 2.1 is quite a bit more efficient with saving an individual field than it was before. That's because it no longer attempts to clear the cache when saving individual fields. As a result, I would suggest that you use the latest 2.1 in this case.

[MilenKo]

Hello guys.

Searching today for page hit counters I stumbled acros your sollution which was working back then. Would you know if the approach would still work with 3.0.6X or if there is  a wiser approach to take for a 'clean' page hit counter that would not include bot counters, page reloads nor super user visits?

[DaveP]

<disclaimer>even less expert in this than other stuff</disclaimer>

Can't see why not, in fact, since this thread was last updated, we now have e.g. ready.php, where IMHO it would be easy to put a bit of code to update a counter field.

Filtering by user would be straightforward, and you could do something clever with $session to discount reloads, but bot user agent sniffing has always been something of a dark art. Jeff Starr has a probably-reliable list on his blog. (Warning - if you are interested in this kind of stuff, you could lose half a day reading there.)