1

I am making a pretty standard PHP sign up form that will validate the data the user entered and then redirect to a page with a success message. I would like to store this data in a database. Should I insert this information into the database before I redirect the page or after it is redirected?

4
  • If the redirect is the success message then you might send a success message even when the entry in the database fails.
    – Pieter B
    Jun 28, 2012 at 22:11
  • So you would favor doing all the operations on the initial form page and not redirecting until everything is done?
    – fdsa
    Jun 28, 2012 at 22:12
  • Why do you store the data? Would storing the data still be meaningful if the next page never showed? Could the user enter the information again? Why is the thank you note on a separate page?
    – NoChance
    Jun 28, 2012 at 22:24
  • 1
    The way I like to do it is to make kind of a data-submit page that doesn't have any visible output but which on success redirects to success-page and on failure redirects to failure page. Just make sure to get your headers right. Original page --submits--> datasubmitpage --onsuccess-->successpage.
    – Pieter B
    Jun 28, 2012 at 22:27

4 Answers 4

4

The pattern for the success case:

  1. Read POST request
  2. Validate POST data
  3. Pre-process POST data
  4. Store
  5. Redirect
  6. Read GET request
  7. Display success message

And in the failure case:

  1. Read POST request
  2. Validate POST data (if fail, go to 5.)
  3. Pre-process POST data (if fail, go to 5.)
  4. Store (fails)
  5. Display error message

In your code, this structure looks somewhat like so (pseudocode, obviously):

if (is_post_request) {
    data = empty_data()
    try {
        data = read_post_data()
        validate(data)
        preprocess(data)
        store(data)
        redirect()
        exit
    }
    catch (ex) {
        display_form(data, error_message = ex)
    }
}
else {
    data = empty_data()
    display_form(data, error_message = NULL)
}

The reason you're redirecting is that you want to avoid a second database update when the user reloads. Because of this, you need to first store and then redirect. In fact, I recommend you make a habit of calling exit immediately after each redirect. There is no point in doing anything whatsoever in the current request once you've redirected (except cleanup, such as closing open file handles).

The reason you don't redirect in the error case is because nothing has been stored yet - if the user reloads, they'll just run into the same error again. If you were to redirect in the error case, you'd have to carry the error messages over the redirect, which is possible but not really pretty, and you'd have an unnecessary round trip.

3

The short answer: Make the database update before the redirect.

You should always use the get-post-redirect pattern when the user submits a form that alters application data. (Props to @WyattBarnett and @PieterB for answering in comments.) In order to work well with browsers, only GET requests should display a page to the user, and GET requests should never have side-effects like database changes, email messages, etc.

So you POST** the form to a processing script, which handles validation, writes to the database, sends emails, whatever... and redirects to another page, which will be requested with GET and will not do any of those things. It just displays stuff.

** Read about REST for an approach to http methods that goes beyond GET and POST. It's most likely not necessary for this application, though.

2
  • Thank you for your answer - would it be a bad practice to include the processing script in the original form page, and redirect through a header() to a success message?
    – fdsa
    Jun 29, 2012 at 0:45
  • @fdsa: What really matters is the pattern of requests and responses between the client and server, not which code lives in which file. You could put all of the code in one file and use $_POST and $_GET to determine which action to take or view to render. Or you could use a separate file for everything, or something in between.
    – grossvogel
    Jun 29, 2012 at 14:28
0

You could avoid redirecting, You could have the form Action field submit to the current page and have a snippet of PHP higher up on the page to watch out for the form submission, save the data and show a Thank you message then.

For example:

<?php
if($_POST['submit'] == 'Sign up')
{
// place some code here to save the details and thank the user
}
?>

<form action='sign_up.php' method='post'>
<form>
5
  • Would this cause any problems with refresh?
    – fdsa
    Jun 28, 2012 at 22:19
  • 2
    @fdsa : yes. You really want to be using get-post-redirect (en.wikipedia.org/wiki/Post/Redirect/Get) here; -1. Jun 28, 2012 at 22:58
  • +1. If the only reason to use redirect is to avoid duplicate insertions on refresh at all costs, then other means must be used, like having an unique value on a form. If, on the other hand, there is some valid reason to redirect, then I'm wondering what is this reason. Jun 29, 2012 at 8:10
  • @MainMa : why fight that battle when get-post-redirect is simple and easy? Jun 29, 2012 at 17:53
  • @Wyatt Barnett: firstly, because the perfectly valid answer was downvoted; secondly, because too many beginner programmers believe that get-post-redirect is the best (the only?) way to submit data, while it's neither the only, nor the best one. Jun 29, 2012 at 18:35
-1

Insert the data into database after an individual signs up using a post method and then redirect using header('location:whateverpage.php?message=success') and on the other page use

if(isset($_GET['message']) == 'success') {
//Show some message
}

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.