i have data from database and i need to count the views for every click,
i need to count only unique click for the current hour.
saving it in database is not in my options. and for the user to know that he/she already click that data
should i use cookie for every data that users clicked or session?
thanks.
I would store it in a session, there is no need to send it back and forth with every page request, that would only slow things down, especially if the site is big and the internet connection of your visitor slow.
However, note that you can only display this information to your visitor if you use sessions or cookies, there is nothing that you can actually do with it unless you store in in a database or a text file.
Related
What I would like to do is essentially check whether or not a user has clicked a certain link on a page. The idea behind the functionality is that a user can click "Thanks!" on a post created on the website, but they can only submit one "Thanks!" per post.
I have no problem creating a simple click counter for the "Thanks!" button, and save the count to a database using PDO, but I am not sure how I can assign a click to the user who's session is active.Also, posts are constantly being added to the site, so I would need a system which would scale to more posts automatically.
Any guidance is appreciated, thanks!
Note: I know I have not put any example code, but I believe this is simple enough for a good programmer to grasp quickly.
EDIT
On further thought, the IP can not be used to distinguish users, as this website will be used by many people on the same IP.
Are the users logged in or anonymous? If they are logged in just save their user id in a session variable and upload it with their vote to a table in your database.
I do something similar using an Ajax request to a .php page that inserts a row with the session user ID and the vote.
If they are anonymous you can save their ip but that leads to problems with users who share the same ip address. Another (bad) option is to use cookies but users can obviously just clear their cookies and vote again.
I'm looking for a way to time a visitors stay on a website, whilst not restarting or interrupting the timer when changing pages.
Store the initial visit time in a session value. Any future visits to the site use a secondary session variable to hold the last visited time and work out the time on your site from that.
Unless you use Ajax to update the session values the user could be active on your site (on the same page) for 20minutes but it would show up as a zero length visit.
Basic example:
<?php
session_start();
if(isset($_SESSION['firstVisit']))
$_SESSION['latestVisit'] = date();
else
$_SESSION['firstVisit'] = date();
echo $_SESSION['firstVisit'] . " - " . $_SESSION['latestVisit'];
?>
You can start a session the moment the user requests the first page. With the session you can track the user from page to page. so you could calculate the total time between the first and last page requst of their visit.
You should also be able to send an Ajax request on page unload, thereby you could detect the time spent on a single page. However, if they browser in multiple windows/tabs, your reading is false, unless you are somehow able to detect page focus.
Combine the two and you should be able to get a quite complete picture.
store the data in the session, and save the data when the user performs logout
(if the user does not logout it will not be saved, but that should not be a problem)
edit: if the users does not login/logout, you have to catch when the session dies and save the data then. when evaluating the data you have to compensate for how long the session lives before it dies, e.g. 5 mins or whatever, and subtract it. will give you a ballpark figure, not exact time the user looked at the site.
You can track the time for which the user was logged in, but if you want the amount of time (a non logged in) user stays, I dont think it is possible, as there are a lot of ways to move from one page to another
I have created a mobile version of a site. It uses the CodeIgniter session to store some data. This seemed okay on Blackberry a few weeks ago but now it is making multiple sessions on every page and therefore it can't access the session where the data is saved. This works fine on the desktop and iPhone. The cookies are being saved to the Blackberry. I've got it so that it using the database to save the data.
On every page it checks to see whether the phone is touch screen to show the page differently. There is also some other data. It's all being saved but into many sessions.
It's on a subdomain - m.domain.com so I'm wondering if the domain name for the cookie might need to be set differently.
EDIT:
I managed to sort it out by saving the session id in a different cookie and then calling that in a query to get the info. Thank you to the person who replied.
do you proceed you session-id on every link and every form? if not, and the client doesn't accept cookies the session will be lost on every new page load - exactly what you're describing.
EDIT: to correct that, take a look at the documentation (+ Passing the Session ID) - just add the SID-constant to all you links and forms, it will automatically be empty if the browser accepts cookies, so the url isn't that ugly for those clients.
I am building a website in which the user can select what list items they see in their navigation menu, my idea is to store the menu items that the user selects in a cookie as this will stop the need for the user to be registered member on the website, is it possible to store realtime data in a cookie and how would I do this? For more information the navigation options are built from a mysql result, the then clicks a link and that link is added to a different list, if they click it again it is deleted, I need to add/remove these items from the cookie as the user add/removes it from there list.
i would use the cookie only to identify the user and do all of your menu option saving in MySql.
Grab the user id from the cookie and query the db for the menu_options and display them.
Either way, storing the data in a cookie or in the database, when the cookie expires, so does (effectively) the user. Plus people delete cookies all the time using cleaners like Adware and CCleaner. I do this about once a week. Cookie = Gone.
This is a bad idea.
The number of cookies a browser can store is not defined (however there is a hard limit for most browsers). RFC 2109 suggests at least 20 cookies per host and a min cookie size of 4k. Certainly the latter is adhered to by most browsers.
You're also going to have to replicate all the features of session management without the nicety of having server-side state. You do not want the kind of pain going down this route will cause you. Keep your session data server-side.
There is no requirement for a user to 'log-in' to have a session. You just need to assign them an automatic identity in a persistent cookie (the replace that if they ever do sign in). And map the session back to a more long term storage when the user changes the config.
C.
I'm working a site where users could technically stay logged in forever, as long as they never close their browser (and therefore never get a new session key). Here's what I could see happening: a user leaves a browser open on computer A. The then use computer B, login and change their name which is stored in the session. They logout of B, but A is still logged in and still has their old name stored in the session. Therefore, their name won't be updated till the next time they logout manually or they close their browser and open it again and are logged in through the remember me function.
Name is a simple example, but in my case the subscription level of their account is stored in the session and can be changed.
How do you deal with this?
A few ideas that I have are:
After a period of 10 minutes or more, the session data get's reloaded. It might be exactly 10 minutes if the user is highly active as the function will get triggered right at the 10 minute point or it could be after 2 hours if the user leaves and comes back and then triggers the functionality.
Store as little information as possible in the session and load the rest from the DB on every page call. (I really don't like this idea.)
Use database sessions and use the same session on all the computers. I like this, but I could see it getting confusing when something like search criteria are stored in the session--the same criteria would show up on both browsers/comptuers.
For information, even such as the user's name or username/email address, store it in the session, but for other information that would heavily affect their abilities on the site, don't store it in the session and load when needed (attempt to only do it once per instance).
Are there other better methods?
--
Another option: 5. Use database session and when an update is made load the user's other sessions (just unserialize), change the relevant information and save them back to the database.
I would go either with number 1 or number 4. If you store the time of the last update of the information, you could even ask on every request whether the date has been updated.
Don't store information likely to change in the session, if you're looking at scenarios like the one you outline. Just get over your dislike of loading user data with every page - it's by far the best idea.
I'm guessing you don't want to load the data from the database because you're concerned about performance issues somehow. Before you try out any of the other solutions, you might want to test how long it takes to actually load a users data from the database, then check that against your number of users - chances are you won't see any performance problems due to loading user profiles on every page.
Regards
I'd go with option 6: only store userid and session specific stuff (search criteria) in his session and put the rest into APC/xcache (memcached if you're using multiple servers).
this way you'll only have to go to the database the first time (and after the cache expires) and you can still share any data between users sessions.
Normally you should do 2), but you don't like it.
maybe you can use sessions stored in db.
when a user change his name, put into all sessions from that user the information "refresh userdata".
on the next request the userdata is reloaded again into the session and is cached there.
this can be done be reusing your loaduserdata function which called at login.
php session_set_save_handler() - also read comments
php session_decode() - to read the username from the session to store it additionally to the sessiondata. usefull for easily to find the users sessions for updating.
[edit]
don't forget:
when you are updating all the sessions while the page is generated (between session_start and session_write_close) you changes maybe lost.