COWOA (for ZC v1.5.x)

lat9:

That P.S. is from a post a little over a year ago. I did a fresh install of v2.4 and the define is still missing. What are the TEXT_CHECKOUT_LOGOFF_CUSTOMER and TEXT_CHECKOUT_LOGOFF_GUEST defines "supposed" to say?

Thought I was missing something... but looking at ZenCart1.5.1 and 2, it's in the core langrage file for /includes/languages/english/checkout_sucess.php not part of COWOA!

define('TEXT_CHECKOUT_LOGOFF_GUEST', 'NOTE: To complete your order, a temporary account was created. You may close this account by clicking Log Off. Clicking Log Off also ensures that your receipt and purchase information is not visible to the next person using this computer. If you wish to continue shopping, feel free! You may log off at anytime using the link at the top of the page.'); 
define('TEXT_CHECKOUT_LOGOFF_CUSTOMER', 'Thank you for shopping. Please click the Log Off link to ensure that your receipt and purchase information is not visible to the next person using this computer.');

Used in tpl_checkout_success_default.php as

<div id="checkoutSuccessLogoff"> 
<?php 
if ($_SESSION['COWOA']) { 
  zen_session_destroy(); 
} else { 
  if (isset($_SESSION['customer_guest_id'])) { 
    echo TEXT_CHECKOUT_LOGOFF_GUEST; 
  } elseif (isset($_SESSION['customer_id'])) { 
    echo TEXT_CHECKOUT_LOGOFF_CUSTOMER; 
  } ?> 
<div class="buttonRow forward"><a href="<?php echo zen_href_link(FILENAME_LOGOFF, '', 'SSL'); ?>"><?php echo zen_image_button(BUTTON_IMAGE_LOG_OFF , BUTTON_LOG_OFF_ALT); ?></a></div> 
<?php } ?> 
</div>

the guest_id section still exist in ZenCart 1.5.2

