COWOA (for ZC v1.5.x)

mydanilo:

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..

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

mydanilo:

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..

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

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

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

DivaVocals:

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..

DivaVocals:

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

Source: http://www.zen-cart.com/showthread.php?196995-COWOA-%28for-ZC-v1-5-x%29/page48&p=1252042#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..

DivaVocals:

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

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

Rizla:

... 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.

bwaikel:

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..

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?

There is a better way of doing this without allowing a user to bypass your define... by hand typing in 'main_page=login' or 'create_account' so on, bypassing the no_account page. to do it right, you need a observer to trap the account and login creation pages.

thought I had a switch setup for this... most of not included it... once I can get GIT to work, I'll pass the changes along..

Adding the switch to the login section of the header and setting up the observer... which will be used again later on to setup free downloads... the ever ghosting checkout by email only one.

Reason for the observer... to catch the bypass hack attempts! Using a switch to turn on/off the account system without modifying many different pages.

davewest:

There is a better way of doing this without allowing a user to bypass your define... by hand typing in 'main_page=login' or 'create_account' so on, bypassing the no_account page. to do it right, you need a observer to trap the account and login creation pages.

thought I had a switch setup for this... most of not included it... once I can get GIT to work, I'll pass the changes along..

Adding the switch to the login section of the header and setting up the observer... which will be used again later on to setup free downloads... the ever ghosting checkout by email only one.

Reason for the observer... to catch the bypass hack attempts! Using a switch to turn on/off the account system without modifying many different pages.

Cool.. As always Dave happy for your hands in this.. If you pass the changes on, I'll incorporate into the repo.. I've partially finished merging some of the last changes you sent to me.. Need to finish testing and get everything submitted..

I spent all day (more than 8 weary hours) comparing cowoa 2.6 with my sweet cowoa 2.3 loaded into zc151, and then painstakingly merging cowoa2.6 into zc154, only to end the day feeling a lot more work is required before 2.6 is up and running on zc154.

I struggle to see the point of the "Shop with Confidence" and "Customer Service" content boxes bundled into cowoa, especially without adequate explanation of what they are supposed to do. But alas they are written into the auto-installer, and their respective files must be inspected and merged in order to derisk a white screen of death. So much extra work when I am already inclined to leave them turned off. In the next release, it would be nice if these could be treated as options rather than as core, more kiss, less facesuck.

Also, if the new and substitute icons could be placed into separate folders under images and icons, so that they are not loaded as if required, only to have to weed them out later.

It has been one of those days.

dw08gm:

I spent all day (more than 8 weary hours) comparing cowoa 2.6 with my sweet cowoa 2.3 loaded into zc151, and then painstakingly merging cowoa2.6 into zc154, only to end the day feeling a lot more work is required before 2.6 is up and running on zc154.Right.. Well not for nothing here, but since it was stated VERY CLEARLY in the Github repo and on this support thread that v2.6 is a BETA version of COWOA, I'm not quite sure what exactly you were expecting by installing a STILL UNDER DEVELOPMENT module... But thanks for pointing out that v2.6 still not ready to be released (something I think ALL the contributors are keenly aware of, and have made clear to EVERYONE who's asked about this version of COWOA.. hence why it's not yet been released..)

dw08gm:

I struggle to see the point of the "Shop with Confidence" and "Customer Service" content boxes bundled into cowoa, especially without adequate explanation of what they are supposed to do. But alas they are written into the auto-installer, and their respective files must be inspected and merged in order to derisk a white screen of death. So much extra work when I am already inclined to leave them turned off. In the next release, it would be nice if these could be treated as options rather than as core, more kiss, less facesuck.It's a BETA VERSION and we're STILL TESTING new features.. So it's ON so we can TEST.. I hope that's clear enough now..

As for WHY the "Shop with Confidence" and "Customer Service" content boxes are part of the COWOA core?? I explained that a few posts back when I 1st posted the link to the COWOA Github repo.. Adding those reasons to the readme files while we're still TESTING is well.. a LOT premature.. Now if you wanna to do some reading up on your own about usability studies and shopping cart conversions, you'll see WHY these OPTIONAL features were added.. (probably the SAME reason why SIMILAR features were added to FEC, and PROBABLY why similar conversion and usability features are being discussed being included as part of the v1.6 core integration of COWOA)

