One-Page Checkout [Support Thread]

I have had this plug-in on my site for sometime. I do not know what is going on. I will do a bit more digging and let you know

I've just submitted v1.3.0 of One-Page Checkout to the Zen Cart Plugins for review; I'll post back here when it's available there for download.

That release contains the changes associated with the following issues; details are present in the plugin's GitHub repository:

#64: Reduce customer confusion; submit button now reads either "Review Order" or "Confirm Order"
#87: Add configuration switch to enable/disable "Shipping=Billing" feature.
#88: Add comments around "main" blocks to make it easier for stores to re-arrange.
#89: Document the "ozPost" shipping method's interoperation.
#90: Checkout-flow standardization, for payment-method interoperability.
#91: Move payment method list that requires confirmation to a configurable setting.
#92: Update core-file overwrites for Zen Cart versions prior to 1.5.5b.
#93: Always display at least one of the submit buttons (follow-on to #64).
#94: Add checkout-alternate for no-script and/or script-error conditions.

Having an odd issue on a client's site after upgrading this plugin from 1.2.0 to the latest 1.3.0.

All displays fine but the "Confirm The Order" button is not responding, it indicates the underlying link when hovering over the button but does nothing when clicked. I checked all new files for presence in the right folder(s), no problem. Could it be just a clash of jscripts?

The module is currently only enabled to work conditionally, i.e only displays when I am logged in. Can supply site URL and my login details by PM if required. Also set up customer relevant debugging so can email log file(s).

Cheers / Frank

I installed this module for my client.
When I checkout using this module, everything works fine except it creates a log file in the logs folder

