Tracking information over many pages for a website

Question

Hey SO,

I have a sort of vague question that you guys are perfect for answering. I've many times come across a point where I've had a form for my user to fill out where it consisted of many different pages. So far, I've been saving them in a session, but I'm a little worried about that practice since a session could expire and it seems a rather volatile way of doing it.

I could see, for example, having a table for temporary forms in SQL that you save to at the end of each page. I could see posting all the data taken so far to the next page. Things along those lines. How do you guys do it? What's good practice for these situations?

Answer 1

Why not just pass things along in hidden parameters?

Answer 2

I would stick with keeping the data in the session as it is more or less temporary at this stage: What would you do if a user does not complete the forms? You would have to check the SQL table for uncompleted data regularly making your whole application more complex.

By the way, there is a reason for session expiring namely security. And you can define yourself when the session expires.

Answer 3

Ahh, good question.

I've found that a great way to handle this (if it's linear). The following will work especially well if you are including different content (pages) into one PHP page (MVC, for example). However, if you need to go from URL to URL, it can be difficult, because you cannot POST across a redirect (well, you can, but no browsers support it).

You can fill in the details.

$data = array();
//or//
$data = unserialize(base64_decode($_POST['data']));


// add keys to data


// serialize
$data = base64_encode(serialize($data));


<input type="hidden" name="data" value="<?= htmlspecialchars($data, ENT_QUOTES); ?>" />

Answer 4

Yes, you can definitely save the intermediate data in the database, and then flip some bit to indicate that the record is finished when the user submits the final result. Depending on how you are splitting up the data collection, each page may be creating a row in a different table (with some key tying them together).

You may also want to consider saving the data in a more free-form manner, such as XML in a single column. This will allow you to maintain complex data structures in a simple data schema, but it will make querying the data difficult (unless your database supports xml column types, which most modern enterprisey databases do).

Another advantage to storing the interim data in the database is that the user can return to it later if he wishes. Just send the user an email when he starts, with a link to his work item. Of course, you may need to add whatever security layers on top of that to make sure someone else doesn't return to his work item.

Storing the interim data in the DB also allows the user to skip around from one page to another, and revisit past pages.

Hidden fields are also a good approach, but they will not allow the user to return later.

I would avoid storing large data structures in session, since if the user doesn't invalidate the session explicitly, and if you don't have a good mechanism for cleaning up old sessions, these expired sessions may stick around for a long time.

In the end, it really depends on your specific business needs, but hopefully this gives you something to think about.