Again.. if you don't want these features, the answer is very simple.. don't turn them on.. They are on by default because WE ARE TESTING and this is how we wanna test things while this module is in BETA.. That should be okay no???

dw08gm:

Also, if the new and substitute icons could be placed into separate folders under images and icons, so that they are not loaded as if required, only to have to weed them out later.No idea what you are talking about..

Actually the mod is quite good, having made further inroads today. My main objection with "Shop with Confidence" and "Customer Service" is the potential for clutter on the login page and distracting customers from quickly proceeding through checkout.

DivaVocals:

No idea what you are talking about..

No wonder, I got confused with SuperOrders, which I had been working on earlier that day. I should have had a rest before jumping straight into COWOA.

Cheers

dw08gm:

Actually the mod is quite good, having made further inroads today. My main objection with "Shop with Confidence" and "Customer Service" is the potential for clutter on the login page and distracting customers from quickly proceeding through checkout.

Right.. Can't say this enough (apparently).. Just like the option for turning off the sideboxes during the checkout, the "Shop with Confidence" and "Customer Service" boxes are an OPTIONAL FEATURE.. If you are concerned, then DON'T turn these boxes on.. A TREMENDOUS AMOUNT of work was done researching shopping cart conversions and improving the checkout process.. I relied on information obtained from people and sites who have distinguished themselves as EXPERTS in this arena. Some of this research includes recommendations from STARS within the Zen Cart community including Delia Wilson, Melanie Prough, and Eric Leuenberger. The inclusion of these boxes is based on usability and conversion studies which suggest their inclusion AIDS in shopping cart conversion.. (as I have already explained in my prior posts) The location is strategically placed precisely so that they don't clutter or distract.. (again based on RESEARCH which indicates that this is the BEST location for these boxes) This is why they are on the right at the bottom of the right column.

Strongly suggest that you read up on shopping cart conversion and some of the usability studies conducted to understand the logic behind the inclusion of these elements and why the location they are placed in was chosen.. We're not forcing any feature on anyone who installs COWOA.. We're only including elements that have been proven in studies to improve the checkout experience. These improvements aren't based on what WE (the contributors) think is right or even prefer.. There was actually some thoughtful research put into adding each of the new features.. Now if you don't believe the logic behind these new inclusions (like turning off the sideboxes throughout the checkout to reduce distractions, the "Shop with Confidence" and "Customer Service" boxes, etc), then DON'T TURN THEM ON.. Again they are OPTIONAL settings. They are turned on by default in our BETA version because we are still TESTING..

I DO appreciate your feedback, but you appear to be advocating excluding these features because YOU don't want them. Which at the end of the day is a PERSONAL preference. I don't see ANY reason to not include these features when they can EASILY be turned off which should satisfy your concerns.. Now if you have a more compelling reason other than personal preference why this feature should not be included, I am all ears because the Githib COWOA effort is ALL ABOUT trying to improve the shopping cart experience..

Alternatives would be to create a separate mod for these items or to enable the parts to be included in other sideboxes, such as Information or More Information.

For stores that also turn off all sideboxes on the login page, such sidebox options would be superfluous.

For those seeking to upgrade from previous versions of this mod and/or zencart, the extra work can be more than a bother. Like I said for me it took all day just to compare the new fileset aganist my older fileset and then to compare the affected files in zc154, since I kept the same db in upgrading directly from zc151, and since the documentation explaining the changes had understandably not yet been updated. It then took another day to get the mod working similar to what I had previously. I am sure the earlier versions, including that with checkout steps, did not require half as much work to setup.

Also I am not a fan of auto-installers, generally because (coming from a non-programming background) I dont always get how they work, and much prefer the old sql-patch method where it is relatively easy to study the changes about to be made and relatively easy to alter or stage (rem/unrem) the sql-patch to only make changes that I understand or desire.

dw08gm:

For those seeking to upgrade from previous versions of this mod and/or zencart, the extra work can be more than a bother. Like I said for me it took all day just to compare the new fileset aganist my older fileset and then to compare the affected files in zc154, since I kept the same db in upgrading directly from zc151, and since the documentation explaining the changes had understandably not yet been updated. It then took another day to get the mod working similar to what I had previously. I am sure the earlier versions, including that with checkout steps, did not require half as much work to setup.
BETA VERSION.. No docs.. Still in development.. So while I appreciate you sharing your expereince, IT'S A BETA VERSION!!!!! Were you expecting a FINISHED product?????? Not sure what your point is here..

