I'm working on a custom shopping cart in PHP. For several reasons, I want the checkout process to be two forms and two pageloads:

1.) Enter shipping information on first form page (click submit, next page loads)
2.) Enter billing and credit card information on second form page (click submit, order is processed, next page loads with purchase receipt)

To process the order, I need to have the information from both forms available to pass to the payment gateway. I know I could take the data from the first form and put it into hidden form fields on the second form, but I was hoping to keep it all in PHP if I could.

To put it another way: On the second form page, I want to be able to take data from the $_POST array, (which was submitted from the first form), keep it as PHP variables, and POST the data again along with the data from the second form.

Yet another analogy: I'd like to be able to "piggyback" data from PHP variables along with a user-submitted form, without the PHP variables in question ever seeing the light of day in the user's browser.

I toyed with putenv() for this but couldn't seem to make it work. Is there any way to accomplish this? It seems basic enough, but I can't find a way.

Thanks,

Matthew
Back to top

Yes, it's basic: use session variables. Sessions are stored on the server somewhere, either as files or in mysql. Each session gets a session id, unique. That's the same session ids that cause so many problems on websites and search engines.

With multipart forms you have to take extreme care to make sure that the data that you need is present. In other words, the form has to be able to withstand the back and forward button.

That's the hardest part.

But what you want is sessions.

Basically, when page 1 submits, you extract the post stuff, put it into sessions, if the sessions are not set yet. If they are set, you have to do some testing.

But basically that's it.

Every page you use session_start. It doesn't hurt to make a special session name too, that keeps the get stuff in the query string from getting ugly with the default php session name.

Example, using the session name: cart


and so on. There's an elegant way to actually create the variable names out of the post field values too, I just learned that, but it's harder to do validation on that method.

On page two you start the session like on this one, grab the session variables, if set, always check to be safe, then use those to post the whole thing when they click submit.

Make sure to destroy the session stuff at the end of the process or the forms start getting weird.



Remember, a cookie is usually how sessions recognized, but if the user has browser set to reject cookies, you need to test for that. Sessions will switch to get if no cookies are available. You can force them to only use cookies. Cookies, even if you destroy them, tend to last until the user closes their browser. This leads to odd behaviors at times, that's why I test for the actual content of the session variable rather than the presence of the session itself.

This is also how you can populate forms etc on back and forward.

As always, test to make sure your hoster supports sessions. And, as always, if they don't, get a new one.
Back to top

Doh. I knew that, really I did, but apparently I managed to get myself into an intellectual box of some sort and couldn't get out without help! <wry grin>

Thanks for straightening me out though. I've used sessions on a couple projects before for purposes about the same as this, so I don't know why I didn't think of them this time. Just a mind block I guess.
Back to top

I won't talk about that night I was building a new box and kept doing the same thing wrong, over and over again, putting 2 sticks of memory in the wrong slots and wondering why they wouldn't be 128 bit dual channel but when I put them the other way, they were. But I was dead set on the first way being the right way, so ignored the screen on the second way.

Wasn't until I posted on a hardware forum that I figured out what I was doing wrong, was very late at night.

The key thing with sessions when used like this is to make sure that if the user starts on the wrong page they get redirected to the start page, and if they've finished, all data is removed from the session. And if they go back, the session can handle it.

The sessions themselves are pretty simple, but make sure it can handle real world users doing real world things. Use many browsers when testing it so you don't always have to wipe out the cookies each test.
Back to top