Storing last visited items

Hi,
so i am looking at updating our beach website and want to have a feature on the front page that if someone isn’t logged in they can see the last few beaches they looked at. Basically the same as when you go on many shopping sites and it show you your recently viewed items.

My question is how best to do this (as i’ve not done this before).

My thinking so far is that i need to use php,mysql and a cookie.

When a new user visits (and isn’t logged in) the site sets a cookie with an id number. Each of the beach pages then use that id number to update a table with the page title and url.
The database is queried (using the cookie id) on the home page to return the last beaches looked at.

Is this how it would/should be done? would IP address be better?

any thoughts appreciated

Every system has its advantages and disadvantages… but in this case I don’t see any advantage of using an IP address. I think that in this case, a cookie is more than enough. No need to complicate your life unnecessarily, me thinks.

cool thanks so i was thinking along the right lines then. I wasn’t sure for example whether i should be storing the last 3 visited pages in the cookie and not have the database at all, but it sounds like having an id refering to the db is the way to go. I guess it will be much more flexible if i want to display more or less and things like when they viewed it last.

thanks

Again, this depends on what you want to do… Having the url of the last page (or three) he visited will only be useful if you want that when he visits next time, that page is displayed. But if you want to show the last pages visited in the home page, then that needs to be built dynamically. Then, the id would make more sense.

yeah i think the fully dynamic version will be the way to go.

So was thinking about the database side of things and i am thinking that each time they visit a beachpage it will insert an entry into the database. Should i look at updating rather than just continually inserting rows.

eg. User looks at Beach A so it insert a record (Beach A @ 1pm) they then look at beach B and inserts (Beach B @1.30pm) they then go back to Beach A and it inserts (Beach A @ 2pm).

They have only looked at 2 beaches but there are 3 entries.

Should i update instead of insert so… If beach A = DB beach name update where cookie id = table id

The only disadvantage i can see is that i wouldn’t know how many times the user has visited the beach only the last time they visited.

Or should i not worry and just insert individual entries on every beach page visit

We get a million visits a year and if everyone looks at a couple of beaches there will be millions of entries into the recently viewed table. Will this be a problem or should i removed entries after a certain time cut off?

thanks

Well, you want a lot of control… for what purpose? The cookie can save that information, if you’re that interested but I don’t see the point to store that information in a database.

the site also enables people to register for an account so i figure the db table will also serve that purpose.

The cookie will obv only be machine specific but if a user logs in from any computer the db table would have the last viewed beaches available.

which is why the db route seems a better option.

Its just knowing how much to store in the db.

I can understand that amount of personalization for a registered user but no for a non-registered one.

As sad as this is, you may have a million visits but only 2-5% of those will be registered users

ah ok so you would suggest that i could store lets say 5 recently viewed beaches in a cookie. So would only need to create and update the cookie without the need for a database.

how would you suggest i store the data in the cookie. as an array (comma separated)?

So it would just be page { title, page url, viewed date } for each beach page.

would that be a sensible way of doing it?

thanks

If you’re going to use the ID… do you really need the URL? It’s built dynamically and it is your own domain…

This question, again, is too generic but comma separated values should be fine.

had a play with cookies and arrays and done the following example which sets a cookie with an array of 3 beaches and their urls and date set (would need to pick this up from the page dynamically but as a test it’s just hard coded).

I’ve serialized and urlencoded (learnt something today) so the string will sit nicely in a cookie.

Seems to do what i am thinking. I guess i could just pick up the page from the database id instead of the url. Would make the string shorter i guess.

so i didn’t need a database after all :slight_smile:

    <?php //Coookie test

if($_COOKIE['recent']){
//this happens if cookie is set
echo 'Cookie ingredients';
echo '<br>';

//look through the cookie and return
$recent = unserialize(urldecode($_COOKIE['recent']));

//run through the array and print out or do whatever with the results.
echo "<ol>";
for ($row = 0; $row < 3; $row++)
{
    echo "<li><b>The row number $row</b>";
    echo "<ul>";

    for ($col = 0; $col < 3; $col++)
    {
        echo "<li>".$recent[$row][$col]."</li>";
    }

    echo "</ul>";
    echo "</li>";
    }
    echo "</ol>";
    
    
    }
    else
    {
    
    //set an array with the data
    
    $array = array
      (
      array("Bovisand","/beach/bovisand-bay","20150109"),
      array("Wembrey","/beach/wembrey","20150109"),
      array("Portown","/beach/portown","20150109"),
      );
    
    //serialize and urlencode to put nice string into cookie
        $str = serialize($array);
        $strenc = urlencode($str);
        //print $str . "\n";
       // print $strenc . "\n";
    
    
    
    //let#s set a cookie with an expiry date in the future
    //Calculate 60 days in the future
    //seconds * minutes * hours * days + current time
    $inTwoMonths = 160 * 60 * 24 * 60 + time(); 
    setcookie('recent', $strenc, $inTwoMonths); 
    echo 'cookie set';
    
    }
    
    
    
    ?>
1 Like

Be careful with storing too much information in the cookie.

The cookie content will be transferred with every request the user create to the domain the cookie belong to. This means if you server images, etc. from the same domain, then the cookie will also be transferred on those requests.

If you check the larger systems using this, they normally create a unique cookie value, and then store the reference data either in a database or other storage like memcached (depending on how long the information should be valid).

This does of course require more resources on the database when pulling the information, but it is still cheaper than having the server handle the overhead of larger cookies.

Ah ok thats useful to know. I think for now it would just be the last 3 visited beaches and if i do as suggested above it can just be the beach id to call the page so could get it down to ( beach id, date) for each of the 3 beaches. Which i guess would be only small string in the cookie.

Can always implement the database if i need to store more data as i will have to set one up for signed in users anyway as that will store more beaches as a ‘feature’ of registering.

thanks all i think i’ve got a good start to go on now and see how it behaves in the real world.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.