Now that said, all of the contributors have tested UPGRADING, and we aren't having the PLETHORA of issues you are describing with regards to upgrading, but to your point we will make sure that we test upgrades thoroughly..

dw08gm:

Alternatives would be to create a separate mod for these items or to enable the parts to be included in other sideboxes, such as Information or More InformationRight.. So allow me to be blunt here.. I appreciate your concerns, but that's JUST NOT going to happen.. not creating a separate module.. It's an OPTIONAL feature.. Don't want it? Don't turn it on.. Why NOT use a sidebox?? Well it's pretty simple. Because some shop owners may turn off sideboxes on checkout pages, we'd have to code for those setups, and without knowing HOW they diabled their sideboxes what would we code for?? the variations on how they MIGHT have done this are numerous.. Sure we could ASSume that they are using the SAME method to turn off the sideboxes we are using in this module, but what if they are using a DIFFERENT means to turn off their sideboxes?? Then what?? Wait to see what those exeptions MIGHT be and then what?? add a piece of code to cover each exception discovered?? Wrestle on the support thread with trying to help shopowners come up with the exact piece of custom code THEY need to cover their unique setup??

Coding by exception is an inherently BAD idea.. which is why we opted for a much SIMPLER way to implement this feature all the while making this module FLEXIBLE enough So that anyone who doesn't want this feature can OPT OUT of it by turning it off.. I appreciate YOU don't want it.. But with all due respect, I have to look at this from a less myopic perspective. That means improving this module by including MODERN tested options that IMPROVE checkout conversions for those who want those features and making such features optional for those shopowners who DON'T want them.. Frankly providing a means to turn the feature off is MORE than an adequate remedy for your concerns. It's YOUR choice to decide that this is not enough of a remedy. It's open source.. feel free to hack away to make this module what you want... Don't want this feature?? hack it out..

dw08gm:

For stores that also turn off all sideboxes on the login page, such sidebox options would be superfluous.Right.. Honestly, this is a less than compelling argument for leaving this feature out.. That said, for shopowners using the SAME method we are to achieve this, I think this is gonna be in the NO BIG DEAL category for most folks.. All we do is move the list of pages to disable sideboxes from a PHP file to the admin where it's MUCH more accessible by novice shopowners and they can easily edit the list of pages to suit their needs.. It's an ease of use improvement anyway which is NOT a bad thing at all. If a shopowner is using another method to turn off sideboxes, this optional feature isn't going to HURT anything.. and AGAIN if they don't WANT to turn off sideboxes during checkout, this feature is OPTIONAL.. You are objecting to an OPTIONAL feature that YOU don't want, and for reasons that are frankly LESS than compelling. Honestly, I don't know what else to tell you..

dw08gm:

Also I am not a fan of auto-installers, generally because (coming from a non-programming background) I dont always get how they work, and much prefer the old sql-patch method where it is relatively easy to study the changes about to be made and relatively easy to alter or stage (rem/unrem) the sql-patch to only make changes that I understand or desire.Again.. you ar giving another less than compelling and myopic argument for NOT using an auto installer.. You DO know that the Zen Cart INSTALLATION is the GRAND-DADDY of all auto-installer scripts right??????

YOU not knowing how the installer works is NOT a GOOD reason to NOT include one with COWOA.. Want to know how the COWOA auto-installer works?? Well then study the auto installer and REM out what you don't want.. They really aren't a big mystery especially when you consider that a NON-PROGRAMMER created this one..

The auto-installer was added because it simplifies the installation, and lessens the chance of install issues. From a support POV the old SQL method is PASSE.. PERIOD.. It is a NIGHTMARE to have to contend with explaining the ins and outs of myPHPAdmin or the Zen Cart SQL installer to non-technical shopowners.. It is a NIGHTMARE to have to create and MAINTAIN MULTIPLE SQL SCRIPTS to try and cover the VARIETY of install and pre-install conditions that might exist. (did the site once have FEC installed?? Are they coming from an older version of COWOA?? are they running this on a v1.3.9 store???) The auto installer allows us to check for the existence of certain conditions and strategically run those parts of the SQL.. It ensures that more shop owners will have a successful and trouble-free installation.. Sorry that doesn't sit well with YOU and YOUR specific needs, but I have LARGER support concerns to contend with than your desire to hang on to an OUTDATED method of developing modules.. Adding features which lend themselves to lessening the chance of install failures IS NOT a bad thing despite your arguments against such moves..

