Hey guys, im building a small product catalog for a client. I am currently trying to figure out how to go about allowing the user to sort by "popularity". I figured the easiest/simplest way to do this would be by having a "views" field in each product record.
Originally I didn't think this through (duh) and thought I would just add one to the "views" count when the function to retrieve a specific product is called. Of course the problem with this is that it doesn't account for someone refreshing the page 30,000 times.
What is the best way to go about this? Does php have any sort of way to see if a visit is unique?
I am using php/codeigniter/mysql/html/css/javascript/jquery.
You could store if the client has already visited the page in a session variable, and run the same views query. Now this won't prevent a user from closing the browser, reopening, and returning, but it should provide a decent level of protection. If that's not enough you can move to cookies, followed by user registration, or IP tracking.
Okay, the session approach. On your page you run:
session_start();
if(!isset($_SESSION['page_views']['some_unique_string'])){
$_SESSION['page_views']['some_unique_string'] = true;
// update your database
}
Note that you'll want to make sure 'some_unique_string' is unique to the page you're tracking views on.
The approach is nearly identical for cookies.
If you want to make sure the page views are unique you have to store the remote IPs of all the page views. There's really no other reliable way to know if a visitor has visited or not. Placing a cookie on their system will fail at a later date for a million different reasons, they cleared their cookies, they used a different browser, etc. You need a views table with a foreign key back to whatever you're counting views for.
You can find all of this sort of code in my free rated images script here:
http://destiney.com/php
Here's a demo:
http://ratedsite.com/
Look at the addImageRating.php script.
Related
I do have Google Analytics on my site (tied to adwords), and have tried many other packages for tracking visitors, but none give me the detail I need. My goal is to keep the exact path visited, per IP.
All those tools work by adding a piece of code to the page, that goes to their server to save the page visit.
It occurred to me that I could save the IP and breadcrumbs in a SESSION array, and scrape the session files directory every few minutes to save the files before they expire.
Later I could decode those and do all kind of of data mining.
This way I don't have to modify the code, don't have to make each page visit go to an external site, and I believe this is less taxing than, let's say... a mysql record write at every page visit.
Would this be a bad idea for any reason I can't imagine yet?
Thanks for any input.
It is possible to do nefarious things with $_SESSION, however, it is pretty safe. Your plan looks good.
On the other hand, users usually don't like it when you track them without their consent. Make sure you disclose the fact that you'll be tracking their every move.
What I would suggest is to use Apache access logs. Add any other information needed apart from default and be sure to log the session ID Cookie in access logs. This will allow you to group the data when data mining.
I have an interesting problem to solve here that may require some creative direction. I have a PHP page which has a variety of different page outcomes depending upon which value is passed through the web browser. For example:
http://examplesite.com/landingpage.php?id=one
http://examplesite.com/landingpage.php?id=two
http://examplesite.com/landingpage.php?id=three
With the current set-up, each of these pages has a different offer for the site visitor. Here is the catch...
I only want the page available to the visitor once per session.
That seems like it would be easy enough, but I cannot make it work right. I have used a one-time offer script to submit a cookie which then re-directs the user to another page if they have already viewed the offer, but that did not work for this situation. It will work fine for one landing page, but it is based on the root PHP page so if any of the other values are passed it will re-route the user even though they have not seen the offer.
For example, if a site visitor goes to:
http://examplesite.com/landingpage.php?id=one
they will see the one-time offer. Then, if they go to:
http://examplesite.com/landingpage.php?id=two
They will be re-routed as if they had seen the offer for 'two' which they had not.
I hope this issue makes sense. If you need further clarification, just ask. Thank you for going through my problem and if you don't have the exact answer, but can point me in the right direction it would be much appreciated.
Without looking at the code for landingpage.php, I can only guess that you are not factoring in the id when you check for the existence of the cookie. You need to set cookies on a per-id basis. Otherwise the behavior you see will occur: viewing id=one will set a cookie and when the user views id=two, landingpage.php sees the cookie exists and redirects the user.
If you want to keep it simple enough, you can just have your cookie be a string of id fields delimited with a character such as a pipe or comma: viewed_ids=one,two,three. Then you could parse this to see if the id of the current page is in the list of viewed ids and redirect the user if it is, or add it if it isn't.
I am sure you realize that maintaining state in the session can be easily worked around by the user, since you mentioned you only need this redirection to occur on a 'per-session' basis.
Whats the best way to keep track of how many users and guests are online? Im making a forum for fun and learning
Right Now I have a 2 fields in the users table called is_online and last_access_time.
If current time is 5 minutes or more than last_access_time i set is_online it to zero. And if the signed in user refreshes browser i set it to 1.
But what about guests? I wanna keep track on how many guests are on also
Another thing that would be really cool is to show what page the user is viewing. and on the page, forum thread for example, 5 guests, Homer and Shomer are viewing this page. But how should i structure this? Hmm maybe i should make another question for that.
i dont know what i should do
What do you suggest?
I'd use cookies for this. Set a cookie when the user enters (checking first to make sure one doesnt exist). Easy way to generate a unique id for that user is to hash their IP plus the current time.
$id = md5($_SERVER['REMOTE_ADDR'] . time());
Store that id in your database and use that to reference
You can check what page they are viewing by grabbing either $_SERVER['PHP_SELF'] or $_SERVER['REQUEST_URI'] near the top of your php source. Store that in the table. I'd take a look at php.net's explanation of whats stored in the _SERVER global, as it should help out quite a bit if you find that you need more then just the document they are on (ex index.php). Found here.
You may need to pull apart of the query string that was used to access that page, parse out the variables to determine the page they are requesting. Either way, this could all be done through cookies, or just use a single cookie to store the unique id and use your table for storing everything else.
You cannot know for certain which page a user is viewing, but you can keep track of which page they last viewed. Every time you deliver a page to a user, record that page's path in a database row associated with them. Voila.
To keep the number of guests, I suggest tracking the number of distinct unauthenticated IP/HTTP-User-Agent combinations seen on a certain page in the last X minutes.
I found this article on Web Monkey that might help you.
http://www.webmonkey.com/2010/02/how_many_users_are_on_your_site_right_now/
I want to allow users as well as me(the admin) to delete data in mysql.
I used to have remove.php that would get $_GETs from whatever that needed to be deleted such as... remove.php?action=post&posting_id=2. But I learned that anyone can simply abuse it and delete all my data.
So what's the safest way for users and me to delete information without getting all crazy and hard? I am only a beginner :)
I'm not sure if I can use POSTs because there is no forms and the data isn't changing.
Is sessions good? Or would there be too many with postings, user information, comments, etc.
Ex: James wants to delete one of his postings(it is posting_id=5). So he clicks the remove link and that takes him to remove.php?action=post&posting_id=5.
EDIT: Alright, so now I am a little confused. While I can't be 100% secure, how do I do this with $_POSTs?
SOO I should use GETs to get all the data to remove.php, THEN have a confirmation submit button and when users click on it, it put all the data into POSTs and delete from the dbc?
Deleting records is a kind of a scary practice. If you or someone makes a mistake there's no real recourse to resolve the issue. Expunged records are very hard to resurrect.
Instead of deleting records, you could add an "active" bit (e.g. Boolean) column that is toggled off when users "delete" records. Essentially your users would be suspending records by toggling them off and the records would be saved in case mistakes or abuse but appear "deleted" to the user. To make this work with your other queries, just add a where clause of active = 1.
You could then have a utility script that's run at some specific date interval that would clean out deprecated, past dated records. You'd also need some type of timestamp for this type of maintenance.
Just a thought. Take if for what it's worth.
I'll echo gurun8 in preferring to 'mark' records as deleted, instead of actually removing data. And then obviously, you'll need to check that the authenticated user has permission to delete the post.
However, it seems very important to mention that $_GET is not safe even with authentication because of cross-site request forgery.
Imagine if Amazon adding things to your cart based on a GET request. All I'd have to do is put an image on my page with that URL, and everyone who visited that page and logged into Amazon will have products added automatically.
To match your example, I don't like Jame's post, so i put an image on my site like this:
<img src='http://example.com/remove.php?action=post&posting_id=5'>
And I send him a link to my page, and ask him to check it out, hoping that at the time he's logged in to your site. Because, of course, he clicked that little 'keep me logged in' button.
So you are right to be concerned about using GET. If you don't want to litter pages with forms, then confirm the action by POST.
Well you have to start by authenticating the users with a login script.
If you want the simplest solution possible, then I'd suggest protecting the directory in which you have remove.php with a simple .htaccess username and password.
If different users have different rights for deleting database entries, then you probably should create a PHP login script and use PHP session.
Bonk me if I'm stupid, but I searched for quite some time for a simple PHP login tutorial that could be placed on a real site (doesn't use session_register(), uses mysql_real_escape_string(), htmlspecialchars() etc) and I simply couldn't find one!
Probably this one comes the closest, you just have to replace session_register() variables with $_SESSION ones for it to work without register_globals (default in PHP5).
Ok, firstly this is not about forms this is about consistent layout as a user explores a site.
let me explain:
If we imagine a (non-ajax) digital camera online store, say someone was on the DSLR section and specified to view the cameras in Gallery mode and order by price. They then click onto the Compact camera's page. It would be in the users interests if the 'views' they selected we're carried over to this new page.
Now, i'd say use a session - am i wrong?
are there performance issues i should be aware of for a few small session vars ( ie view=1 , orderby=price) ?
Speaking of performances, there should not be much problems with either solutions.
Some things that have to be considered are :
With GET, if an URL gets copy-pasted (in a email or MSN), the other who will receive the URL will have the same GET parameters
is that a good thing, or not ?
On the other hand, session will not be shared, if an URL is copy-pasted
which means the first guy will say to the other "key, look at this", and the second guy will not see the same page ;; same thing with bookmarking, should I add.
GET is specific to each URL
While SESSION is shared accross all tabs of the user
Which means browsing with several tabs at the same time can cause troubles, when using Session, if you don't take care of that
I'd say use both. Store it in the session, but also put it in the get parameters for the page.
Why? This way the user is able to carry his options from page to page, but they are also in the URL so if he sends search results to his friend, his friend sees them the exact same way he did.
No, the session's performance will not degrade by putting those small variables in there. Unless you're storing monolithic arrays in your session, the vast majority of the time loading a session will be reading it from its storage medium (file, database, memcache, etc).
You should use GET in your case.
There is one simple rule in the web development: each page with different content must have it's own address. So, customer can save any page into favorites, send it to a frend. It's pain in the bottom then someone sends you a link to a particular page saying "Look!" but site uses frames and you land at the front page and dunno where to look.
You can save user's preferences into his profile/cookie (not session), but it should be reflected in the address bar as well.
Sessions being used for completely different purpose, shopping cart is an example.
It's a subjective question, it would work either way.
Personally I would go with sessions as it doesn't interfere with the URL so people can bookmark the url if they wanted.
However the argument for that would be if they bookmarked it they might see different things if it was done using $_SESSION.