Contents of the log file (just pasting only a part of it)
2017-07-17 12:27:40 checkout_one: CHECKOUT_ONE_ENTRY, version (1.2.0 (2017-04-23)), Zen Cart version (1.5.5e), template (yabba_shop)
2017-07-17 12:27:40 checkout_one: CHECKOUT_ONE_AFTER_SHIPPING_CALCULATIONS, pass (), free_shipping (), (not set)
2017-07-17 12:27:40 checkout_one: CHECKOUT_ONE_AFTER_SHIPPING_QUOTES
array (
'id' => 'perweightunit_perweightunit',
'title' => 'Per Unit (Best Way)',
'cost' => 2.45000000000000017763568394002504646778106689453125,
'module' => 'perweightunit',
)order Object
(
[info] => Array
(
[order_status] => 1
[currency] => GBP
[currency_value] => 1.00000000
[payment_method] =>
[payment_module_code] =>
[coupon_code] =>
[shipping_method] => Per Unit (Best Way)
[shipping_module_code] => perweightunit_perweightunit
[shipping_cost] => 2.45
[subtotal] => 4
[shipping_tax] => 0
[tax] => 0
[total] => 4
[tax_groups] => Array
(
[0] => 0
)

        [comments] => 
        [ip_address] => 81.132.142.146 - 81.132.142.146
    )

[totals] => Array

Is it an error or its normal?

mani:

I installed this module for my client.
When I checkout using this module, everything works fine except it creates a log file in the logs folder
.....

Is it an error or its normal?

In Admin > Configuration > One-Page Checkout Settings, do you have "Enable One-Page Checkout Debug?" set to true? If so, just set it to "false".

frank18:

In Admin > Configuration > One-Page Checkout Settings, do you have "Enable One-Page Checkout Debug?" set to true? If so, just set it to "false".

Thank you so much!

frank18:

Having an odd issue on a client's site after upgrading this plugin from 1.2.0 to the latest 1.3.0.

All displays fine but the "Confirm The Order" button is not responding, it indicates the underlying link when hovering over the button but does nothing when clicked. I checked all new files for presence in the right folder(s), no problem. Could it be just a clash of jscripts?

The module is currently only enabled to work conditionally, i.e only displays when I am logged in. Can supply site URL and my login details by PM if required. Also set up customer relevant debugging so can email log file(s).

Cheers / Frank
Frank, check your browser's console for javascript/jQuery errors ***after ***the OPC jQuery loads. I've got some protection in there if a jQuery error was detected *prior *to the OPC load, but if there's an error afterwards ... the submit/review buttons are inoperable.

Those buttons now result in a form-submittal only via jQuery call, as part of the payment-module interoperation. If a jQuery error were registered prior to the OPC load, there would be a message on the screen notifying the customer with a link that will result in the "normal" 3-page checkout process to do its thing.

You can send me the link/credentials via PM or email; it might be sometime tomorrow betore I can take that peek.

lat9:

Frank, check your browser's console for javascript/jQuery errors ***after ***the OPC jQuery loads. I've got some protection in there if a jQuery error was detected *prior *to the OPC load, but if there's an error afterwards ... the submit/review buttons are inoperable.

Those buttons now result in a form-submittal only via jQuery call, as part of the payment-module interoperation. If a jQuery error were registered prior to the OPC load, there would be a message on the screen notifying the customer with a link that will result in the "normal" 3-page checkout process to do its thing.

You can send me the link/credentials via PM or email; it might be sometime tomorrow betore I can take that peek.

Did that, console shows no error at all. That's in Firefox, same error in Opera and Chrome.

Check PM

Cheers / Frank

Hmm, none of the jQuery events for OPC are "firing"; changes to the shipping-method don't result in the AJAX call to change the shipping cost and changes to the payment method don't cause the payment-type/submit-button display to be invoked.

What I see in the FireFox console:

setFormSubmitButton, payment-module: null  index.php:191:13
Showing "confirm"  index.php:191:13
Setting orderConfirmed (0), submitter (null)  index.php:191:13
jQuery version: 1.12.0  index.php:191:13
window.controllers is deprecated. Do not use it for UA detection.  index.php

In the Chrome console:

index.php:25 A Parser-blocking, cross site (i.e. different eTLD+1) script, https://code.jquery.com/jquery-1.12.0.min.js, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message.See https://www.chromestatus.com/feature/5718547946799104 for more details.
index.php:956 A Parser-blocking, cross site (i.e. different eTLD+1) script, https://ssl.google-analytics.com/ga.js, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message.See https://www.chromestatus.com/feature/5718547946799104 for more details.
(anonymous) @ index.php?main_page=checkout_one:956
index.php:191 setFormSubmitButton, payment-module: null
index.php:191 Showing "confirm"
index.php:191 Setting orderConfirmed (0), submitter (null)
index.php:191 jQuery version: 1.12.0

None of the OPC's jQuery events are firing. You *should *see console logs when the shipping-method and/or payment-method are changed, but I'm seeing nothing after the OPC's initial load. I'll continue investigating, but wanted to report back to let you and others know what's going on.

@frank18, it appears that the site's Google tracking script is not playing nice with OPC:

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("UA-xxxxx-1");
pageTracker._trackPageview();
} catch(err) {}</script>

More investigation required ...

lat9:

I've just submitted v1.3.0 of One-Page Checkout to the Zen Cart Plugins for review; I'll post back here when it's available there for download.

That release contains the changes associated with the following issues; details are present in the plugin's GitHub repository:

#64: Reduce customer confusion; submit button now reads either "Review Order" or "Confirm Order"
#87: Add configuration switch to enable/disable "Shipping=Billing" feature.
#88: Add comments around "main" blocks to make it easier for stores to re-arrange.
#89: Document the "ozPost" shipping method's interoperation.
#90: Checkout-flow standardization, for payment-method interoperability.
#91: Move payment method list that requires confirmation to a configurable setting.
#92: Update core-file overwrites for Zen Cart versions prior to 1.5.5b.
#93: Always display at least one of the submit buttons (follow-on to #64).
#94: Add checkout-alternate for no-script and/or script-error conditions.
v1.3.0 is now available for download from the plugins.

lat9:

@frank18, it appears that the site's Google tracking script is not playing nice with OPC:

> More investigation required ...

I replaced the Google tracking script to eliminate document.write but still have same issue.

Interesting that document.write is still used in the latest ZC 1.5.5e in includes/templates/template_default/common/html_header.php, around lines 123-124

<script type="text/javascript">window.jQuery || document.write(unescape('%3Cscript type="text/javascript" src="//code.jquery.com/jquery-1.12.0.min.js"%3E%3C/script%3E'));</script> 
<script type="text/javascript">window.jQuery || document.write(unescape('%3Cscript type="text/javascript" src="<?php echo $template->get_template_dir('.js',DIR_WS_TEMPLATE, $current_page_base,'jscript'); ?>/jquery.min.js"%3E%3C/script%3E'));</script> 

