One-Page Checkout [Support Thread]

lolwaut:

You're right. I misunderstood.

Actually, now that I am fully testing this, if the gift card field is populated with anything but $0.00 and the order is submitted WITHOUT clicking the "Apply" button, Zencart actually throws an error: Your order's details have changed. Please review the current values and re-submit.

@carlwhat For this to be implemented properly, the checkout submit process would need to ignore that field. This might be more complicated than I initially thought. Does your plugin address this?
It's actually One-Page Checkout's processing that issues that message. That's because the order (upon submittal) contains that GC value, but the previous record of the order didn't. That's to 'protect' the customer (and the store) from any misleading charges.

lolwaut:

@carlwhat For this to be implemented properly, the checkout submit process would need to ignore that field. This might be more complicated than I initially thought. Does your plugin address this?Best asked in the support thread for the mod.

lat9:

That clearing of the credit-card fields, IIRC, was a PCI-compliance-related change. What I **will look into is the possibility of clearing *only the CVV number field, so that all the information doesn't need to be re-entered.***I have found that the more you leave in the forms, the easier it is for the spammers to try to get their stolen cards to work. With just the CVV, all they need do is 999 checks (9,999 for AE) to see which one works. The Zip would be 99,999 which is still doable for the hacker. Turn both off and they will probably bother someone else. And, they will spread the word that you have created a testing ground.

It's always a delicate balance between convenience and security.

I am not sure whether this is alterations I have made or if it is a bug. Still looking at it. Maybe someone can advise me :-)
The file I am looking at is modules/pages/checkout_one_confirmation/header_php.php

Line 203 reads:

                        $_SESSION['shipping']['extras'] = (isset($quote[0]['extras'])) ? $quote[0]['extras'] : '';

The problem is that for a shipping module that has not previously set 'extras' it adds a empty field to the session. Not a problem by itself but then later on we get to ln 278 or so:

$session_end_hash = $checkout_one->hashSession($currencies->format ($order->info['total']));
if ($confirmation_required === false && $order_confirmed === true && $session_end_hash !== $session_start_hash) {
    $error = true;
    $messageStack->add_session('checkout_payment', ERROR_NOJS_ORDER_CHANGED, 'error');
}

Because the session has been amended the error is added. Nothing has actually changed but the hash values will not match.

I find that this is a better version of the line:

                        if(isset($quote[0]['extras'])) $_SESSION['shipping']['extras'] = $quote[0]['extras'];

Perhaps I am missing something though? Or perhaps it is due to a fairly highly modified store. If one of the experts can chime in then that would be great.

Nick

OPC's observer class (which performs the session-hash) doesn't include $_SESSION['shipping']['extras'] as being pertinent to the hash.

lat9:

OPC's observer class (which performs the session-hash) doesn't include $_SESSION['shipping']['extras'] as being pertinent to the hash.

True.

I had read that file but somehow missed the first lines of the function. What a numpty.

niccol:

True.

I had read that file but somehow missed the first lines of the function. What a numpty.
Not a numpty! There are a lot of "moving parts" in One-Page Checkout and it's easy to miss some of the intricacies. I had to review back into the code to find that myself.

lat9:

OPC's observer class (which performs the session-hash) doesn't include $_SESSION['shipping']['extras'] as being pertinent to the hash.

But if the condition was understood correctly, on the initial run through of the hash, wasn't $_SESSION['shipping'] not set to begin with? Thus the first cycle would not have that session variable and then when checking for the change, the extras key would be removed but now the shipping session variable would be present?

I say that because of the fix that appeared to work for the OP.

mc12345678:

But if the condition was understood correctly, on the initial run through of the hash, wasn't $_SESSION['shipping'] not set to begin with? Thus the first cycle would not have that session variable and then when checking for the change, the extras key would be removed but now the shipping session variable would be present?

I say that because of the fix that appeared to work for the OP.
OPC's AJAX handler sets the session-based shipping. If the overall value isn't set, there'd be a redirect back to the main page prior to the hash.

I did some tests on the order lookup page (order_status) from OPC. I noticed that, sometimes it will show some errors.

Here are what I found:

In Chrome, open a new Incognito Windows, enter order_status URL directly (/index.php?main_page=order_status). Enter something in order number and email (no matter they are valid or not). Then click "Continue" button. It will always show "Whoops! Your session has expired./Login Time Out". This error page will be shown up by 100% chances.

Then, if I use Go Back button on the browser to go back, enter something in the order number and email then continue, "Whoops! Your session has expired." error page will be shown up again.

Then, under the same windows, if I reload the page or manually enter order_status page URL directly (/index.php?main_page=order_status). Then enter a valid order number and email, click "Continue", you will see the order details. Then if you click Go Back button on your browser, there is a chance that it will show "Confirm Form Resubmission" error. Error code is ERR_CACHE_MISS. If error message is not shown up, click Go Forward button on the browser and you will see the error.

The bottom line is, it seems to me that for order_status function needs to use Cookies or session based. If it is the customer's first time to visit this order_status page (like using a new computer), it will show expired session error. Also it is not advised to use Go Back, Go Forward buttons from the browser during this page, because sometimes it will show ERR_CACHE_MISS error.

njcyx:

I did some tests on the order lookup page (order_status) from OPC. I noticed that, sometimes it will show some errors.

Here are what I found:

In Chrome, open a new Incognito Windows, enter order_status URL directly (/index.php?main_page=order_status). Enter something in order number and email (no matter they are valid or not). Then click "Continue" button. It will always show "Whoops! Your session has expired./Login Time Out". This error page will be shown up by 100% chances.

Then, if I use Go Back button on the browser to go back, enter something in the order number and email then continue, "Whoops! Your session has expired." error page will be shown up again.

