integrating unregistered user id with registered id

[mwolfe]

Currently i have a system setup for users to pick songs for there wedding reception. This works fairly similar to a shopping cart. I did not write the site using sessions rather i wrote it using cookies.. I plan on upgrading it with sessions, and allowing users to use the site without having registered.. of course they will need to register before they can complete. Currently they can browse songs but can't add them tot here "cart". What i need to know is a good way to integrate the two, between a user who has not yet registered's songs with the user once he registers..
Currently the user registers his/her name and that is his unique identifier (other than the built in unique id). I'm thinking i would have to take the session ID and use that as the users i'd.. then once he registers i need to like rename that to the name he registers right? I'm not really sure if thats the way it typically gets done..
I would almost prefer to put a temp into another table that way i don't store a bunch of extra information that will never get used (for all the users who do not follow through with registering and using this service).. What do you guys think about this? Also, if i do that, what is the best way to "recycle" the system (i dont know if thats the right term i just made it up). I'd like to store say up to 25-50 temp accounts before the first gets replaced with a new one.. I suppose i would have to run a query to find the lowest id (not sure how to do that) and remove that entry.

Any ideas

[mwolfe]

any ideas? i'm sure someone has worked with this before..

[jaswinder_rana]

sorry, i din't get it
if you want only registered users to select songs, then whenever they try to do something which needs user to be registered then ask them to register first. not need fo rtemp tables. its too much for nothing. and i'd say not only the user ID should be unique, but also the username.

same like in sitepoint. you can read the posts, but you need to be a registered user to post(eg). i hope i am being clear.

hope this helps
EDIT: you migh twanna take a look here for a user authentication system, tutorial. http://www.sitepoint.com/article/ant...ess-control/16

[Galo]

Currently i have a system setup for users to pick songs for there wedding reception. This works fairly similar to a shopping cart. I did not write the site using sessions rather i wrote it using cookies.. I plan on upgrading it with sessions, and allowing users to use the site without having registered.. of course they will need to register before they can complete. Currently they can browse songs but can't add them tot here "cart". What i need to know is a good way to integrate the two, between a user who has not yet registered's songs with the user once he registers..
Currently the user registers his/her name and that is his unique identifier (other than the built in unique id). I'm thinking i would have to take the session ID and use that as the users i'd.. then once he registers i need to like rename that to the name he registers right? I'm not really sure if thats the way it typically gets done..
I would almost prefer to put a temp into another table that way i don't store a bunch of extra information that will never get used (for all the users who do not follow through with registering and using this service).. What do you guys think about this? Also, if i do that, what is the best way to "recycle" the system (i dont know if thats the right term i just made it up). I'd like to store say up to 25-50 temp accounts before the first gets replaced with a new one.. I suppose i would have to run a query to find the lowest id (not sure how to do that) and remove that entry.

Any ideas

So you have the problem you want to show different songs for non-registered users and registered users or am i wrong, in that case it's better to have implement user-based levels and show songs according to the level the user has i.e. admin : usrLevel = 0, visitor : usrLevel = 1, member : usrLevel = 2. i assume you have a database with a user table, add another record for storing the levels, you can read the table, store it in a session/cookie and write your algorithms according to a switch case state.
like
switch($_SESSION['usrLevel']).
case 0 :
case 1 :
case 2 :
etc...

Cheers,
Galo

[mwolfe]

Alright i think you guys missed my point a bit.. RIght now only registered users can use the site.. non registered users cannot add songs. In order to complete the process of the site (which includes submitting your song requests via a form that sends an email to the owner) they have to register, because the registration process is where the details come from about who they are and all that (Basically just contact information). But i just didnt want to deter people from using the site by making them register before they could try the process out..
Right now they can search for songs but they can't see any of the other steps like picking the special dance songs (like mother son, first dance, etc). Its not bad the way it is, its just when you visit a storefront you don't have to register before you add items to your basket, but usually you have to do some sort of registration before you can check out.. Well for my site, they will have to register before they finish the process, but it would be nice if there was some way i could let them use the service before registering by using sessions. If its a lot of work i'll probably ditch the idea but i'd like this service to be real well built and i think that is an extra that may increase the usefullness of the site.

[jaswinder_rana]

ok, what you can try to is see if they are logged in and set some variables say
$_SESSION['user'] = 1;
to see if they are user.
if $_SESSION['user'] = 1; then itmeans they are not user.

let them browser the website, add the songs and when they try to check out then check against this variable and if its 0 then ask them to register and if its 1 then let them proceed.

i think this is the best solution than creating temp tables and all.

you'll set this variable to 1 if they log in unless it'll be either NOT SET or 0.

hope this helps

[mwolfe]

alright.. That makes sense, except i still will have the problem of where to store the songs they have added.
Currently i have a table named music with the information for all the songs
liek artist, title, genre, length, etc
then a table for the users, including username, password, email, user_id, phone, priviledges (currently just user and admin, but i may add temp for the non registered users). Then i have another table for the users music, it contains a user id, song id, and special (indicating what special dance that song is for if any).

So basically i just need to know where to put temporary users songs.. Whether they should go in the same table as users songs or another table. And then also how to implement a unique username for each temp (session) user.. I know sessions are unique.. but is that only for active sessions, is it possible (i know its extremely unlikely) but that a session could be the same number from say today and two weeks from now if there were lots of visitors? THanks for your help, and i hope this make sense

[mwolfe]

by the way if my computer is on the site is up at www.mwolfe.dynu.com/weddingbells
you can see what i mean ( i still have to work out the design a bit more)

[jaswinder_rana]

You can use sessions if its not very big shopping cart.
this tutorial might help
http://www.phpbuilder.com/columns/evert20000816.php3
http://www.macromedia.com/devnet/mx/.../php_cart.html


moreover you can use database to use sessions, if you want to store session values in database.

hope this helps

[mwolfe]

Thanks, that makes sense now..
I guess i got so used to using the database i forgot that i could just create like an array for the song information.. That may complicate things a bit (since the tables all are generated from the result resource of a query and not just an array. But i'll probably figure something out. Thanks.. I'll play with it later, right now i need to go study for a stats exam, ughh.