but a Google search for "alternative to document.write" returns umpteen documents stating that document.write is an outdated and even bad way to use it.

frank18:

Interesting that document.write is still used in the latest ZC 1.5.5e in includes/templates/template_default/common/html_header.php, around lines 123-124

> 
> but a Google search for "alternative to document.write" returns umpteen documents stating that document.write is an outdated and even bad way to use it.
Yes. It was still somewhat in vogue when that template was initially created.  Are you suggesting it should be ripped out during a "point release" and not wait for a "major version release"?

Keep in mind that the majority of people who have contributed templates or who google for help with pretty much any javascript-driven stuff are gonna find or use outdated methods ... and most won't have a clue how to use many of the so-called "better" methods.

Furthermore, you do realize that the code you're referring to is ONLY a catch-all in case the CORRECT loading of jquery hasn't already happened earlier. Those two script lines should NEVER trigger anything if the template is working as designed out of the box

DrByte:

Yes. It was still somewhat in vogue when that template was initially created. Are you suggesting it should be ripped out during a "point release" and not wait for a "major version release"?

Keep in mind that the majority of people who have contributed templates or who google for help with pretty much any javascript-driven stuff are gonna find or use outdated methods ... and most won't have a clue how to use many of the so-called "better" methods.

Furthermore, you do realize that the code you're referring to is ONLY a catch-all in case the CORRECT loading of jquery hasn't already happened earlier. Those two script lines should NEVER trigger anything if the template is working as designed out of the box

Thanks Doc, we are just trying to get errors with OPC fixed as per lat9's post #470.

Eliminated one possible source, namely the Google Analytics issue but still investigating the other in that post.

frank18:

I replaced the Google tracking script to eliminate document.write but still have same issue.
Thanks for trying that, Frank. I also noticed that you're using jQuery 1.12.0 while my test site was using 2.1.4; unfortunately, downleveling the jQuery version did not lead me to replication of the site's interoperability issue.

Whenever using jQuery 1.12.x or 2.2.x I always advocate to also use jQuery Migrate which helps with backwards capability; ie. JS code that needs an earlier version of jQuery to work properly. It is a shim that is most handy. Save it on your hosting account though as calling it locally is faster.

Website Rob:

Whenever using jQuery 1.12.x or 2.2.x I always advocate to also use jQuery Migrate which helps with backwards capability; ie. JS code that needs an earlier version of jQuery to work properly. It is a shim that is most handy. Save it on your hosting account though as calling it locally is faster.
Thanks, I'll keep that in mind ... although I'm not sure it applies in the current case as I'm able to checkout with OPC using either jQuery 1.12.x or 2.1.4.

lat9:

Thanks, I'll keep that in mind ... although I'm not sure it applies in the current case as I'm able to checkout with OPC using either jQuery 1.12.x or 2.1.4.

As you are someone who checks their code beforehand I'm sure your code is not the problem. :smile:

Where I found the jQuery Migrate to be very helpful is when old custom code or outdated modules are being used, which can be difficult to find / correct on errors. Not saying that is that case here either but Migrate is now a tool I use without even thinking about it.

frank18:

... we are just trying to get errors with OPC fixed as per lat9's post #470.

Eliminated one possible source, namely the Google Analytics issue but still investigating the other in that post.

Ok, problem solved.

This morning I decided to revive the local clone of this site so I could play with various scenarios including deleting files at will without interupting a live site.

Long story short, on the local clone I had a few more files for Zen Lightbox. Found out that things started to work after deleting ../jscript/jquery-1.12.0.min.js and ../jscript/jquery.min.js. A peek at the source showed the output of ../jscript/jscript_zen_lightbox.php including a call for jquery-1.11.3.min.js - and the lightbulb went off!!! Gotcha, bugger!!

So made all look the same on the live site (deleting and modifying a few files) and bingo, OPC was up and running. As I suspected from the outset, there had to be a clash of some jscripts. This was not the case when that site had OPC 1.2.0 running....