Unfortunately, having the constants in the checkout_success page's language file doesn't do the order_status page any good.:(

Those two constants are used at the bottom of tpl_order_status_default.php:

<!--Kills session after COWOA customer looks at order status-->
<?php
if ($_SESSION['COWOA'] and COWOA_LOGOFF == 'true') {
  zen_session_destroy();
} else {
  if (isset($_SESSION['customer_guest_id'])) {
    echo TEXT_CHECKOUT_LOGOFF_GUEST;
  } elseif (isset($_SESSION['customer_id'])) {
    echo TEXT_CHECKOUT_LOGOFF_CUSTOMER;
  }
?>
<?php } ?>
<!--eof logoff-->

I'm thinking that the wording on the order_status page should be a tad different than that used on the checkout_success page, too.

lat9:

That P.S. is from a post a little over a year ago. I did a fresh install of v2.4 and the define is still missing. What are the TEXT_CHECKOUT_LOGOFF_CUSTOMER and TEXT_CHECKOUT_LOGOFF_GUEST defines "supposed" to say?

Just did a search of the code and I don't see any reference to "TEXT_CHECKOUT_LOGOFF_GUEST".

"TEXT_CHECKOUT_LOGOFF_CUSTOMER" looks like it has been missing for sometime, and it's never been reported as an "issue".. I don't think that it creates an "issue" since it's wrapped in a non-existent condition

  if (isset($_SESSION['customer_guest_id'])) {
    echo TEXT_CHECKOUT_LOGOFF_GUEST;

"customer_guest_id" doesn't exist.. I'm thinking that this is code from an original/older version of COWOA.. The codebase that is part of COWOA comes from multiple contributors, and this looks like code that was leftover from one of these original contributors..

lat9:

Unfortunately, having the constants in the checkout_success page's language file doesn't do the order_status page any good.:(

Those two constants are used at the bottom of tpl_order_status_default.php:

I'm thinking that the wording on the order_status page should be a tad different than that used on the checkout_success page, too.

I see what your saying... I use a differnt oder status page then what came with COWOA and didn't see a need to have a kill command or login user check when the session was killed at the successfull order completed page. I also wanted any user to make an easy check on order status even if they have a account. I hate logging in just to see where my order is.

@DivaVocals

Just did a search of the code and I don't see any reference to "TEXT_CHECKOUT_LOGOFF_GUEST".
That chunk of code at the bottom of the tpl_order_status_default.php during your next testing/edits could possibly get removed. I may have to play a bit too, my page header is differnt for it too... due to how I'm using returns.

I have Zen Cart 1.50 with a couple of free items. After installing COWOA, customer has only FREE items in cart, $0.00 total. They get to get "order review" stage of checkout with not buttons to click to complete the order. I have the FreeCharger payment module installed to handle this case. Is there a patch for COWOA?

So tonight I was able to replicate this issue.

Scully:

I've gone through this entire post and haven't seen the answer to my question, so if someone could help me, I'd be very grateful. :-)

I installed the COWOA (1.5.0, I think) a few months ago, and after some hiccups, got it working properly. But recently a few different book customers have contacted me, saying that the system is telling them their session has expired. This is happening less than 5 minutes after they've finalized their order. How can I reset the timeout feature so that their session won't expire until AFTER they've downloaded their products?

Oddly enough, it isn't happening every time, just occasionally. Any ideas why?

Thanks!!

To resolve it I changed the COWOA setting "Enable Forced Logoff" to "false". This stopped the session expiration error and allowed my customer to get their download.

BUT..

once I changed "Enable Forced Logoff" to "false", I noticed that something lat9 reported reared it's ugly head..

lat9:

P.S. Off-subject, but when I did a fresh install of COWOA on a fresh install of Zen Cart 1.5.1, the define TEXT_CHECKOUT_LOGOFF_CUSTOMER appears to be missing from the orders_status page.

lat9:

That P.S. is from a post a little over a year ago. I did a fresh install of v2.4 and the define is still missing. What are the TEXT_CHECKOUT_LOGOFF_CUSTOMER and TEXT_CHECKOUT_LOGOFF_GUEST defines "supposed" to say?

DivaVocals:

Just did a search of the code and I don't see any reference to "TEXT_CHECKOUT_LOGOFF_GUEST".

"TEXT_CHECKOUT_LOGOFF_CUSTOMER" looks like it has been missing for sometime, and it's never been reported as an "issue".. I don't think that it creates an "issue" since it's wrapped in a non-existent condition

if (isset($_SESSION['customer_guest_id'])) {
echo TEXT_CHECKOUT_LOGOFF_GUEST;

> 
> "customer_guest_id" doesn't exist.. I'm thinking that this is code from  an original/older version of COWOA.. The codebase that is part of COWOA  comes from multiple contributors, and this looks like code that was  leftover from one of these original contributors..

The issue is that in BOTH cases this block of code in the orders_status page is the issue.. The missing constant definition aside, this code flat out it just doesn't "do" what it should do, and it's over my head to fix.. So I'm throwing it out there for the community to take a gander at..

<!--bof logoff--> <!--Kills session after COWOA customer looks at order status--> <?php if ($_SESSION['COWOA'] and COWOA_LOGOFF == 'true') { zen_session_destroy(); } else { if (isset($_SESSION['customer_guest_id'])) { echo TEXT_CHECKOUT_LOGOFF_GUEST; } elseif (isset($_SESSION['customer_id'])) { echo TEXT_CHECKOUT_LOGOFF_CUSTOMER; } ?> <?php } ?> <!--eof logoff-->

The workaround for now for anyone selling downloads is to set "**Enable Forced Logoff**" to "false" and replace the code above as follows:

<!--bof logoff--> <!--Kills session after COWOA customer looks at order status--> <?php if ($_SESSION['COWOA'] and COWOA_LOGOFF == 'true') { zen_session_destroy(); } else { if (isset($_SESSION['customer_guest_id'])) { echo ' '; } elseif (isset($_SESSION['customer_id'])) { echo TEXT_CHECKOUT_LOGOFF_CUSTOMER; } ?> <?php } ?> <!--eof logoff-->

DivaVocals:

"customer_guest_id" doesn't exist.. I'm thinking that this is code from an original/older version of COWOA.. The codebase that is part of COWOA comes from multiple contributors, and this looks like code that was leftover from one of these original contributors..
Actually, $_SESSION['customer_guest_id'] is set by the PayPal payment processing when a not-logged-in customer uses the express-checkout button to complete their purchase.

lat9:

Actually, $_SESSION['customer_guest_id'] is set by the PayPal payment processing when a not-logged-in customer uses the express-checkout button to complete their purchase.
Agreed, but this whole codeblock still isn't working as expected, and it's totally noticeable if one is selling downloads..

osulywan:

I have Zen Cart 1.50 with a couple of free items. After installing COWOA, customer has only FREE items in cart, $0.00 total. They get to get "order review" stage of checkout with not buttons to click to complete the order. I have the FreeCharger payment module installed to handle this case. Is there a patch for COWOA?

I found what was happening. For the benefit of others who may have a total order = $0 ...

includes/templates/[YOUR TEMPLATE]/templates/tpl_checkout_confirmation_default.php on or about line 47 is this condition:

if ($_SESSION['cart']->show_total() != 0) { ?>

I removed the condition but kept "?>"

Then I deleted the last 3 lines of the file that close the conditional:

<?php } ?>

I hope most of you have enormous numbers in your order totals but if you offer free stuff or in my case use products to register volunteers and customer appreciation swag, here it is. Thanks for the work you have done on COWOA, it works great. Here is my site: https://www.mellew.com/reg/

After uploading the COWOA files (I did change the name of the admin folder, and the template folder), when I try to SEND the SQL code I get "WARNING: An Error occurred, please refresh the page and try again."

mdawg:

After uploading the COWOA files (I did change the name of the admin folder, and the template folder), when I try to SEND the SQL code I get "WARNING: An Error occurred, please refresh the page and try again."

And what does the log file say the error is??

Hi Diva Vocals,

I'm loving this mod, so easy to implement, and the graphic steps are really nice. Just one change would be useful in my particular case...

Is it possible to safely skip the payment page in COWOA mode but keep it for logged in customers? On my website, there's nothing for a COWOA buyer to do on this page - they just entered their billing address on the billing page, they don't get any gift vouchers, they don't get to choose a payment method (i only use paypalwpp), they already entered comments if any on the shipping page, they'll see their total on "confirm order" page, and they make their payment on paypal.com after they confirm the order (I don't accept any payments directly on my website). If it's doable for someone fairly familiar with if/else statements but whose coding ability is limited to copying and pasting, how would I go about making this change?

Thank you!
Magz

magz:

Hi Diva Vocals,

I'm loving this mod, so easy to implement, and the graphic steps are really nice. Just one change would be useful in my particular case...

Is it possible to safely skip the payment page in COWOA mode but keep it for logged in customers? On my website, there's nothing for a COWOA buyer to do on this page - they just entered their billing address on the billing page, they don't get any gift vouchers, they don't get to choose a payment method (i only use paypalwpp), they already entered comments if any on the shipping page, they'll see their total on "confirm order" page, and they make their payment on paypal.com after they confirm the order (I don't accept any payments directly on my website). If it's doable for someone fairly familiar with if/else statements but whose coding ability is limited to copying and pasting, how would I go about making this change?

Thank you!
Magz

You can disable the gift vouchers though so it doesn't appear on the payment page by disabling the gift voucher module..

I know the default Zen Cart checkout skips the shipping page when there are no shipping options enabled or if the order requires no shipping (in the case of downloadable products).. I believe that the payment page is skipped when the cart contains only free products by default.. Dunno what is required to skip the payment page if only one payment method is enabled in the store.. Maybe another community member can chime in..

Thanks Diva Vocals...

I can't disable GVs because registered customers use them, and can't totally disable the payment page because that's where the registered customers redeem the GVs...unless GV redemption can be moved to a different page. Ideally, I'd have a single-page checkout but without all the hassle and incompatibilities of the FEC mod... I guess that would be a lot of figuring out of what code to copy & paste from/to where... ;-)

Yes, if other community members could chime in that would be great...
Thanks!
Magz

DivaVocals:

You can disable the gift vouchers though so it doesn't appear on the payment page by disabling the gift voucher module..

I know the default Zen Cart checkout skips the shipping page when there are no shipping options enabled or if the order requires no shipping (in the case of downloadable products).. I believe that the payment page is skipped when the cart contains only free products by default.. Dunno what is required to skip the payment page if only one payment method is enabled in the store.. Maybe another community member can chime in..

magz:

Thanks Diva Vocals...

I can't disable GVs because registered customers use them, and can't totally disable the payment page because that's where the registered customers redeem the GVs...unless GV redemption can be moved to a different page. Ideally, I'd have a single-page checkout but without all the hassle and incompatibilities of the FEC mod... I guess that would be a lot of figuring out of what code to copy & paste from/to where... ;-)

Yes, if other community members could chime in that would be great...
Thanks!
Magzas I said before a single page check out isn't necessarily going to save time because a lot of processing still has to happen in the back end.. and it doesn't change the same basic four steps to completing a sale. payment, shipping, review, and confirm.. where this module improves the stock checkout process is that it provides an improved user interface with good visual cues for the shopper so they know exactly where they are in the process, what part of the process they have completed, and what steps left are in the process..

Finally, COWOA will be the DEFAULT checkout process in the upcoming 1.6 release of Zen Cart as it is being integrated into the core code.

I've installed COWOA for 1.5.1 and it works great but it asks for Billing information even though Pick Up and Pay in Store are options, so if they choose those, I won't need them to enter billing info. Any way of changing the order in which it asks for things? Like, it should only ask for billing info if you are paying with some method that requires a bill sent out. Billing info should come after payment method is selected. Eg If I select PayPal Express then billing and shipping are handled without entering anything again.

Eldridge:

I've installed COWOA for 1.5.1 and it works great but it asks for Billing information even though Pick Up and Pay in Store are options, so if they choose those, I won't need them to enter billing info. Any way of changing the order in which it asks for things? Like, it should only ask for billing info if you are paying with some method that requires a bill sent out. Billing info should come after payment method is selected. Eg If I select PayPal Express then billing and shipping are handled without entering anything again.Are Pick Up and Pay in Store payment and shipping modules... a single module? What??? Because I'll bet MONEY that you'd have the VERY SAME "issue" with the default checkout process (which COWOA follows).. So sure you COULD re-write the checkout process to accomodate your needs..

No, they are separate modules. By COWOA forcing the customer to enter Billing information, it's almost as much work as them having to register an account. It sort of defeats the purpose. I mean who really bills their customers anyway? We mostly expect payment up front through PayPal or Credit Card or payment on pick up or delivery. So being confronted with a page where you have to give your name, address etc before you have selected your payment method makes no sense.

Eldridge:

No, they are separate modules. By COWOA forcing the customer to enter Billing information, it's almost as much work as them having to register an account. It sort of defeats the purpose. I mean who really bills their customers anyway? We mostly expect payment up front through PayPal or Credit Card or payment on pick up or delivery. So being confronted with a page where you have to give your name, address etc before you have selected your payment method makes no sense.

Okay..It's a discussed to death fact that COWOA MUST create a customer record. You do understand that you have to collect CUSTOMER DATA in order for Zen Cart to record an order.. Regardless as to whether or not they are paying with PayPal, you still have to create a customer record in order to create an ORDER record..
BILLING isn't about sending the customer an INVOICE.. It's a term to mean WHO/WHERE the payment will be collected from.. If you don't like using that term, you are free to change the language file to use a term that you prefer.

I installed COWOA in Feb on my Zen 1.5.1 store. I received some complaints that products are being placed in the user's cart that they did not acquire. Further research revealed this customer was a COWOA account. There were rows in customers_basket table for her customer id that did not belong. (We have product option values for Name on these products which is how I know they do not belong). I know Zencart has a "merge cart" feature designed to capture stuff put into the cart in a previous session when the user logs in. I am not sure how that should behave for a COWOA session. Timing is an issue since these customers may have been on the store simultaneously.

Is there a way to assure that COWOA customers bypass the merge cart routine?