Then, under the same windows, if I reload the page or manually enter order_status page URL directly (/index.php?main_page=order_status). Then enter a valid order number and email, click "Continue", you will see the order details. Then if you click Go Back button on your browser, there is a chance that it will show "Confirm Form Resubmission" error. Error code is ERR_CACHE_MISS. If error message is not shown up, click Go Forward button on the browser and you will see the error.

The bottom line is, it seems to me that for order_status function needs to use Cookies or session based. If it is the customer's first time to visit this order_status page (like using a new computer), it will show expired session error. Also it is not advised to use Go Back, Go Forward buttons from the browser during this page, because sometimes it will show ERR_CACHE_MISS error.
I've tried to reproduce on my demo site, but I'm not seeing the issue.

Hi @lat9, thanks for your response. I suspected there is something wrong with my www & https redirect in .htaccess file, so sometimes it will cause expired session issue. I tried a different snippet code in .htaccess now and it resolved this issue.

Thanks for your help again.

One more update. Unfortunately, "Whoops! Your session has expired." issue on order_status page on my site is still there. If I opened an Incognito windows or clean my browsers' cookies, and if I directly visit the order_status page, after I submit the form, I will see the expired session note there. But if I visited any links on my site at first then visit order_status page, it will function properly.

The updated htaccess file seems to fix my Go Back & Go Forward error then.

I tried an OPC demo site and that site worked fine. So it is something wrong on my site then. Well well, another headache on my site then...

njcyx:

One more update. Unfortunately, "Whoops! Your session has expired." issue on order_status page on my site is still there. If I opened an Incognito windows or clean my browsers' cookies, and if I directly visit the order_status page, after I submit the form, I will see the expired session note there. But if I visited any links on my site at first then visit order_status page, it will function properly.

The updated htaccess file seems to fix my Go Back & Go Forward error then.

I tried an OPC demo site and that site worked fine. So it is something wrong on my site then. Well well, another headache on my site then...

2nd update. Hi @lat9, for your demo site, can you please help me to check if your admin/configuration/sessions/force cookie use is set to true or false?

My site is set to true. After I changed it to false, my order_status page works properly. If your site is set to false, you can set it to true and see if you can reproduce my issue.

I tried to search force cookie use in the forum and I could only find some very old posts. So in zc 1.57d, is it recommended to set it as true or false?

njcyx:

2nd update. Hi @lat9, for your demo site, can you please help me to check if your admin/configuration/sessions/force cookie use is set to true or false?

My site is set to true. After I changed it to false, my order_status page works properly. If your site is set to false, you can set it to true and see if you can reproduce my issue.

I tried to search force cookie use in the forum and I could only find some very old posts. So in zc 1.57d, is it recommended to set it as true or false?
I normally don't change the Configuration :: Sessions settings for my test sites, so the site's setting for Force Cookie Use is set to **False **there (the default). When I change that setting to **True **on my localhost test site, I ***do ***see the issue you identified.

Noting that it doesn't need to be incognito.

Thanks for your help! I set it to false now.

FWIW, I've opened an issue (https://github.com/lat9/one_page_checkout/issues/348) on the OPC GitHub repository to correct that unwanted behavior when the setting is 'True'.

I've just submitted v2.4.2 of One-Page Checkout for the Zen Cart moderators' review and will post back here when it's available for download (https://www.zen-cart.com/downloads.php?do=file&id=2095).

This release contains changes associated with the following GitHub issues:

#332: Guest shipping-address overwritten if billing address is changed.
#334: Disable Confirm/Review buttons until terms/privacy are agreed to.
#335: Correct 'languages_id' warning when cart's restored by "Keep Cart".
#338: Display HTML in status-history comments for all but the first, customer-entered, one.
#339: Remove extraneous language constants from ot_coupon and ot_gv overrides.
#340: Check for terms/privacy acceptance only if no previous redirect detected.
#341: Correct warnings (or PHP 8 errors) when 'credit covers' an order.
#342: Don't default guest-checkout state selections to the store's zone/state; require a selection.
#343: Correct interaction with square_webPay payment module.
#344: Convert language files to adhere to zc158 language-file naming conventions.
#345: Remove unneeded template-override language file.
#346: Document additional payment modules supported (authorizenet_cim and authorizenet_cof).
#347: PayPal Express Checkout proceeds to OPC if the cart's changed ... it shouldn't!
#348: order_status: Correct handling for stores that use Force Cookie Usage set to 'True'.

Hi @lat9, I just updated my OPC to 2.4.2 and it worked good!

I just tested my site for your issue #347 mentioned above (PayPal Express Checkout proceeds to OPC if the cart's changed ... it shouldn't!)

If I click "PayPal express checkout" in the shopping cart page, I will redirect to PayPal. Then after I entered my paypal info and redirect back to ZC, I will see the traditional 3-page checkout. The first page is to ask the shipping method, then second page is asked about payment. But in this second page, I can only see the total summary and I can leave a note for this order, but nothing else. Should I see some texts like, PayPal is selected for the payment of this order?

I disabled OPC and tried again, but I see the same content for the 2nd page. Not sure if that is correct.

Update. If I go to shopping cart and change the products quantity, then click Checkout button, I can still see the traditional 3-page checkout (not OPC, which is correct). But in the second page, I can see Payment method section here and PayPal Checkout button is selected by default.

njcyx:

Update. If I go to shopping cart and change the products quantity, then click Checkout button, I can still see the traditional 3-page checkout (not OPC, which is correct). But in the second page, I can see Payment method section here and PayPal Checkout button is selected by default.
That's how the traditional 3-page checkout works when the checkout process is started via the PayPal Express Checkout button.