#1
  1. No Profile Picture
    Contributing User
    Devshed Regular (2000 - 2499 posts)

    Join Date
    Sep 2006
    Posts
    2,030
    Rep Power
    535

    Creating a signup form


    Hello all,

    I need to create a signup form. I have not done one since I first started with PHP, and while there are many beginner tutorials written on the subject, I hopefully "finally" know more than many of the authors. I wish the form to work with non-JS users, however, wish a better UI with JS users.

    The process has three (and maybe more) pages.
    1. Signup Form (currently one page, but maybe I will break into a couple). For JS users, it will validate client-side before submitting (and of course I will later validate server-side). For non-JS users, I will make the form sticky if it doesn't validate. If the user has already signed up (as determined by a cookie on the client), I will display some indication of this.
    2. Verify Information. Display the users input and give them the option to proceed or go back. One unique aspect is that I will verify the address, and if I do not think it is valid, will give the user the ability to use their inputted address, or what I think is their correct address. I am thinking I will include a hidden form on this page instead of putting the data uploaded in the previous step in a session, but am undecided.
    3. Form Received. It will tell the user that an email was sent, allow them to resend the email, and allow them to change the email they included in the signup form. If the user has already signed up but goes to the signup form, I don't want to display the signup form but display the form received page.


    I am questioning whether I should display the various pages based on a unique URL for each step, or use a single URL but display different results based on POST data and/or SESSION data. I typically implement some sort of MVC strategy. Related to this is whether I should submit, then return the next page, or do some sort of redirect server side, or submit vial ajax and redirect client side. I don't want the annoying browser warnings "Are you sure you want to re-post this page" for JS users, but don't care if non-JS users get this warning.

    Any thoughts of a good workflow to implement this?

    Thanks
  2. #2
  3. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Hi,

    exposing the steps through separate URLs will be very confusing, because users might try to jump straight to a particular step, which they're obviously not supposed to.

    So make it one URL and display the right content for the particular state the user is in.

    The re-POST problem is solved with the PRG pattern. It allows people to refresh the page or go back at any time.

    Use explicit hidden fields instead of implicitly storing the values in the session. Otherwise, the user might unknowingly submit different data than what they're seeing in the verification step. For example, they might run into this scenario: They submit data to step 2 in one tab. In a different tab, they submit different data to step 2 which overrides the previous data. Then they go back to their previous tab with the obsolete data. They submit the form, assuming they get what's on the screen. But they actually submit the session data from the other tab.

    You generally need to be aware that you have to deal with conflicting data. People may open any step of the registration page in many different tabs and many different browsers and then submit any combination of data. You need a sensible way for handling those situations.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  4. #3
  5. No Profile Picture
    Contributing User
    Devshed Regular (2000 - 2499 posts)

    Join Date
    Sep 2006
    Posts
    2,030
    Rep Power
    535
    Thanks Jacques1, seems very sensible.

    If I did use separate URLs, I would need some logic to redirect when the user is out of order, but then what is the point of separate URLs in the first place.

    Yes, I planned on using the PRG pattern. One problem I've challenge in the past is displaying validation errors. EDIT- Similarly, having a back button and keeping the form sticky. I solved it by storing errors in a session during the POST step, and sending back those errors during the GET step, but I always thought there must be a more elegant solution.

    Good point about the user having different tabs open. I didn't think about that scenario. Is just putting past form data in hidden inputs enough, or is more required? Also, just to clarify, but using sessions to do this (which I am no longer plan on doing) will not be an issue with different browsers as they will use different sessions, no?
    Last edited by NotionCommotion; February 18th, 2014 at 08:25 AM.
  6. #4
  7. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Originally Posted by NotionCommotion
    Yes, I planned on using the PRG pattern. One problem I've challenge in the past is displaying validation errors. EDIT- Similarly, having a back button and keeping the form sticky. I solved it by storing errors in a session during the POST step, and sending back those errors during the GET step, but I always thought there must be a more elegant solution.
    Well, you can't write the error messages directly into the response like you would do in the old model. You either have to store them somewhere (a cookie, the session etc.) or transmit them in the URL (which is confusing).

    But I'd say that's simply how modern web programming works. The whole idea of sending a POST request to a form is rather weird given the meaning on the verb. A POST request is supposed to add a subresource or append data to an existing resource, so it should go to the target resource, not some form. The target resource then knows what to do with it.



    Originally Posted by NotionCommotion
    Good point about the user having different tabs open. I didn't think about that scenario. Is just putting past form data in hidden inputs enough, or is more required?
    Like I said, you may receive conflicting data. For example, a user may send data to step 2. And 5 minutes later, they send different data to step 2. What do you do? Simply reject the submission and throw away the new data? Then a person who has simply forgotten the old tab and wanted to do the actual subscription in the new tab has a problem.

    Those are design decisions. I would simply sit down with a piece of paper and write down the problematic cases and the desired outcome. Then you can choose the techniques accordingly.



    Originally Posted by NotionCommotion
    Also, just to clarify, but using sessions to do this (which I am no longer plan on doing) will not be an issue with different browsers as they will use different sessions, no?
    Right. But tabs are a much bigger problem, anyway.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  8. #5
  9. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Dec 2013
    Posts
    6
    Rep Power
    0

    PHP Programing


    Here I am also learning PHP & I would like to pay thanks to each & everyone for support

IMN logo majestic logo threadwatch logo seochat tools logo