Leon,
I disagree on one part of your idea, I don't think you need to worry about
giftwrap, special coupon codes, etc or anything specific that occurs in the
checkout process. I wrestled with this for a while... the simplest solution I
came up with was, and this also pertains to the SHOPPER_MUST_REGISTER deal, the
code is quite a bit of spaghetti, so I can't really submit, but it goes
something like this...
Shopper comes in to site:
Puts items in basket:
Clicks on checkout:
CREATE_INVOICE gets called,
If shopper is not logged in,
send him to login screen, but first I set a new variable, I call it
$FAILEDSCREEN, and I set it to the name of the file screen we were intending to
go to, which in this case would be either order_info or order_express, at this
point I set $SCREEN=login and return(will work in 4.01 and above), as Leon
pointed out to me, the return won't work correctly in PHP3 or should I say works
differently from this in PHP3, so you have to fall through the CREATE_INVOICE
file, but either way set the variables.
In the login file, at the top I have logic like so:
if(isset($FAILEDSCREEN)) {
print(StartForm($FAILEDSCREEN, 'post', 'LOGIN_USER', TRUE, '',
'', '',
'loginForm'));
print("<INPUT TYPE=\"hidden\" NAME=\"FAILEDSCREEN\"
VALUE=\"$FAILEDSCREEN\">\n");
}
else {
print(StartForm("contents", 'post', 'LOGIN_USER', TRUE, '', '',
'',
'loginForm'));
}
the logic above will send them to the order_info or order_express or actually it
will send them to whatever the FAILEDSCREEN variable was set to, it can be used
if they were trying to call edit_user or something similar without being logged
in, set it anywhere you require a login and send them to login, then after login
they will be sent to where there destination was originally, before they got
sidetracked at the login page...
anyway that's one part:
The part about the basket I try to do something like so:
You will enter CREATE_INVOICE, first check to see if the customer already has an
invoice(which means he probably aborted during checkout, somewhere, sometime, if
he does, destroy it, and create a new one with what is in the basket now)
at or near the bottom of the CREATE_INVOICE is where the basket is dumped, just
say no, don't dump it... from the best I can determine, there is only one thing
that can change the contents of the basket, and that is if they update the
quantities on this screen, if UPDATE_INVOICE_SKU is called, you need to dump the
basket and fill it up with what is on the invoice, and that is basically all
there is to it... when they submit the order, then and only then do you dump the
basket .... otherwise leave it alone, and all should be well...
Leon, as far as the giftwrap, coupons, I wouldn't worry about them, I tried
Amazon, I said giftwrap one of the items I had in the basket, I got to the end
right before confirm, and aborted and went back to shopping, I then went through
the process again, and the gift wrap instructions were gone, so they didn't keep
any options I selected during checkout, plus they logged me out also, I guess,
they made me enter my password again :)
Anyway, that my $.25 worth.
Kelley
Leon Atkinson wrote:
> I'll admit that this is a design idea that wasn't quite on target. Here's
> how it works now:
>
> 1. Customer puts something in their basket, which means a row is added to
> session_sku.
> 2. Customer clicks "checkout". An invoice row is created and all the rows
> in session_sku are copied to invoice_sku. All the session_sku rows are
> removed.
> 3. Customer finishes order, and as expected the items are no longer in the
> basket.
>
> But, what if the customer clicks away midway through? Well, the items no
> longer show in the basket, but when they choose to checkout again, they'll
> discover the items have reappeared on their invoice.
>
> The solution is to not move the items into the invoice until the very end of
> checkout. The one problem is that the user marks items for giftwrap or
> shipping destination in the invoice process. So, you have to account for
> that information in the session_sku table.
>
> This problem hasn't been addressed in FT 2, BTW. Let's remember that we
> need to do so.
>
> Leon
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Site: http://www.working-dogs.com/freetrade/
Problems?: [EMAIL PROTECTED]
