SitePoint Sponsor

User Tag List

Results 1 to 10 of 10
  1. #1
    SitePoint Guru mwolfe's Avatar
    Join Date
    Mar 2005
    Posts
    912
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    integrating unregistered user id with registered id

    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

  2. #2
    SitePoint Guru mwolfe's Avatar
    Join Date
    Mar 2005
    Posts
    912
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    any ideas? i'm sure someone has worked with this before..

  3. #3
    Umm. PHP Guru....Naaaah jaswinder_rana's Avatar
    Join Date
    Jul 2004
    Location
    canada
    Posts
    3,193
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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
    ---------------------------
    Errors = Improved Programming.
    My Site

  4. #4
    SitePoint Guru Galo's Avatar
    Join Date
    May 2005
    Location
    Holland!
    Posts
    852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 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
    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
    Business as usual is off the menu folks, ...

  5. #5
    SitePoint Guru mwolfe's Avatar
    Join Date
    Mar 2005
    Posts
    912
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  6. #6
    Umm. PHP Guru....Naaaah jaswinder_rana's Avatar
    Join Date
    Jul 2004
    Location
    canada
    Posts
    3,193
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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
    ---------------------------
    Errors = Improved Programming.
    My Site

  7. #7
    SitePoint Guru mwolfe's Avatar
    Join Date
    Mar 2005
    Posts
    912
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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

  8. #8
    SitePoint Guru mwolfe's Avatar
    Join Date
    Mar 2005
    Posts
    912
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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)

  9. #9
    Umm. PHP Guru....Naaaah jaswinder_rana's Avatar
    Join Date
    Jul 2004
    Location
    canada
    Posts
    3,193
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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
    ---------------------------
    Errors = Improved Programming.
    My Site

  10. #10
    SitePoint Guru mwolfe's Avatar
    Join Date
    Mar 2005
    Posts
    912
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •