COWOA (for ZC v1.5.x)

[DivaVocals]

I experience a strange issue. Some COWOA customers occasionally manage to checkout a small order with out shipping cost added to the order. The shipping line on the order shows:
u: $0.00
I allow free shipping if above $65 and otherwise customer selects USPS or UPS. No other options. This happened 3x over the last 2 weeks and about 100 orders. I am at a loss how this happens. Any idea how to find out?

Nope.. to troubleshoot you need to replicate the issue.. You have to know the EXACT set of circumstances to create this issue consistently.. Check your error logs.. there may be some clues there too.. Otherwise we'd all only be guessing what's going on since this is not a known/reported bug with COWOA..

[mydanilo]

Thanks, going to ask last customer and try to replicate.

[DivaVocals]

Thanks, going to ask last customer and try to replicate.

If you have a dev version of your site you can try recreating the EXACT order where the issue cropped up and see if you can trigger the error..

[tomtom55]

Hey everyone,

I am using COWOA 2.4 with Zen Cart 1.5.3. In an attempt to use only COWOA and not give the option to create an account I have changed the following:

I changed the checkout link in the header and the button in the cart to point at the no_account page (the first page of the COWOA checkout process)

I removed the account and login links from the header

Last, I removed the login link and text from the COWOA page itself.

Everything seems to be working fine but I am concerned I may have overlooked something or that it may cause errors down the road. Does anyone see any issues with this setup?

Thank You,

Tom

[rstar23]

I am currently running 1.3.9g and using COWOA. We rely heavily upin it, in fact. Have found out that we need to upgrade to 1.5.4 (by 3/15/15). After searching t4his thread for 1.5.4, my question is: will the current version of COWOA work with zencart 1.5.4?

tia and blessings

Rich

[DivaVocals]

GENTLE reminder that it PAYS to search the support threads.. You question may have already been answered..

Just wanted to add one more thought..

This is one MORE reason why you DO NOT install ANY modules especially a BETA module on your LIVE store until you TEST TEST TEST THE SNOT OUT OF IT!!!!!! The PROPER way to do ANY upgrade (New module, upgraded module, new Zen Cart version) is to create a PROPER development environment and test your changes there BEFORE attempting to update your live site.. In fact I think that shopowners should get into the habit of maintaining an active dev/test/sandbox site. (like a localhost version)

The COWOA version on Github (https://github.com/DivaVocals/zen_COWOA) is a BETA, PRE-RELEASE version. It is NOT a SNEAK PEEK/ version and should not be treated as such unless you are sure what you are doing and test it on a proper dev/test/sandbox site before posting on your live site.. I posted the link to the Github repo to get TESTING feedback before submitting to the downloads. YES.. It IS in use on live stores, but you should TEST TEST TEST on a DEVELOPMENT SITE before using on your own live site..

And here is the issue... Please note the highlighted section:

Source: http://www.zen-cart.com/showthread.p...42#post1252042





I just noticed this in your post from earlier today..





So the issue is that COWOA v2.06 is compatible with the LATEST version of Zen Cart (v1.5.3).. The error logs you are getting would be expected since the login module, functions, and classes in Zen Cart v1.5.3 are VERY different than v1.5.1. The issues you had with the install SQL can only be chalked up to user error as I CANNOT repeat them..

It is possible to apply the new COWOA changes to v1.5.1. You would have to do some merging to pull in the updates to COWOA while leaving behind the v1.5.3 specific code.

OR

you could spend some time trying to bring in the classes and functions needed from v1.5.3 into your v1.5.1 store to allow you to use COWOA v2.06 with Zen Cart v1.5.1. (NOT recommended)

I am NOT sure I will do ANY work to make this version of COWOA v1.5.1 compatible.. It's TOO MUCH work to maintain two versions where the core files are soooo different.. I submit module updates as I make them for my clients, and I will NOT be upgrading any of my v1.5.1 clients to this new version of COWOA until I upgrade their stores to v1.5.3. There are BIG differences between v1.5.1 and v1.5.3. Given that Zen Cart v1.6.0 will include COWOA as part of the core fileset, and there are many parts of the v1.5.3 fileset that come from the v1.6.0 dev. So, I'm not AT ALL inclined to maintain backwards compatibility with v1.5.1.

I am of the opinion that v1.5.0, and v1.5.1 shops should be upgrading to v1.5.3 NOW and not meandering about waiting to upgrade..

Here's the changelog:
v2.6 - 07/10/2014

• Updated for Zen Cart v1.5.3
• Fix bug with downloads being prevented for COWOA when 'Enable Forced Logoff' was turned on (dwest)
  ref: http://www.zen-cart.com/showthread.php?196995-COWOA-(for-ZC-v1-5-x)&p=1246575#post1246575
• Additional improvements to onscreen text/labels
• MANY improvements to the login page:
  
  • Eliminate the need for an unnecessary click to create an account by making the "Create Account" available on the login page.
  • Addition of "Shop with Confidence" and "Customer Service" content boxes (admin control to turn on/off and content managed via the banner manager)
  • Move guest checkout field-set to the top of the page for better user visibility
  
  

Would like folks to test and report back issues they find, and once it seems like everything is working okay, I will submit to the downloads..

Here's the link to the GitHub repo: https://github.com/DivaVocals/zen_COWOA

[jeking]

A client wants to force all customers to use COWOA, removing the login and create account options. This means the login page is no longer needed and we can skip right to checkout. I thought I could do this by changing the filename of

define('FILENAME_LOGIN', 'login');

to

define('FILENAME_LOGIN', 'no_account');

Worked as expected on the cart side, but then also redirected the admin login to a non-existant no_account page. Is there a way to accomplish this while not breaking the admin login?

[jeking]

A client wants to force all customers to use COWOA, removing the login and create account options. This means the login page is no longer needed and we can skip right to checkout. I thought I could do this by changing the filename of

define('FILENAME_LOGIN', 'login');
to
define('FILENAME_LOGIN', 'no_account');

Worked as expected on the cart side, but then also redirected the admin login to a non-existant no_account page. Is there a way to accomplish this while not breaking the admin login?

Figured it out just after posting. In /includes/templates/MY_TEMPLATE/templates/tpl_shopping_cart_default.php and /includes/templates/MY_TEMPLATE/common/tpl_header.php I changed FILENAME_CHECKOUT_SHIPPING to FILENAME_NO_ACCOUNT

[bwaikel]

... I also had a customer fall through without leaving their telephone number (although it's mandatory) I checked myself and sure enough I could purchase without filling this field.

Don't know if you already figured this one out but I had the same issue with COWOA not requiring telephone number (customer service said they wanted that info). Turns out I had "0" set for telephone number in "configuration>minimum vales". I set it to "10" now I get the alert when trying COWOA and not inputting a tel number.

[DivaVocals]

Don't know if you already figured this one out but I had the same issue with COWOA not requiring telephone number (customer service said they wanted that info). Turns out I had "0" set for telephone number in "configuration>minimum vales". I set it to "10" now I get the alert when trying COWOA and not inputting a tel number.

Thanks for sharing this.. I assume that by "COWOA" you mean the GUEST checkout function of the COWOA module is where you see this phenomenon occurring.. Correct?? OR do you see this occurring in the standard checkout as well??

Actually this sounds like a it's more of a ZEN CART buglet.. (will have to look at this and do more testing to see) If the phone number is REQUIRED, but you set the minimum digits required to ZERO, then yep.. technically the phone number field not being filled out COULD pass form validation. Nonetheless, I'll add this note to the user docs just so folks know..