One-Page Checkout [Support Thread]

carlwhat:

@lat9, i think this is it:

https://www.numinix.com/zen-cart-plugins-modules-taxes-order-totals-c-179_250_373_165/store-credit-and-reward-dollars

$8/month...

best.

Correct

Just sayin ... lat9 isn't going to be able to inspect or identify any possible issues without access to that mod's code. Contact her by PM with a copy of the code for inspection. I'm sure she won't use it inappropriately.

DrByte:

Just sayin ... lat9 isn't going to be able to inspect or identify any possible issues without access to that mod's code. Contact her by PM with a copy of the code for inspection. I'm sure she won't use it inappropriately.

mprough:

Anyone using NUMINIX's store credit mod with OPC in 1.5.7?

~Melanie

I was inquiring for anyone who was using it. I wasn't asking anything else.

mprough:

I was inquiring for anyone who was using it. I wasn't asking anything else.
Fair, but I think lat9's query was an expression of willingness to test it, and potentially make it compatible or at least supported.

DrByte:

Fair, but I think lat9's query was an expression of willingness to test it, and potentially make it compatible or at least supported.
That's a correct interpretation.

lat9:

That's a correct interpretation.

Appreciate that, I'm trying to get a feel if it's time well spent or not. If no one uses it, then...

mprough:

Anyone using NUMINIX's store credit mod with OPC in 1.5.7?

~Melanie

carlwhat:

@lat9, i think this is it:

https://www.numinix.com/zen-cart-plugins-modules-taxes-order-totals-c-179_250_373_165/store-credit-and-reward-dollars

$8/month...

best.
mprough:

Appreciate that, I'm trying to get a feel if it's time well spent or not. If no one uses it, then...
Two alternatives of which I'm aware, but unfortunatly have no meaningful experience with, are Reward Points (free plugin) and another by TwitchToo (commercial).

Zen Cart 1.5.7b
One-Page Checkout (One Page Checkout) - Version: v2.3.7

I've made some modifications to my site so that I can prevent specific products from being visible to customers from certain countries.
Whilst this works for the most part, I want to ensure that if a customer changes shipping address during checkout to a country that has restrictions, the restricted product is removed from the cart and a message advises the customer of this.

I've got shipping country detection working on main_page=checkout_one, but I'm struggling to find a way to remove the restricted product from the array.

I tried doing this