One of these days I'm going to get REAL fancy and figure out how to use the methods that powerhouse devs like niccol and lhungil use in their mods so that the need to have to rename template folders to install modules is passe as well. gasp I expect that you will object to these attempts to simplify/modify the installation process as well, and you should know now, that I will be just as unmoved by your arguments against these improvements as I am unmoved by your arguments against optional features andimprovements today.. shrug

I would ask you to please let's just agree to disagree, but I'm not sure you will do that.. Again, I appreciate your thoughts, but with all due respect, your concerns don't really rise to the level of REAL bugs or even real issues.. The bottomline is that you just don't like the new OPTIONAL features. Being able to turn off an OPTIONAL feature is not an acceptable remedy to you, and I don't have an alternate to offer you.. Finally you don't like the new auto-installer because YOU don't understand it..

Duly noted..

DivaVocals:

I would ask you to please let's just agree to disagree, but I'm not sure you will do that.. Again, I appreciate your thoughts, but with all due respect, your concerns don't really rise to the level of REAL bugs or even real issues.. The bottomline is that you just don't like the new OPTIONAL features. Being able to turn off an OPTIONAL feature is not an acceptable remedy to you, and I don't have an alternate to offer you.. Finally you don't like the new auto-installer because YOU don't understand it..

I would agree with DivaVocals here. They are optional features (which I've been using on my clients site for years, they do improve conversions, so will use) in beta software. Your troubles with them and the auto-installed do not warrant either of them being removed. I see them both as improvements and appreciate DivaVocals continuing to take the time to maintain and update this plug-in.

jeking:

I would agree with DivaVocals here. They are optional features (which I've been using on my clients site for years, they do improve conversions, so will use) in beta software. Your troubles with them and the auto-installed do not warrant either of them being removed.
Yep.. Times are a-changing, and we now know a LOT more about user behavior and this module needs to keep up with those changes.. Some of the old mores about online shopping are still very much reflected in current versions of COWOA and within the default Zen Cart checkout.. It's time to adapt and "get with the times". That's what we're trying to do here.. We are in some places allowing for those folks who want to hang on to the "old ways".. (ie: optional features)

We also know a LOT more about DIY shopowners behavior too.. SIMPLIFYING the process to eliminate potential points of failure is to the benefit of the community as a WHOLE.. Not doing so simply because I like the "old method" is akin to me hanging on to my 1982 Portland color TV television and expecting DirectTV to "make it work" with my new whole home DVR system.. So while DirectTV eventually figured out a way to hook up my new wireless whole home DVR to a television where the only inputs and outputs are via a coaxial cable, the price I pay for this is a FUZZY picture on this T.V., because they have to use a converter box to convert from coaxial to composite in order to connect the TV to the Genie Mini.. This obliterates the signal, and results in noise lines on the screen..

Am I in the market for a replacement for this T.V.?? probably not anytime soon as it's really just an office "noise-maker" to help me pass the time while I work.. I've learned to adapt to the fuzz:laugh:.. But I do now recognize that I just can no longer hang on to this T.V. anymore simply because "it still works".. Same is true of COWOA.. So anyone who doesn't want to move FORWARD with the new features is welcome to grab the old codebase, update it to whatever version of Zen Cart they are using and stick with the "old way" of doing things.. v2.6 is not JUST about implementing a silly Zen Cart compatibility update, it's about IMPROVING the process..

jeking:

I see them both as improvements and appreciate DivaVocals continuing to take the time to maintain and update this plug-in.
and I appreciate that you and Dave have been contributing to this dev effort.. :clap:The next steps I see for this should be an effort to simplify the number of steps without obscuring, confusing, and obliterating the process (which many so-called "one-page" solutions do).. I think a GREAT starting point will be making the shipping and billing info pages ONE "step" (versus the 2 steps they are now) Melanie Prough provided some links to some articles with some great info on this.. I'll share them on the Github repo as a point of discussion on a direction in this regard..