Forum Moderators: coopster
I've been working with php for a number of years now; a number of projects I've done involve multi-page forms. What I've done up to this point, I've carried inserted all post variables into sessions to carry the information forward (and backward if the user wants to re-view/revise information already input on a previous page). Then, on the last page of the multi-page "form set" I drop the information collected in my session vars into one or more db tables.
More times than not, this works fine. However (and on a recently deployed project) sometimes the db ends up with totally blank field data - comprehensive validation routines check each field for empty/invalid data when the user goes from one page to the next, so I know it's not a validation issue. Are the sessions somehow screwing things up on these rare - I hate it when stuff like this happens without any repeatable reason! - occasions? I don't have a clue. Did the user just close their browser (or did the power go off) when they were half way through the form? Maybe, but - under those circumstances, why would anything be posted to the db as the db insert happens when the user presses the "finish" button on the very last page of the form set.
I've read some posts that indicate that temp db tables would be a good alternative to sessions when dealing with data for multi-page forms... but that's been the ONLY other "persistent" solution I've come across.
So... after all of that... (and after the latest "empty-db-field" mystery) I'd like to really get opinions regarding what the good folks here consider a best-practice workflow for multiple form page persistence.
And, if anyone else has run across the same problems with blank db fields - and the reason for this - I'd love to know about it!
Great appreciation in advance!
Neophyte
More times than not, this works fine. However (and on a recently deployed project) sometimes the db ends up with totally blank field data - comprehensive validation routines check each field for empty/invalid data when the user goes from one page to the next, so I know it's not a validation issue.
It doesn't look as if you are validating your (session) data before saving it in the DB?
Is it possible that a robot is spaming the last page of your form? Any session data probably won't be set in this case.
I never thought about validating the sessions before database inclusion (does anyone else do this? Interested to hear if anyone does!).
I've also never heard of a robot spamming session data! How does this happen? are there any guards against this?
Still also interested in anyone weighing in on whether sessions are really the way to go with multi-page form data or temp db tables, or something entirely different!
Neophyte
I never thought about validating the sessions before database inclusion (does anyone else do this? Interested to hear if anyone does!).
I wasn't just referring to validating the session data, but validating the data you are about to insert into your database - wherever that might be coming from (session, cookie, flatfile, form fields...). The data that is passed to your database inclusion routine should be validated.
I've also never heard of a robot spamming session data! How does this happen? are there any guards against this?
The robot isn't specifically spamming your session data. If a robot spams your form - robots generally don't support cookies - your session data is not going to be populated. The robot could have found the URL of the last page of your form and is targeting that directly - although, it just needs to know where the form is actually being posted to.
Still also interested in anyone weighing in on whether sessions are really the way to go with multi-page form data or temp db tables, or something entirely different!
Are you referring to using temp db tables in order to store your session data (ie. session-set-save-handler() [uk2.php.net]) or somehow managing your own user sessions entirely? Creating a custom session handler (to store session data in a DB) still uses sessions and I would have thought you would need to do that or use hidden fields in your form (as idfer suggests) in order to manage your multi page forms, IMO.
If your users were logged in the I suppose you could store the form data against that user, rather than just the session? But I too would be interested in hear of any other ways to handle multi-page forms.