$selected_ship_country = $_SESSION['opc']->getAddressValues('ship')['country_id'];
foreach ($_SESSION['cart']->get_products() as $product) {
    $check_for_restriction = $db->Execute("SELECT products_id
                                         FROM " . TABLE_PRODUCTS . "
                                         WHERE products_id = '" . $product['id'] . "'
                                         AND restricted_country_id LIKE '%" . $selected_ship_country . "%'");
    if ($check_for_restriction->RecordCount() > 0) {
        remove($product['id']);
}

in the hope that calling the remove function of the shopping cart class would do the trick, but it didn't make any difference.

Is there a way to achieve this during checkout with OPC?

strelitzia:

Zen Cart 1.5.7b
One-Page Checkout (One Page Checkout) - Version: v2.3.7

I've made some modifications to my site so that I can prevent specific products from being visible to customers from certain countries.
Whilst this works for the most part, I want to ensure that if a customer changes shipping address during checkout to a country that has restrictions, the restricted product is removed from the cart and a message advises the customer of this.

I've got shipping country detection working on main_page=checkout_one, but I'm struggling to find a way to remove the restricted product from the array.

I tried doing this

$selected_ship_country = $_SESSION['opc']->getAddressValues('ship')['country_id'];
foreach ($_SESSION['cart']->get_products() as $product) {
$check_for_restriction = $db->Execute("SELECT products_id
FROM " . TABLE_PRODUCTS . "
WHERE products_id = '" . $product['id'] . "'
AND restricted_country_id LIKE '%" . $selected_ship_country . "%'");
if ($check_for_restriction->RecordCount() > 0) {
remove($product['id']);
}

> in the hope that calling the remove function of the shopping cart class would do the trick, but it didn't make any difference.
> 
> Is there a way to achieve this during checkout with OPC?

i currently do not use OPC, although i have played around with it.  i'm not sure this is where i would do it...  but, if this is the spot i would try:

```php
//from:
remove($product['id']);

//to:
$_SESSION['cart']->remove($product['id']);

best.

carlwhat:

//from:
remove($product['id']);

//to:
$_SESSION['cart']->remove($product['id']);

That worked a treat. Now I just need to figure out how to get the total to recalculate as it is still showing the value from before the item is removed!

strelitzia:

That worked a treat. Now I just need to figure out how to get the total to recalculate as it is still showing the value from before the item is removed!
Follow that product removal up with a

zen_redirect(zen_href_link(FILENAME_CHECKOUT_ONE));

... after having set a message to the customer via the $messageStack class (which probably will require a global $messageStack; statement) to let them know what's going on.

On the page's re-display, the shipping and taxes will recalculate based on the updated products in the order.

OK, so... I'm trying to have the "shipping=billing" UNchecked by default so the customer gets to see both billing AND shipping address at the same time when going through Guest Checkout.

I've changed includes/classes/OnePageCheckout.php on line 169 from

public function getShippingBilling()
    {
        $_SESSION['shipping_billing'] = (isset($_SESSION['shipping_billing'])) ? $_SESSION['shipping_billing'] : true;
        return $_SESSION['shipping_billing'];
    }
``` to 

public function getShippingBilling()
{
// BOF shipping=billing default to false
$_SESSION['shipping_billing'] = (isset($_SESSION['shipping_billing'])) ? $_SESSION['shipping_billing'] : false;
// EOF shipping=billing default to false
return $_SESSION['shipping_billing'];
}

When a customer starts checkout, both billing and shipping address fields are visible and if you fill out billing address, save it, fill out shipping address and save it, everything works fine and you can continue through checkout.
BUT, if you fill out billing details, save it and then tick the "shipping=billing" checkbox, the shipping address gets populated and properly assigned, but there's still no payment/shipping options available. Editing ANY of the details (email, billing OR shipping) and saving it bring up the shipping/payment section and allows to proceed. 

What am I missing? Is this controlled anywhere else that I'm not seeing it? Thanks in advance!

I think I got it. Changing includes/classes/ajax/zcAjaxOnePageCheckout.php on line 54 seems to do the trick. I've changed it from

if ($_POST['shipping_is_billing'] == 'true') {
                $_SESSION['sendto'] = $_SESSION['billto'];
                $_SESSION['shipping_billing'] = true;
                $ship_to = 'billing';
                $_SESSION['opc']->setTempShippingToBilling();
            }

to

if ($_POST['shipping_is_billing'] == 'true') {
                $_SESSION['sendto'] = CHECKOUT_ONE_GUEST_SENDTO_ADDRESS_BOOK_ID;
                $_SESSION['shipping_billing'] = true;
                $ship_to = 'billing';
                $_SESSION['opc']->setTempShippingToBilling();
            }

Reason for this change is because if sendto==billto, it doesn't pass validation in validateTempShiptoAddress()

Initial tests indicate it's working OK, but I'm still unsure if this should be considered as an actual solution and what downsides it may have, or evn worse, what problems it may cause. Any ideas would be welcomed, especially if you can foresee any problems by using this code. Thanks!

balihr:

I think I got it. Changing includes/classes/ajax/zcAjaxOnePageCheckout.php on line 54 seems to do the trick. I've changed it from

if ($_POST['shipping_is_billing'] == 'true') {
$_SESSION['sendto'] = $_SESSION['billto'];
$_SESSION['shipping_billing'] = true;
$ship_to = 'billing';
$_SESSION['opc']->setTempShippingToBilling();
}

> to
> ```
if ($_POST['shipping_is_billing'] == 'true') {
                $_SESSION['sendto'] = CHECKOUT_ONE_GUEST_SENDTO_ADDRESS_BOOK_ID;
                $_SESSION['shipping_billing'] = true;
                $ship_to = 'billing';
                $_SESSION['opc']->setTempShippingToBilling();
            }

Reason for this change is because if sendto==billto, it doesn't pass validation in validateTempShiptoAddress()

Initial tests indicate it's working OK, but I'm still unsure if this should be considered as an actual solution and what downsides it may have, or evn worse, what problems it may cause. Any ideas would be welcomed, especially if you can foresee any problems by using this code. Thanks!
I'll need to review the operation for this case and will get back with that. My initial feeling is that you'll need to comment the cr@p out of what you're doing, else someone coming in later to help with the site is going to be very, very confused.

lat9:

I'll need to review the operation for this case and will get back with that. My initial feeling is that you'll need to comment the cr@p out of what you're doing, else someone coming in later to help with the site is going to be very, very confused.

I love this! But I need some details on how much is consider a cr@p? Is it less than a pound? Bigger than a breadbox? Sorry I just could not resist after looking through code that has no comments at all!!!

lat9:

I'll need to review the operation for this case and will get back with that. My initial feeling is that you'll need to comment the cr@p out of what you're doing, else someone coming in later to help with the site is going to be very, very confused.

LOL, yeah, I know, and I already have done that. The comments provided here were actually simplified or removed just to keep it simple here, but I really did try to explain it as much as I possibly could in the actual files. I've actually had to make a few other changes as well, which I was VERY unhappy with because I'd like to keep OPC as close to original as possible, primarily because you keep improving and updating it, but some things are just necessary...
BTW, you should see how I butchered the OPC's template files... :D

May I suggest considering adding this to a future release, with an admin-controlled switch? In some cases, it actually does make sense to show both addresses without requiring user action because billing and shipping addresses are different in 99% cases. So, if the admin could simply flip a switch to have it always shown, it would be great.

Also, one other thing I've noticed (not sure if it's been discussed before) is the inability to abort Guest Checkout and go to login. A simple scenario is - I click Guest Checkout and then I remember "oh wait, I have an account on this site, lemme login...". There's no way to go back to the point of choosing Guest-New-Returning once you start Guest Checkout, which might be a bit confusing... But then again, it's not SO important...

balihr:

May I suggest considering adding this to a future release, with an admin-controlled switch? In some cases, it actually does make sense to show both addresses without requiring user action because billing and shipping addresses are different in 99% cases. So, if the admin could simply flip a switch to have it always shown, it would be great.:dontgetit
I just did a random check of thirty or so of our customers' Orders page.

The result was exactly the opposite of your claim. In fact nearly twenty percent of the sites had no orders showing on the current page with the billing and shipping different.

I would agree that the trend may be turning toward more folks sending items rather than presenting them in person but, I just cannot see us ever getting to the two addresses being different 99% of the time.

dbltoe:

:dontgetit
I just did a random check of thirty or so of our customers' Orders page.

The result was exactly the opposite of your claim. In fact nearly twenty percent of the sites had no orders showing on the current page with the billing and shipping different.

I would agree that the trend may be turning toward more folks sending items rather than presenting them in person but, I just cannot see us ever getting to the two addresses being different 99% of the time.

You missed my point. I said "in some cases...", meaning those sites where 99% of orders have different shipping and billing addresses. Slow down on the wine. :P
I only gave a suggestion for a future feature update which really isn't that hard to add (assuming my solution above is actually correct :wacko:), and it's an option for the store admin to choose from IF they need it. :wink2:

g2ktcf:

I love this! But I need some details on how much is consider a cr@p? Is it less than a pound? Bigger than a breadbox? Sorry I just could not resist after looking through code that has no comments at all!!!
A cr@p is enough so that someone familiar with this plugin (or any other chunk of code) can figure out what's going on if the person who made the change is no longer available!

I hear you about the code that has no comments at all! Way back, I was tasked with creating a simulation model of a Motorola 68000. I found another developer who had created one and asked for a copy of the code to use as a basis.

When I received the code (a humongous blob, BTW), there was not a single comment. When I asked the developer why, he said "Comments only indicate what the code's *intended *to do". I hit the delete button and started from scratch.

lat9:

I'll need to review the operation for this case and will get back with that. My initial feeling is that you'll need to comment the cr@p out of what you're doing, else someone coming in later to help with the site is going to be very, very confused.
The issue here is that while a Billing address is *always *required, a Shipping address isn't (think downloads and/or Gift Certificates). That's why OPC asks initially for the billing address and gives the opportunity to indicate a different shipping address (iff one is required).