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?

  • 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 '12 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 '12 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 '12 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 '12 at 22:27

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()
    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.


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.

  • 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 '12 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 '12 at 14:28

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:

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

<form action='sign_up.php' method='post'>
  • Would this cause any problems with refresh? – fdsa Jun 28 '12 at 22:19
  • 2
    @fdsa : yes. You really want to be using get-post-redirect (en.wikipedia.org/wiki/Post/Redirect/Get) here; -1. – Wyatt Barnett Jun 28 '12 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. – Arseni Mourzenko Jun 29 '12 at 8:10
  • @MainMa : why fight that battle when get-post-redirect is simple and easy? – Wyatt Barnett Jun 29 '12 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. – Arseni Mourzenko Jun 29 '12 at 18:35

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, privacy policy and cookie policy

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