Sure, send them on. If you'll install "Display Logs" so that I can 'see' what's going on, I'll only need admin-login credentials.Quote:
Originally Posted by mprough
Printable View
Sure, send them on. If you'll install "Display Logs" so that I can 'see' what's going on, I'll only need admin-login credentials.Quote:
Originally Posted by mprough
The checkout-loop that @mprough reported in post #1693 above was due to the changes made in #1692, which applied the id="OPC" to all order-totals, causing OPC's jQuery to pick up the value of the order's sub-total instead of the total.Quote:
Originally Posted by lat9
That discrepancy was the cause of the checkout-loop. Here's the correction for the Bootstrap template's /templates/tpl_modules_order_total.php:
If you're using that, you'll also need to change the OPC's order-total selector's configuration as identified in post #1692 above!Code:<?php
/**
* Module Template
*
* BOOTSTRAP v1.0.BETA
*
* @package templateSystem
* @copyright Copyright 2003-2005 Zen Cart Development Team
* @copyright Portions Copyright 2003 osCommerce
* @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
* @version $Id: tpl_modules_order_totals.php 2993 2006-02-08 07:14:52Z birdbrain $
*/
?>
<?php
/**
* Displays order-totals modules' output
*/
for ($i=0; $i<$size; $i++) { ?>
<?php
//-20200718-lat9-Only apply the id="OPC" for the order's total
$value_parameter = ($GLOBALS[$class]->code == 'ot_total') ? ' id="OPC"' : '';
?>
<tr id="<?php echo str_replace('_', '', $GLOBALS[$class]->code); ?>">
<td colspan="2" class="text-right">
<?php echo $GLOBALS[$class]->output[$i]['title']; ?>
</td>
<td class="text-left"<?php echo $value_parameter; ?>>
<?php echo $GLOBALS[$class]->output[$i]['text']; ?>
</td>
</tr>
<?php } ?>
I see 160 odd pages of discussion, can you narrow it down for ae a little bit? is there a link to the answer ?
I've identified Melanie's two posts by their post numbers which appear in the respective post's date/time header, to the right.Quote:
Originally Posted by johnniejetski2
I have an odd issue and trouble tracking it down.
OPC 2.1.4
Zen Cart 1.5.6c
The order confirmation emails for guest checkout have the billing and shipping address as a single line of text (https://prnt.sc/tczh24). Regular account order confirmation emails appear correctly with each line of the address on it's own line.
I'm having trouble tracking down where this issue might be coming from. I've been tracking down $email_text in /includes/classes/observers/class.checkout_one_observer.php
but not having any luck solving this.
Jim, there have been 86 commits (i.e. code changes) since OPC v2.1.4 was released last September. The various releases are documented here: https://github.com/lat9/one_page_checkout/releases.Quote:
Originally Posted by jeking
You might try applying the change documented here: https://github.com/lat9/one_page_che...af4be9e4aca26e
ZCv1.56c
OPCv2.3.2 (pretty sure still applies in OPC v2.3.3)
A code change request - I think I've got this right.
In the various customer address blocks - store side, the placeholder alert asterisk (ENTRY_STATE_TEXT) is placed inside the state field when it is not a dropdown:
tpl_modules_checkout_new_address.php
tpl_modules_address_book_details.phpCode:echo zen_draw_input_field('state', '', zen_set_field_length(TABLE_ADDRESS_BOOK, 'entry_state', '40') . ' id="state" placeholder="' . ENTRY_STATE_TEXT . '"');
not so in tpl_modules_opc_address_block.phpCode:echo zen_draw_input_field('state', zen_get_zone_name($entry->fields['entry_country_id'], $entry->fields['entry_zone_id'], $entry->fields['entry_state']), zen_set_field_length(TABLE_ADDRESS_BOOK, 'entry_state', '40') . ' id="state" placeholder="' . ENTRY_STATE_TEXT . '"');
The placeholder is outside of the state field, I think it could do with being inside it. I've dabbled but can't seem to add the placeholder after the state_field_id without breaking it.Code:echo zen_draw_input_field($state_field_name, $address['state'], zen_set_field_length(TABLE_ADDRESS_BOOK, 'entry_state', '40') . " id=\"$state_field_id\"");
if (zen_not_null(ENTRY_STATE_TEXT)) {
echo '<span class="alert">' . ENTRY_STATE_TEXT . '</span>';
}
Edit: forgot to include tpl_modules_create_account.php in my examples
I feel stupid asking this... but what file is missing when the checkout page only displays stuff like the following instead of the actual text. I have triple checked the install - concentrating on the /english files - and everything looks fine to me.......
Home :: NAVBAR_TITLE_1 :: NAVBAR_TITLE_2
HEADING_TITLE
TEXT_CHECKOUT_ONE_TOP_INSTRUCTIONS
TITLE_BILLING_SHIPPING_ADDRESS
Using latest 1.3.3 and this shows on
https://xxxxxxxxxxxxxx.com/catalog/i...e=checkout_one
Look for /includes/languages/english/checkout_one.php; check your template's language-override (/includes/languages/english/YOUR_TEMPLATE/checkout_one.php).Quote:
Originally Posted by stellarweb
THANKS!!!! That worked! I triple checked that and missed it each time! lolQuote:
Originally Posted by lat9
On a new 1.5.7 site, when I checkout - PPExpress - after I get to the paypal side and confirm, I get the dreaded Warning an error occurred please refresh etc etc
I also get it what going to customers/orders. Here is the error log if someone can help
HTML Code:[20-Jul-2020 23:55:12 UTC] Request URI: /catalog/2020/index.php?cmd=orders, IP address: 162.72.107.178
#1 trigger_error() called at [/home/afamblck/public_html/catalog/includes/classes/db/mysql/query_factory.php:170]
#2 queryFactory->show_error() called at [/home/afamblck/public_html/catalog/includes/classes/db/mysql/query_factory.php:142]
#3 queryFactory->set_error() called at [/home/afamblck/public_html/catalog/includes/classes/db/mysql/query_factory.php:269]
#4 queryFactory->Execute() called at [/home/afamblck/public_html/catalog/2020/includes/classes/observers/OnePageCheckoutAdminObserver.php:58]
#5 OnePageCheckoutAdminObserver->update() called at [/home/afamblck/public_html/catalog/includes/classes/class.base.php:118]
#6 base->notify() called at [/home/afamblck/public_html/catalog/2020/orders.php:1253]
#7 require(/home/afamblck/public_html/catalog/2020/orders.php) called at [/home/afamblck/public_html/catalog/2020/index.php:11]
--> PHP Fatal error: 1054:Unknown column 'is_guest_order' in 'field list' :: SELECT is_guest_order
FROM zen_orders
WHERE orders_id = 4581
LIMIT 1 ==> (as called by) /home/afamblck/public_html/catalog/2020/includes/classes/observers/OnePageCheckoutAdminObserver.php on line 58 <== in /home/afamblck/public_html/catalog/includes/classes/db/mysql/query_factory.php on line 170.
You've somehow caused OPC's admin initialization scripts to not run; the orders::is_guest_order field has been in use by OPC since v2.0.0. What version of OPC is in effect on the zc157 site?Quote:
Originally Posted by stellarweb
This did the trick. Thank you for pointing it out! :smile:Quote:
Originally Posted by lat9
It is the latest one you posted a week or so ago - I think 1.3.3
Fresh install or upgrade?Quote:
Originally Posted by stellarweb
Fresh installQuote:
Originally Posted by lat9
I've no idea what you've done, but for zc157 OPC's (other than a couple of CSS files and a minor change to the information side-box) a drop-in install. The admin installation should have added that element to the orders table, just like it adds its configuration settings to the configuration table.Quote:
Originally Posted by stellarweb
Were/are there any admin-related debug-logs?
Leave it to me to screw up a simple process!!!!
I THINK what I posted was an admin log - I get a reegular log error and the adm one and the both look much the same. I am posting the NON adm error log here - there are some subtle differences.
Would it help to reinstall the admin files?
Here is the code:
HTML Code:[21-Jul-2020 00:01:42 UTC] Request URI: /catalog/index.php?main_page=checkout_process, IP address: 162.72.107.178
#1 trigger_error() called at [/home/afamblck/public_html/catalog/includes/classes/db/mysql/query_factory.php:170]
#2 queryFactory->show_error() called at [/home/afamblck/public_html/catalog/includes/classes/db/mysql/query_factory.php:142]
#3 queryFactory->set_error() called at [/home/afamblck/public_html/catalog/includes/classes/db/mysql/query_factory.php:269]
#4 queryFactory->Execute() called at [/home/afamblck/public_html/catalog/includes/classes/observers/CheckoutOneEmailObserver.php:62]
#5 CheckoutOneEmailObserver->update() called at [/home/afamblck/public_html/catalog/includes/classes/class.base.php:118]
#6 base->notify() called at [/home/afamblck/public_html/catalog/includes/functions/functions_osh_update.php:89]
#7 zen_update_orders_history() called at [/home/afamblck/public_html/catalog/includes/modules/payment/paypalwpp.php:501]
#8 paypalwpp->after_process() called at [/home/afamblck/public_html/catalog/includes/classes/payment.php:261]
#9 payment->after_process() called at [/home/afamblck/public_html/catalog/includes/modules/pages/checkout_process/header_php.php:17]
#10 require(/home/afamblck/public_html/catalog/includes/modules/pages/checkout_process/header_php.php) called at [/home/afamblck/public_html/catalog/index.php:35]
--> PHP Fatal error: 1054:Unknown column 'is_guest_order' in 'field list' :: SELECT is_guest_order
FROM zen_orders
WHERE orders_id = 4582
LIMIT 1 ==> (as called by) /home/afamblck/public_html/catalog/includes/classes/observers/CheckoutOneEmailObserver.php on line 62 <== in /home/afamblck/public_html/catalog/includes/classes/db/mysql/query_factory.php on line 170.
Quote:
Originally Posted by lat9
I just re-uploaded the admin files. OPC is turned to FALSE. I go to the orders page - which is blank with the error and get the following adm file
Also -this is a pretty "vanilla" site with only a couple of mods.
HTML Code:[22-Jul-2020 17:23:24 UTC] Request URI: /catalog/2020/index.php?cmd=orders, IP address: 162.72.107.178
#1 trigger_error() called at [/home/afamblck/public_html/catalog/includes/classes/db/mysql/query_factory.php:170]
#2 queryFactory->show_error() called at [/home/afamblck/public_html/catalog/includes/classes/db/mysql/query_factory.php:142]
#3 queryFactory->set_error() called at [/home/afamblck/public_html/catalog/includes/classes/db/mysql/query_factory.php:269]
#4 queryFactory->Execute() called at [/home/afamblck/public_html/catalog/2020/includes/classes/observers/OnePageCheckoutAdminObserver.php:58]
#5 OnePageCheckoutAdminObserver->update() called at [/home/afamblck/public_html/catalog/includes/classes/class.base.php:118]
#6 base->notify() called at [/home/afamblck/public_html/catalog/2020/orders.php:1253]
#7 require(/home/afamblck/public_html/catalog/2020/orders.php) called at [/home/afamblck/public_html/catalog/2020/index.php:11]
--> PHP Fatal error: 1054:Unknown column 'is_guest_order' in 'field list' :: SELECT is_guest_order
FROM zen_orders
WHERE orders_id = 4582
LIMIT 1 ==> (as called by) /home/afamblck/public_html/catalog/2020/includes/classes/observers/OnePageCheckoutAdminObserver.php on line 58 <== in /home/afamblck/public_html/catalog/includes/classes/db/mysql/query_factory.php on line 170.
Somehow, part of OPC's installation didn't run. You need to run the database uninstall.sql provided in the plugin's /docs sub-directory. Then those missing database elements will be re-added on an admin-page refresh.Quote:
Originally Posted by stellarweb
Quote:
Originally Posted by lat9
YOU DA BOSS, Girl!!!!!! That worked!!! Thank you SO MUCH for sticking with me until this was resolved!
No problems, happy to have helped. The real question, though, is why that database installation didn't "take" initially.Quote:
Originally Posted by stellarweb
Update: Remember, too, to change that OPC totals' selector in the admin configuration.
I don't know - I installed it correctly, so don't know why the orders page and the checkout was affected.Quote:
Originally Posted by lat9
What do you mean about changing the OPC total's selector? Right now it says #ottotal > div:first-child
I thought that your site's Bootstrap template's tpl_modules_order_total.php had been updated to use #OPC as the selector for the order's total. Check the code before making changes.Quote:
Originally Posted by stellarweb
I've discovered that this module doesn't work when EC Analytics is installed (https://www.zen-cart.com/downloads.php?do=file&id=1997)
I am just presented with the regular multiple page checkout.
Is this something you're aware of, and is there a solution other than switching to a different analytics module?
I've not seen that before. Are there console logs generated? Debug-logs?Quote:
Originally Posted by strelitzia
No debug logs, or console logs.Quote:
Originally Posted by lat9
EC Analytics is as per zc download apart from the following change after adding an admin configuration page for setting the GA number and a switch to enable/disable the module.
In includes/templates/YOUR_TEMPLATE/jscript/jscript_ec_analytics.php i replaced
if ((!defined('GOOGLE_UA') || GOOGLE_UA === "UA-XXXXXXXX-X")) {
echo '<script>alert("The Google Analytics trackingID is not yet defined in\n /includes/extra_datafiles/ec_analytics.php")</script>' ;
} else { $trackingID = GOOGLE_UA ; }
?>
with
if (GOOGLE_ANALYTICS_ENABLE == 'true'){
if ((!defined('GOOGLE_UA') || GOOGLE_UA === "UA-XXXXXXXX-X")) {
echo '<script>alert("The Google Analytics trackingID is not yet defined in Admin > Configuration > EC Analytics Configuration")</script>' ;
} else { $trackingID = GOOGLE_UA ; }
?>
so that the warning message wasn't displayed if the module wasn't active.
Site is ZC 1.5.7, latest version of OPC, and last available update of EC Analytics apart from the edit mentioned above.
I did some digging around here and it seems to be related to 'NOTIFY_HEADER_START_CHECKOUT_SHIPPING', on line 26 of includes/classes/observers/class.ec_analytics.php, meaning that commenting out that line allows OPC to load correctly upon checkout. Obviously this is going to have some negative impact on the functionality of EC Analytics though.
I assume it's somehow messing with whatever part of your code calls checkout_one rather than checkout_shipping
Does that help at all?
I just looked at the auto_loaders file for both OPC and ECA
ECA is using $autoLoadConfig[90] whereas OPC is mainly using $autoLoadConfig[200]
I took a wild guess that perhaps ECA being loaded earlier than OPC was causing an issue so as a test I changed ECA to $autoLoadConfig[200] as well.
The issue went away, but not sure of the ramifications of changing the loading order like this.
Is it likely to cause issues for ECA, or should I perhaps change OPC to load earlier?
What do you advise Cindy?
You didn't indicate in your original posting, @strelitzia, but are you, by chance running zc157?Quote:
Originally Posted by strelitzia
If that's the case, there's a bug in the zc157 core, identified by @mc12345678 (https://github.com/zencart/zencart/pull/3654), that prevents multiple observers from watching the same event.
Hi,
I wonder if it is a simple matter to incorporate the action of the rather nice gift wrapping module in OPC?
The module presents a set of options for gift wrapping surcharge at checkout.
Gift Wrapping module:
https://www.zen-cart.com/downloads.php?do=file&id=267
That Gift Wrapping module touches too many core-files and provides a non-standard (i.e. displayed on checkout_shipping rather than checkout_payment) order-total. The concept is good, but will need some re-thinking for an integration with OPC.Quote:
Originally Posted by gernot
OK, got it. No point in me messing around with that then for now!
Yes, I am running 157. I forgot to mention that in the original post, but added it to the bottom of post #1727Quote:
Originally Posted by lat9
I'll check out that bug on git.
Thanks
I see that now! Thanks, BTW, for the detailed investigation ... it helped to provide the solution to the issue!Quote:
Originally Posted by strelitzia
Silly question, but would it be easy to configure an auto-refresh when a checkbox is clicked INSTEAD of the apply button?
We have an Optional Shipping Insurance module installed. On the one page checkout, we fear that a customer will click the checkbox, but overlook the "Apply" button. It would be so much easier if the ajax form would auto-regresh when selected (kind of like what happens when you select a different shipping option).
Perhaps you can tell me what I would have to add to which file to make the checkbox (or all checkboxes) on the checkout page auto-refresh the total so that we can get rid of the additional "Apply" button? That would also save the customer an extra "click" by having this functionality.
Checkbox-handling on page transitions is notoriously finicky due to the transitional nature of those inputs.Quote:
Originally Posted by Jeff_Mash
One-Page Checkout's jQuery for the checkout_one page performs an auto-submit (non-confirmation) when a page element with a class of opc-cc-submit is clicked. That said, you could try adding that class to the optional insurance order-total's checkbox.
Awesome, thanks for pointing me in the right direction. I just added the class="opc-cc-submit" to that optional insurance block and it seems to work.Quote:
Originally Posted by lat9
There is still a little problem that I have, and hopefully you can help.
When looking at the One Page Checkout screen, the "Optional Insurance" is displayed first (before selecting the Payment). What happens is that now, when a customer clicks the box to apply the Insurance, it does the auto-submit (non-confirmation)......but because no default payment method is selected, we get the automatic message that says you need to select a payment first.......so the Optional Insurance isn't applied.
Since we only have two payment options (Paypal or Check/Money Order), 99.99% of our customers are going to select the PayPal option. Can we modify the one-page checkout to have that option auto-selected so that the error can be eliminated when the Insurance is applied?
If not, then is there a way to display the Optional Insurance block BELOW the payment options so that a customer doesn't apply it before they select their payment?
Sure, you can create a little addition to the checkout_one page's processing. Create the file /includes/modules/pages/checkout_one/header_php_paypal_default.php containing:Quote:
Originally Posted by Jeff_Mash
If you're using PayPal Payments Pro, just change that paypalwpp to paypaldp.PHP Code:<?php
if (empty($_SESSION['payment'])) {
$_SESSION['payment'] = 'paypalwpp';
}
Thanks! That works great! I think we are almost there, but we are inadvertently causing another side effect by doing this.Quote:
Originally Posted by lat9
Where we now stand:
1. Customer comes to the One Page Checkout screen. Payment is now auto-selected thanks to your recommendation above. This is GOOD.
2. Customer checks the Optional Insurance box. This automatically refreshes the page now, and updates the total at the bottom of the page. Also GOOD!
However, after the auto-refresh which applies the insurance to the total, the page reloads WITHOUT the Optional Insurance box checked. (The order total does reflect the Optional Insurance added, it's just that the checkbox is not showing it being selected).
So now what happens is that when I click the Confirm Order button, it doesn't confirm the order. Instead, it refreshes the page REMOVING the Optional Insurance (because it wasn't checked) and updates the order total without the insurance.
So Problem #1: What do I need to set to keep the checkbox checked? I assume it's setting that Session variable in someway.
And Problem #2: Will solving #1 above cause the order to be Confirmed on the first click of the button?
To keep that checkbox checked, you'll need to modify that optional insurance order-total so that it records the check when clicked (or unclicked) into the session, as you indicated, and also to initialize the checkbox based on that session value (if present).
Ok cool.....I just did that in the ot_insurance module and got it working!Quote:
Originally Posted by lat9
Final question (I promise)! It looks like your One Page module is the one putting the "Apply" button next to these other modules, which makes total sense because it's designed to have the user "click to apply" their settings.
But since I modified the Insurance module to "auto-submit" upon checking the box, I no longer need the "Apply" button next to it (since it's auto-applied based on our changes).
How can I remove that Apply button from being displayed on the ot_insurance section of the checkout page? (Would it just be an if/else statement added to your function submitonce() in your checkout_one.js file)?
You can "hide" that button via CSS. Just update your template's version of /css/checkout_one.css and add something akin toQuote:
Originally Posted by Jeff_Mash
Just use your browser's 'element inspector' and make sure that the id= attribute on the ot_insurance input matches the value above.Code:#disc-ot_insurance+div.buttonRow { display: none; }
Thank you so much for all your help! That works PERFECTLY!!Quote:
Originally Posted by lat9
Just to document what I did (for anyone else wanting to accomplish the same), I made two changes to the code.
1. Since your template is the one that adds the Apply button on the checkout page, I modified the tpl_opc_credit_selections.php to assign a unique class name to ONLY the insurance block.
I changed this (line 54):
And replaced it with this:Code:<div class="buttonRow forward"><?php echo zen_image_button(BUTTON_IMAGE_SUBMIT, ALT_TEXT_APPLY_DEDUCTION, $additional_parms, $secondary_class); ?></div>
There is probably a better (and prettier) way to accomplish that, but I'm not a native PHP programmer. :)Code:<?php
if(strpos($current_selection['module'],"Shipping Insurance") !== false){
?>
<div class="buttonRow forward ot-insurance"><?php echo zen_image_button(BUTTON_IMAGE_SUBMIT, ALT_TEXT_APPLY_DEDUCTION, $additional_parms, $secondary_class); ?></div>
<?php
}
else {
?>
<div class="buttonRow forward"><?php echo zen_image_button(BUTTON_IMAGE_SUBMIT, ALT_TEXT_APPLY_DEDUCTION, $additional_parms, $secondary_class); ?></div>
<?php
}
?>
2. Finally, I simply edited your checkout_one.css file to add the following line:
Those changes (along with the previous posts of ours) made the module work exactly as we wanted! The customer can now click to apply insurance, it will update the form totals automatically, and the now-redundant "Apply" button has been removed from that Insurance block (without removing it from others like Coupons and Gift Certificates, etc).Code:.ot-insurance { display: none; }
Thanks again for all your help, Lat9!
I think I have a bug =(
So when you change the shipping/billing address in checkout the only button there is cancel, "save changes" doesn't appear until you click the box which cannot be seen
Zen Cart 1.5.5f
OPC 2.3.3 (2020-07-07)
~Melanie
Which bootstrap template is in use? Have you checked to see that any of the template's overrides of the OPC templates is 'current'?Quote:
Originally Posted by mprough
I'll note that the site's pulling in a woefully old v2.1.1 of jQuery, don't know if that has play in the issue or not.
Noting, too, that the Save Changes button appears when you exit the changed field.
Updated jQuery, no help. Bootstrap Version: 1.0.5 08 July 2018.Quote:
Originally Posted by lat9
Not to be dense, but I don't understand this LOLQuote:
Have you checked to see that any of the template's overrides of the OPC templates is 'current'?
For that last bit, I was suggesting that you file-compare the /templates/bootstrap/templates against templates/template_default/templates to ensure that any template-overrides for the OPC templates have all the current changes.
I have done so.... did a full install of OPC instead of picking through itQuote:
Originally Posted by lat9
Correct, but rarely do people click outside of the field... the simply need to be able to click save without having to unselect the last edited field. People can't use this like this... I showed it to 5 people and 4 of them couldn't figure out how to save the infoQuote:
Originally Posted by lat9
fresh install zen 1.57 on php 5.64 temporarily until upgraded to 7.3 added Database Backup
After my square was setup I then enable one page checkout ver 2.3.3 (2020-07-07) and place items into a cart and select credit card for payment the cc fields are not displayed for entering data. When one page checkout settings are false my cc fields display correctly.Attachment 19167
Last lines of the read.me for Square.
Have you copied the `jscript_square.php` file from `/includes/modules/pages/checkout_payment/` into the `/includes/modules/pages/checkout_one/` folder?
I've just submitted v2.3.4 of One-Page Checkout for the Zen Cart moderators' review; I'll post back here when it's available for download.
This release contains changes associated with the following GitHub issues:
#268: Enable "Save/Cancel" buttons on input-focus instead of change.
#269: Provide update scripts to ensure that guest address records are unmodified.
See also this additional documentation regarding the usage of /YOUR_ADMIN/opc_admin.php. That script, added for v2.3.4, provides fix-ups for OPC's guest billing and shipping addresses as there's the possibility that the addresses were overwritten by earlier versions of OPC's guest-handling.
Now available for download: https://www.zen-cart.com/downloads.php?do=file&id=2095Quote:
Originally Posted by lat9
Hi, I did a fresh install of ZC 1.5.7 along with One-Page checkout version 2.3.4. All seems to be working fine but there is one thing I wish I could resolve. when users checkout as guest, the customer information aren't recorded in customers. instead only "Customer, **do not remove**" appears with whatever number of entries. The customer information is only found in the orders
Is there away to force it to record this name and email addresses. Why do I need it to do so?
We are using a hosted pay page which redirects back to the site after a payment is issued/deducted. If the browser fails to redirect or session timeout in between, there is no order number issues. So if I see a name registered an email address, it clues me in to check whether the fee was collected and nor order issues so that I can issue a refund immediately.
I use that functionality to determine whether a user tried to pay and or some reason their session timedout
For a guest-checkout, there's no individual customer record or address-book entries recorded ... it's a guest-checkout, after all. What payment method is in use on the site?Quote:
Originally Posted by riomaha
I am using moneris hosted pay page. The module does not insert customer information until a the transaction is approved. If declined or canceled it is not recorded.
If you turn the Moneris debug on, the resulting .log files will contain the information you seek.Quote:
Originally Posted by riomaha
Out of curiosity, is there still an issue with Guest Checkout for virtual products? I am trying to work-around the reality of our customers buying a digital download that we sell, but using the guest checkout feature. Since they are purchasing it without an account, it would seem like there is no way to give them the access to the file.
If that's the case, do you know of anyway to PREVENT a customer from checking out as guest *IF* they have any virtual items in their cart? Perhaps a way to disable guest checkout if they have any products from Category XYZ (where XYZ equals the product category we have for digital items)?
Guest checkout order reviews are via the 'orders_status' page, as reflected in guest-checkout orders' emails.Quote:
Originally Posted by Jeff_Mash
One thought came to me but it requires lots of digging unless someone already knows where and what. In one page checkout there is the function that "updates". The function could serve a double purpose to register customer or pre order before confirming the order. or event at the confirm order. Unfortunately, time is something i don't have right now to fiddle with it.
R
I looked through the code and it seems there isn't a single insert statement or update in the guest checkout, customer info, or confirm order. On the other hand, I found a statement that updates the address or resets it but still no insert statement and yes I looked in the tpl files.
Within OPC, the primary elements that control the database manipulations are the OnePageCheckout.php and ajax/zcAjaxOnePageCheckout.php classe-files.
Hi Lat9 - I'm not sure if this is a bug or not, but I wanted to report it here.
Do you know of any issues with a customer using your module with a NEGATIVE order total?
Here is what I am seeing.
Customer goes to buy something in our store for $80.25.
We have the Reward Points module, so customer has 81 reward points to apply towards the order. 1 point = $1.00.
Orders new total is -$0.25.
When the Confirm Order button is hit, you are simply taken back to the main checkout_one page.
If you think there is a problem with submitting negative orders, perhaps we can adjust the module so that if order total < 0, than order total = 0.
See this (https://www.zen-cart.com/showthread....34#post1329034) link that identifies some tweaks (as identified in the OPC readme) to enable the Reward Points' integration.
Yeah I tried that but no luck. Is there an area in your module code that I should look for in order to initialize the order total back to zero *IF* the value is a negative number? I was looking in the jquery.checkout_one.js file but didn't see where to change it (even just to test if that would fix the problem).
I'll come up with a set of instructions that you (and others!) can use to determine what's causing that 'kick-back' from the confirmation page back to the data-collecting one.Quote:
Originally Posted by Jeff_Mash
It's normally some session value that's different between the session-state on entry to the confirmation page and that 'state' after going through the order's final checks (i.e. interrogating the shipping, payment and order-total modules).
Jeff, after actually reading your post (I was seeing that the Reward Points' contribution to the order was a negative value), I'll need to review whether OPC 'cares' that the order's value is negative.
I think that would be an EXCELLENT addition to your already excellent module! Can't wait to see it and try it out.Quote:
Originally Posted by lat9
Okay, I will wait to hear back from you. I just assumed it was your module spitting it back because it isn't liking "something" from the values being submitted to it. I did confirm that the issue (regardless of which module is causing it) is definitely with the negative value. If I submit the order without a negative value, it goes through the OPC confirmation just fine.Quote:
Originally Posted by lat9
Granted, the situation I describe isn't very common (but does happen from time to time). Since reward points are always in whole round numbers, they usually will create some kind of negative order_total when applied fully to an order. And normal non-OPC checkout handles it fine........meaning the order gets submitted with a negative number. If I can help test anything out for you, please let me know.
Jeff, see your Private Messages.
ZC v1.57
PHP v7.2.10
OPC v2.3.4
CEON
DPU
SBA
Quantity Discounts
CSS_JS Loader
IH5
Colorbox
Structured Data
Upgraded an existing ZC v1.56c site to ZC v1.57 and I'm have difficulty debugging this issue:
Checking out as a guest I'm successfully directed to the OPC checkout_one page and all's well. But checking out as a logged in customer I'm taken to Step 1 (checkout_shipping) page - it's as if OPC is not kicking in (unlike in ZC v1.56c w/OPC v2.3.4). There are no errors in the browser console (I'm not loading OPC minified script files) or logs directory.
Any ideas where I would start looking?
Simon, have you applied all the zc157 bugfixes? Does OPC generate a customer-specific log for the situation?
Yes it just occurred to me to check the ZC v157 bug fixes, I thought I could get away with waiting until ZC v1.57a was released. I'll apply those, try again and then post a customer log if neccessary - thank you. In the meantime the customer log generated in this instance is:Quote:
Originally Posted by lat9
Code:2020-09-28 16:16:24 OnePageCheckout: updateOrderAddresses, on entry:order::__set_state(array(
'orderId' => NULL,
'info' =>
array (
'order_status' => '1',
'currency' => 'GBP',
'currency_value' => '1.000000',
'payment_method' => '',
'payment_module_code' => '',
'coupon_code' => '',
'shipping_method' => 'Standard Delivery (No Charge)',
'shipping_module_code' => 'flat_flat',
'shipping_cost' => 0,
'subtotal' => 0,
'shipping_tax' => 0,
'tax' => 0,
'total' => 0,
'tax_groups' =>
array (
),
'comments' => '',
'ip_address' => '127.0.0.1 - 127.0.0.1',
),
'totals' =>
array (
),
'products' =>
array (
),
'customer' =>
array (
'firstname' => 'Simon',
'lastname' => '[hidden]',
'company' => NULL,
'street_address' => '[hidden]',
'suburb' => '',
'city' => '[hidden]',
'postcode' => '[hidden]',
'state' => '[hidden]',
'state_code' => NULL,
'zone_id' => '0',
'country' =>
array (
'id' => '222',
'title' => 'United Kingdom',
'iso_code_2' => 'GB',
'iso_code_3' => 'GBR',
),
'format_id' => 8,
'telephone' => '[hidden]',
'email_address' => '[hidden]',
),
'delivery' =>
array (
'firstname' => 'Simon',
'lastname' => '[hidden]',
'company' => NULL,
'street_address' => '[hidden]',
'suburb' => '',
'city' => '[hidden]',
'postcode' => '[hidden]',
'state' => '[hidden]',
'state_code' => NULL,
'zone_id' => '0',
'country' =>
array (
'id' => '222',
'title' => 'United Kingdom',
'iso_code_2' => 'GB',
'iso_code_3' => 'GBR',
),
'country_id' => '222',
'format_id' => 8,
),
'billing' => NULL,
'content_type' => 'physical',
'email_low_stock' => NULL,
'products_ordered_attributes' => NULL,
'products_ordered' => NULL,
'products_ordered_email' => NULL,
'products_ordered_html' => NULL,
'attachArray' => NULL,
'email_order_message' => NULL,
'extra_header_text' => NULL,
'doStockDecrement' => NULL,
'send_low_stock_emails' => NULL,
'queryReturnFlag' => NULL,
'bestSellersUpdate' => NULL,
'use_external_tax_handler_only' => NULL,
'products_ordered_attributes_html' =>
array (
),
'observerAliases' =>
array (
'NOTIFIY_ORDER_CART_SUBTOTAL_CALCULATE' => 'NOTIFY_ORDER_CART_SUBTOTAL_CALCULATE',
),
))OnePageCheckout::__set_state(array(
'isGuestCheckoutEnabled' => true,
'registeredAccounts' => false,
'guestIsActive' => false,
'isEnabled' => true,
'tempAddressValues' => NULL,
'guestCustomerInfo' => NULL,
'guestCustomerId' => 51,
'tempBilltoAddressBookId' => 68,
'tempSendtoAddressBookId' => 69,
'dbStringType' => 'stringIgnoreNull',
'customerInfoOk' => NULL,
'billtoTempAddrOk' => NULL,
'sendtoTempAddrOk' => NULL,
'isVirtualOrder' => NULL,
'billtoAddressChangeable' => NULL,
'sendtoAddressChangeable' => NULL,
'observerAliases' =>
array (
'NOTIFIY_ORDER_CART_SUBTOTAL_CALCULATE' => 'NOTIFY_ORDER_CART_SUBTOTAL_CALCULATE',
),
))
2020-09-28 16:16:24 OnePageCheckout: Current sendto: 107
2020-09-28 16:16:24 OnePageCheckout: updateOrderAddresses, , , 222, 0
{"firstname":"Simon","lastname":"[hidden]","company":null,"street_address":"[hidden]","suburb":"","city":"[hidden]","postcode":"[hidden]","state":"[hidden]","state_code":null,"zone_id":"0","country":{"id":"222","title":"United Kingdom","iso_code_2":"GB","iso_code_3":"GBR"},"format_id":8,"telephone":"[hidden]","email_address":"[hidden]"}
null
{"firstname":"Simon","lastname":"[hidden]","company":null,"street_address":"[hidden]","suburb":"","city":"[hidden]","postcode":"[hidden]","state":"[hidden]","state_code":null,"zone_id":"0","country":{"id":"222","title":"United Kingdom","iso_code_2":"GB","iso_code_3":"GBR"},"country_id":"222","format_id":8}
The bug-fix that most likely is "getting you" is in post#8 of that bugfix thread (https://www.zen-cart.com/showthread....v1-5-7-series).
This was the bugfix that needed to be applied - Re: 157: plugins watching shared notifiers may not all trigger properly , I should have paid more attention to that thread.
Hello,
I am finally finding time to work further on trying to add support for Japanese (some issues with zones, as well as adding language and hiragana fields) to OPC.
I have had to disable OPC because while it worked beautifully for guest checkout and registrations, it gave an error when trying to add addresses, since my shop's user creation and address book registration/changing code has been modified to support the needs of users here in Japan (selecting a language for the address, so that users can register an address in either English or Japanese, and then fields for hiragana name/surname as appropriate, plus multilanguage zone and country support).
I am working now using the code of OPC 2.3.4.
I suspect most of my work will be limited to editing files in includes/modules/pages/checkout_one/, with no changes needed in modules/pages/create_account/ unless I want to change the default population of an account.
I understand I will need to change the function "saveAddressValues" in the file jquery.checkout_one.js. This seems fairly simple.
However, in the file jquery.checkout_one_addr.js there is mention of an array "z2c" in function "updateCountryZone", but I cannot find this anywhere.
Apparently it is supposed to be supplied by jscript_main.php, but there is no mention of it there. I definitely need to edit the creation of this array. Can anyone point out where I may find it?
Sorry, meant to write "c2z", not "z2c". Still, cannot find the array anywhere.
Apart from the page files above, most of the work will be in includes/classes/OnePageCheckout.php to add Japanese address requirements (language choice for address, hiragana support in new name fields, and multilanguage country and zone support). In standard Zen Cart this is done in the PHP and the JavaScript files (for real-time zone updates when country or language selection changes, so one more level added: address language change also changes display of country and zones).
Plus then adding new fields to the various template files, just like in standard Zen Cart.
@gernot, that c2z (country-to-zone) lookup table is generated by the OnePageCheckout class' getCountriesZonesJavascript method (as called by /includes/modules/pages/checkout_one/jscript_main.php) when state dropdowns are enabled for a site.
I'll suggest, if you're planning on "tinkering" with OPC's innards (i.e. /includes/classes/OnePageCheckout.php) that you create a Japanese version that uses class-inheritance so that you override only what's needed. That will save you a 'world-of-hurts' if/when that class is updated in the future.
That class is loaded at CP-0 and instantiated into the session at CP-75 by its auto_loader. If your class-override was loaded at CP-1 (so that it can extend OnePageCheckout) and instantiated into the session at CP-74, then the base OPC class will not be loaded, since it checks for instantiation prior to its load.
@lat9
Many thanks for the pointer, I saw the function in the class file, not sure why search for c2z in Windows did not show me that file. I know I need to modify many of the functions in the class, and was only too aware of the world of hurts you speak of (and which I have at each Zen Cart upgrade too).
I will play with the auto_loader method, although I need to first figure out class inheritance, and the implementation of loading and instantiation. All good basic study for further work on Zen Cart!
@lat9
I am looking into your suggestion of class inheritance. First time to do, and I am confused as to where the new and old class are supposed to meet logically.
Firstly, I am not sure whether class override means overriding the whole class, or just a subset of its functions. I assume the latter for now in this example.
Let's say I create new file OnePageCheckoutJP.php and in it have a new class definition to extend your class:
Then I put only the changed functions, with the same names as in the original OnePageCheckout class, into the new file.Code:OnePageCheckoutJP extends OnePageChekout
Then in class autoloader file config.checkout_one.php I would (well, it would be a new file, but just to illustrate the point) add new definitions for loading (CP-1) and instantiation (CP-74):
In this class override, does the "objectName" remain "opc"? I am confused (easily I may add!).Code:autoLoadConfig[0][] = array(
'autoType' => 'class',
'loadFile' => 'OnePageCheckout.php'
);
// new CP-1 loading
autoLoadConfig[1][] = array(
'autoType' => 'class',
'loadFile' => 'OnePageCheckoutJP.php'
);
// new CP-74 instantiation
$autoLoadConfig[74][] = array(
'autoType' => 'classInstantiate',
'className' => 'OnePageCheckoutJP',
'objectName' => 'opc',
'checkInstantiated' => true,
'classSession' => true
);
$autoLoadConfig[75][] = array(
'autoType' => 'classInstantiate',
'className' => 'OnePageCheckout',
'objectName' => 'opc',
'checkInstantiated' => true,
'classSession' => true
);
You wrote "then the base OPC class will not be loaded", that seems to imply that actually I need to override the entire class rather than just certain functions within the class?
Any pointers much appreciated.
@gernot, you're on the right track!
First, in the new auto_loader, you'll instantiate your class-override as the 'opc' session value. Since that will occur at CP-74, the instantiation of the base OPC at CP-75 won't occur, since the auto-loader won't overwrite that class if it's already there.
For the class-inheritance, you're correct ... you'll only provide the methods in your class that are being overridden, with the same names and inputs as the 'base' OPC methods. You might take a peek at my Database I/O Manager as its /admin/includes/classes/dbio/DbIo*Handler.php classes use class-inheritance to provide handler-specific actions while using common/base functions within the DbIoHandler.php class.
On the download page I saw Stirpe mentioned at v1.0.7 and v1.0.8
Do I need to install the Stripe plugin as well?
Thank you.
Only if that's what you want to use for payments on your store. OPC doesn't include any additional payment modules in its zip-file.Quote:
Originally Posted by keneso
Was there ever a fix for this? I have a client getting the 10730 error. It seems to be occurring only with guest checkout and when using a credit card to pay on PayPal.Quote:
Originally Posted by shags38
Zen Cart 1.5.6
OPC 2.3.4
Jim, since you're using a 'base' zc156 (no alpha-suffix), did you follow the installation/update instructions for that version: https://github.com/lat9/one_page_che...-cart-156-156aQuote:
Originally Posted by jeking
That identifies additions/changes needed for the older Zen Cart 'core' modules, especially the addition of a notification within the paypalwpp.php module to enable an observer (like OPC's) to instruct the processing to bypass the customer-record creation.
Sorry, typo. ZC is 1.5.6cQuote:
Originally Posted by lat9
Try enabling the paypalwpp debug mode. For those PayPal paid orders during guest checkout, you should be seeingQuote:
Originally Posted by jeking
in the PayPal-generated logs.Code:ec_step2_finish - 2a', 'address-creation bypassed based on observer setting.
Dang, I just cleared them thinking it would be in one-page logs. I'll watch for more and report back.Quote:
Originally Posted by lat9
Actually, having both the PayPal and OPC logs will both help to "read the tea leaves"!Quote:
Originally Posted by jeking
The OPC logs remained, so I've got those. I'll wait for a new error we can read all the leaves. :-)Quote:
Originally Posted by lat9
Got another one. I've got one large one-page error log and 13 paypal error logs.Quote:
Originally Posted by jeking
In the paypal logs, I do see the code you mentioned earlier in some of them https://prnt.sc/v5eavw
Got the logs, James. I'll review today and in the morning.
I'm still working on the OPC change, but the following patch is required for all Zen Cart versions prior to the (not-yet-released) zc157a.Quote:
Originally Posted by lat9
Edit (after making a copy) your store's /includes/modules/payment/paypalwpp.php, finding the following section:
and adding the following notification for OPC's (and other plugins') use:Code:/**
* Get Override Address (uses sendto if set, otherwise uses customer's primary address)
*/
function getOverrideAddress() {
global $db;
// Only proceed IF *in* markflow mode AND logged-in (have to be logged in to get to markflow mode anyway)
if (!empty($_GET['markflow']) && zen_is_logged_in()) {
// From now on for this user we will edit addresses in Zen Cart, not by going to PayPal.
$_SESSION['paypal_ec_markflow'] = 1;
// debug
$this->zcLog('getOverrideAddress - 1', 'Now in markflow mode.' . "\n" . 'SESSION[sendto] = ' . (int)$_SESSION['sendto']);
// find the users default address id
if (!empty($_SESSION['sendto'])) {
$address_id = $_SESSION['sendto'];
} else {
$sql = "SELECT customers_default_address_id
FROM " . TABLE_CUSTOMERS . "
WHERE customers_id = :customerId";
$sql = $db->bindVars($sql, ':customerId', $_SESSION['customer_id'], 'integer');
$default_address_id_arr = $db->Execute($sql);
if (!$default_address_id_arr->EOF) {
$address_id = $default_address_id_arr->fields['customers_default_address_id'];
} else {
// couldn't find an address.
return false;
}
}
That change was submitted (and accepted) for the zc157a 'core' yesterday.Code:/**
* Get Override Address (uses sendto if set, otherwise uses customer's primary address)
*/
function getOverrideAddress() {
global $db;
// Only proceed IF *in* markflow mode AND logged-in (have to be logged in to get to markflow mode anyway)
if (!empty($_GET['markflow']) && zen_is_logged_in()) {
// From now on for this user we will edit addresses in Zen Cart, not by going to PayPal.
$_SESSION['paypal_ec_markflow'] = 1;
// debug
$this->zcLog('getOverrideAddress - 1', 'Now in markflow mode.' . "\n" . 'SESSION[sendto] = ' . (int)$_SESSION['sendto']);
// find the users default address id
if (!empty($_SESSION['sendto'])) {
$address_id = $_SESSION['sendto'];
} else {
$sql = "SELECT customers_default_address_id
FROM " . TABLE_CUSTOMERS . "
WHERE customers_id = :customerId";
$sql = $db->bindVars($sql, ':customerId', $_SESSION['customer_id'], 'integer');
$default_address_id_arr = $db->Execute($sql);
if (!$default_address_id_arr->EOF) {
$address_id = $default_address_id_arr->fields['customers_default_address_id'];
} else {
// couldn't find an address.
return false;
}
}
// -----
// Give a watching observer the opportunity to bypass this address-override. An observer
// can disable the address-override processing by setting the $disable_address_override
// parameter to specifically (bool)true.
//
$disable_address_override = false;
$this->notify('NOTIFY_PAYPALWPP_DISABLE_GET_OVERRIDE_ADDRESS', $address_id, $disable_address_override);
if ($disable_address_override === true) {
$this->zcLog('getOverrideAddress - 1a', "Override disabled by observer request.\n");
return false;
}
Hi Cindy - I too am starting to get these PayPal 10730 errors. We are on 1.5.7 and using OPC 2.3.3. Didn't upgrade to 2.3.4 yet, so if you think that addresses the issue, I can do that.
Whenever I see this error, the one common denominator I see in the PayPal_CURL error log is that it never lists a customer ZIP code. Here is what I see from the recent customer failure:
As you can see, there is no zip, no city, and the street address says "Default billing address".Code:Request Parameters: {DoExpressCheckoutPayment}
Array
(
[PAYMENTREQUEST_0_AMT] => 15.9
[PAYMENTREQUEST_0_ITEMAMT] => 9.95
[PAYMENTREQUEST_0_SHIPPINGAMT] => 5.95
[L_PAYMENTREQUEST_0_NUMBER0] => LOOPSNEWGEN
[L_PAYMENTREQUEST_0_NAME0] => Loops New Generation by Yigal Mesika - Trick [22071]
[L_PAYMENTREQUEST_0_QTY0] => 1
[L_PAYMENTREQUEST_0_AMT0] => 9.95
[PAYMENTREQUEST_0_PAYMENTACTION] => Sale
[ALLOWEDPAYMENTMETHOD] => InstantPaymentOnly
[PAYMENTREQUEST_0_SHIPTONAME] => Guest Customer, **do not remove**
[PAYMENTREQUEST_0_SHIPTOSTREET] => Default billing address
[PAYMENTREQUEST_0_SHIPTOCITY] =>
[PAYMENTREQUEST_0_SHIPTOSTATE] => CA
[PAYMENTREQUEST_0_SHIPTOZIP] =>
[PAYMENTREQUEST_0_SHIPTOCOUNTRYCODE] => US
[BUTTONSOURCE] => ZenCart-EC_us
[ADDROVERRIDE] => 1
[RETURNFMFDETAILS] => 0
[PAYMENTREQUEST_0_CUSTOM] => EC-30972-1603506358
[PAYMENTREQUEST_0_INVNUM] => 30972-1603506358-[MJMMagic]
[PAYMENTREQUEST_0_CURRENCYCODE] => USD
[TOKEN] => EC-83T582732X054240A
[PAYERID] => FVMURM2NX3KC2
[NOTIFYURL] => https://www.domain.com/store/ipn_main_handler.php
[METHOD] => DoExpressCheckoutPayment
[USER] => customerservice_api1.domain.com
[PWD] => ****************
[VERSION] => 124.0
[SIGNATURE] => ****************************************************vHb3
)
Response:
Array
(
[TOKEN] => EC-83T582732X054240A
[SUCCESSPAGEREDIRECTREQUESTED] => false
[TIMESTAMP] => 2020-10-24T02:25:58Z
[CORRELATIONID] => 3ea9da404272b
[ACK] => Failure
[VERSION] => 124.0
[BUILD] => 55009056
[L_ERRORCODE0] => 10730
[L_SHORTMESSAGE0] => Shipping Address Postal Code Empty
[L_LONGMESSAGE0] => The field Shipping Address Postal Code is required
[L_SEVERITYCODE0] => Error
[CURL_ERRORS] =>
)
KEEPING IN MIND - This all seems to work fine for the most part. We still see a ton of orders come in using the Guest Account, both with PayPaldp and Paypalwpp. So it's not like the module isn't working. But I have seen these 10730 errors now once per day and can't figure out why it's not happening for everyone.
I just added that new block of code you mentioned above to see if that helps, but wanted to document here that this issue is also happening to us as well.
For my client it was only guest's checking out and paying with a credit card on PayPal. Cindy sent two changes I implemented today. It's not been long enough to know if it's worked or not, yetQuote:
Originally Posted by Jeff_Mash
Jeff, you'll need the 'other side' of the change, too. See this One-Page Checkout Github commit for details. That change to OPC's observer-class grabs that new notification and instructs paypalwpp to bypass its address-override creation when the site's processing a guest checkout.Quote:
Originally Posted by Jeff_Mash
Zen Cart 1.5.5f
Template is M o z e n (forum won't let me post that word without the spaces)
OPC 2.3.4
I did follow the steps for 1.5.5f on GitHub
When trying to checkout, I'm getting a 500 error:
[26-Oct-2020 09:29:39 America/Chicago] PHP Parse error: syntax error, unexpected ')', expecting :: (T_PAAMAYIM_NEKUDOTAYIM) in /XXX/includes/modules/pages/checkout_one/header_php.php on line 355
Clearly this file is not the root cause. But if that's not the cause, where do I go looking for the real issue?
I'm having problems with Payment form styling changing if a user makes a change to the default shipping method after OPC page has loaded.
After inspecting the page in both conditions I've discovered that on initial page load the form fields all have
class="form-control"
But as soon as a shipping method is changed that class is removed from the form fields, messing up the form style.
Is there a fix for this, or do I need to modify my forms so they look nice without the "form-control" class?
look for a double colon , ie ::Quote:
Originally Posted by jeking
T_PAAMAYIM_NEKUDOTAYIM: It’s a name for the :: operator in PHP. It literally means "double colon". For some reason they named it in Hebrew. Check your code syntax, and put a :: where appropriate.
best.