Printable View
I have rolled back and all is working fine. I will wait till the release and see what occurs with others. 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. Now I am back to original COWOA it all works as it should.
For the info:
151 clean install
PHP 5.4.28
MySQL 5.1.73
Well Dave's testing mimics my own testing and I have this version in production for the stores I developed it for.. I suggest that you create a dev store and do your upgrade there so there's no pressure to fix a live store.. this is what you should be doing anyway before pushing updates to your live store..Quote:
Originally Posted by Rizla
Yes! Will do, but I will still await other comments... I am convinced there is an error in one of the files... Just my opinion. But I do like the work you have put into it and the presentation to the customer is far better.... Hope it works out.
Sorry.. gonna have to disagree with you.. Like I said I tested this a fair bit on the sites I developed it for.. Can't afford to have my clients live sites going down.. They are NOT having the issues you are reporting.. and JUST this morning, I just installed it on ANOTHER client's test site (I always keep a test site which is a parallel of the live production site running for all of my clients JUST for upgrades etc..) I did not have ANY of the issues you described.. Install script ran fine, no errors, blank pages, or errant behavior..Quote:
Originally Posted by Rizla
AND
This particular client site I have added additional customer fields (shipping phone number, email confirmation fields), and through careful merging of the files I didn't lose any of this functionality with the latest version of COWOA installed..
That said you are free to wait for more feedback, but I do believe the issue is in an errant merge that went awry in your install.. I CANNOT recreate ONE of the issues you described.. **shrug** Suggest you create a dev store and try again..
And here is the issue... Please note the highlighted section:
Source: http://www.zen-cart.com/showthread.p...42#post1252042
Quote:
Originally Posted by DivaVocals
I just noticed this in your post from earlier today..Quote:
Originally Posted by DivaVocals
Quote:
Originally Posted by Rizla
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..Quote:
Originally Posted by Rizla
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..
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..
Quote:
Originally Posted by DivaVocals
Amen to that!Quote:
Originally Posted by DivaVocals
I downloaded the Github version and installed it on a development site that was upgraded from 1.5.1 to 1.5.3. I wanted to let you know that the documentation didn't mention a couple of files that are modified by COWOA.
/includes/templates/custom_template/common/tpl_main_page.php
/includes/languages/english/custom_template/button_names.php
While the installation of the files went smoothly after the integration, when I went into admin to run the full install SQL file, admin stated that there was an error and to reload the page. When that failed, I checked the log and got the following error message.
[21-Jul-2014 21:10:35 America/Chicago] PHP Fatal error: 1054:Unknown column 'COWOA_account' in 'where clause' :: select count(*) as count from customers WHERE COWOA_account = '0' ==> (as called by) /home1/godsglor/public_html/develop/shop/admin/index.php on line 53 <== in /home1/godsglor/public_html/develop/shop/includes/classes/db/mysql/query_factory.php on line 155
I was still able to access the Install SQL Patches item from the Tools menu to upload the SQL file. After that, all was well. I'm not certain if it would be better to have the users install the SQL before uploading the modified files. While it didn't freak me out, it might concern others. :D
Finally, the tpl_header.php and tpl_main_page.php files in the /includes/templates/custom_template/common folder caused the styling to be off a bit with my template. I'm using Responsive Sheffield Blue. I had to replace both of them with the backups that I made. Replacing just one of those two caused the site to give a blank page. I'm not asking for any assistance with it for two reasons: 1) I want to see if the client is ok with the way it looks now and 2) it's probably something on my end. I'm going to compare the files tomorrow to see what the differences are.
I just wanted to report on the few issues that I've found, albeit minor ones. Thanks for developing a nice mod.
--Dustin
Might be because I haven't updated the docs yet..Quote:
Originally Posted by tromak
Noted, and I'll update the install instructions accordingly..Quote:
Originally Posted by tromak
The tpl_main_page.php changes turn off the sideboxes on the checkout pages if you turn on the admin flag.. You should be merging that change into your template's version of the file.. If you replaced it and your template modifies this file, I would expect that you WOULD see some unwanted style changes..Quote:
Originally Posted by tromak
The tpl_header.php changes only add some COWOA flags to the login/logoff links.. Again you should be merging those changes into your template's version of the file.. If you replaced it and your template modifies this file, I would expect that you WOULD see some unwanted style changes..
These are not issues with COWOA, but in how you merged in the files with your own template..
Dear all, can I ask how we can simply let user buy using email without asking for his address details and newsletter subscription?
Many thanks!
EK
Even better if possible, upon clicking checkout button, automatically bring him to the page asking for his email or just name without even requiring him to choose and click on the guest checkout option. is that actually achievable?
Thanks again!
EK
Some help please, as i have been trying for a full day and still unable to achieve the above of entering just the email for purchase without any other billing info...
Many thanks!
EK
For the checkout button, just modify the link for it and make it go to the no account landing page. As for your request, no help can be made unless you give more info on what exactly you are offering. In short, in order to process payments billing info is needed for every customer.Quote:
Originally Posted by EngKiat
Quote:
Originally Posted by EngKiat
If you are asking can COWOA be modified to include this capability then I have to agree with yaritai, you cannot SKIP the customer entering BILLING data.. see my previous response to someone else on this very same line of discussion..Quote:
Originally Posted by EngKiat
Quote:
Originally Posted by DivaVocals
Thanks a lot for reply!
Am actually helping to build a survey cart site that needs to provide anonymity to the shoppers~can we bypass any billing info and even exclude email address , for users to check out and 'buy' the product?
Thanks!
Ummm let me try answering this another way..Quote:
Originally Posted by EngKiat
NO!!! unless payment processors are suddenly not requiring this information to process payments (HINT: none are.. they ALL need billing info passed to them..)
Quote:
Originally Posted by DivaVocals
So what is the answer? I have the same exact issues as shinypenguin. v1.5.3 http://s l a d e w e b s-testarea.com/Quote:
Originally Posted by shinypenguin
That post is from TWO YEARS and a few COWOA versions ago.. So the answer is to install the latest version of COWOA.. However, as has been stated in this support thread already, COWOA in the Zen Cart downloads/plugins section HAS NOT been updated for the latest version of Zen Cart.. There is a BETA version updated for v1.5.3 in Github.. It is NOT for use in a production site..Quote:
Originally Posted by loribug1
It would help if you tell us what version you have installed too..
After merging files and installing sql patch (I had to do this manually via phpMyAdmin, since there were errors through zen cart admin panel) I got empty page in Admin -> Configuration -> COWOA Configuration.
Also, I don't have column query_builder in my database, what to do with that?
jesus, this plugin is buggy...
Alright, I figured nice tip for those who have blank COWOA Configuration page.
If you type into Developers Tools Kit "COWOA_STATUS" (for example) in all-files search, there should pop up red option for searching database tables. If you click on this, and later "Edit", it should prompt correct COWOA Configuration, which is not accessible through Configuration dropdown.
Another problem: Now the last step of COWOA order gives me blank page. Something with the database again?
Yeah.. so buggy that the Zen Cart devs are going to make this plugin part of the core..Quote:
Originally Posted by khejit
COWOA is not buggy at all if installed normally.. based on your post you didn't go through normal install steps..
Blank page means an error.. what's in your error logs..Quote:
Originally Posted by khejit
Alright, blank page was about my BitPay plugin. If I choose payment with BitPay it should redirect to their site to finalize payment.
It looks like COWOA is not compatible with standard Zone Rates shipping module from ZC. Always shows "The shipping rate cannot be determined at this time".Code:[23-Oct-2014 09:58:07 CST6CDT] createInvoice error array (
'type' => 'limitExceeded',
'message' => 'Invoice not created due to account limits, please check your approval levels',
)
[23-Oct-2014 09:58:07 CST6CDT] PHP Fatal error: Call to undefined function zen_remove_order() in /home/vibraint/public_html/includes/modules/payment/bitpay.php on line 152
Hmm, how to get into this?:huh:
OUT THE BOX, COWOA works with ALL the dafault Zen Cart payment and shipping modules.. INCLUDING the Zone Rates shipping module.. COWOA does NOT modify ANY CODE that would impact shipping and payment modules..Quote:
Originally Posted by khejit
My current installation of the cart with this plugin has come up with a hiccup. There are two orders that created an account and went through perfectly. however the order that went through without an account and the cc didn't process but the cart completed the order like it had. any ideas?
During the COWOA checkout process, on the Payment Information screen, it says "No_Account No_Account" in place of a customer name. This makes sense since the customer hasn't registered a name...but it strikes me as a bit rude. How can I change that to show something like "Valued Customer" on the COWOA and the confirmation e-mails? Thanks!
This kind of issue has never been reported previously. Which could mean that this is likely something that is unique to your store's configuration. Which means it's hard to guess why this is happening for you..Quote:
Originally Posted by WebGoddess
I have a habit of finding bugs no one else has seen. Is there any way to hard-code something in place? Because "No_Account No_Account" just isn't an acceptable salutation. LOL
Whoops, sorry...I misread the previous post and thought it was in reference to my question. :blush:
Can't say how to fix an issue that has never been reported before and one I can't recreate..Quote:
Originally Posted by DK_Scully
Okay, are you referring to WebGoddess's plugin error, or my "No_Account" error? LOLQuote:
Originally Posted by DivaVocals
I quoted your post.. I was responding to you.. Can't offer a suggested fix for an issue that has not been reported before, and one that I cannot re-create.. Perhaps you could provide a link to your site, and the EXACT steps you took to see this issue. That might help run this down..Quote:
Originally Posted by DK_Scully
http://www.carnal-pleasures.com/zencart (apologies that it's an adult site)
Order the free book in the left sidebar. You'll see the error crop up when you use the COWOA checkout. :-)
Thanks for the heads up about this being an adult site..Quote:
Originally Posted by DK_Scully
As temp workaround, go to this file: includes/modules/custom_template/no_account.php
Try modifying lines 217-218 as follows:
217 $firstname = Valued ;
218 $lastname = Customer;
Please note there is a space after "Valued". This is UNTESTED, but it should work..
Just wanted to add some notes here.. I will be looking into a BETTER long term solution. Apparently the module for the no_account.php page fills in No_account for ALL the fields except the email field when the cart total is zero. What I posted is a bandaid fix and will address the issue, but it is not a good long term solution IMHO.Quote:
Originally Posted by DivaVocals
Shouldn't there be quotes around the variable values:Quote:
Originally Posted by DivaVocals
Code:217 $firstname = 'Valued ';
218 $lastname = 'Customer';
That's what I thought too.. Interestingly they aren't in the current code..Quote:
Originally Posted by lat9
Personally I think that when the cart value is $0.00 that instead of blocking all fields except the e-mail address field the full name name AND email address should AT LEAST be collected when the cart value is $0.00. That is the long term solution I will be looking at..
I'm happy to be your guinea pig. :P
The good news is that the e-mail came out absolutely perfect. On the shopping cart, though, there was no space visible between the words Valued and Customer; for some reason it crammed them together into one word. But no complaints...this has been bothering us ever since we installed the COWOA. Even ValuedCustomer is much, much better than calling them a no-account! LOL
Now if I can just get rid of the "TEXT_CHECKOUT_LOGOFF_CUSTOMER" message that has suddenly appeared...
Try changing "Valued" to "Valued-"Quote:
Originally Posted by DK_Scully
or alternatively you can try what lat9 suggests (adding the single quotes) and change the values as follows:
217 $firstname = 'Valued ';
218 $lastname = 'Customer';
or
217 $firstname = 'Valued ';
218 $lastname = 'Customer';
Again, untested.. But see what happens.. If you get a blank page please post the text from the error log..
Quote:
Originally Posted by DK_Scully
not only fixed the name problem, but it got rid of that extra error message on the page bottom at the same time. Thank you so much for your help!!! :hug:Quote:
Originally Posted by DivaVocals
One last little thing...now when someone creates a new account (not using the COWOA), the first and last name are run together on the signup screen. LOL The e-mail shows up properly with the space between the first and last name...not sure why the signup screen looks different.
If you have any advice on that, I'd be very grateful. Thanks!
You don't say.. but is this a NEW issue that manifested AFTER making the changes to the "No_account" issue??Quote:
Originally Posted by DK_Scully
I honestly don't know. I didn't try to set up a new user account until someone reported a totally different error with the script last night, which I was able to fix. Then I noticed this little glitch. Since it was so similar to what the No_Account process showed, I thought I'd mention it and see if you had any ideas.
No.. because this too has NEVER been reported, and it's unlikely a bug, but something impacted by changes you may have made (including the "No_account" issue).. Suggest rolling back the previous change to see if it persists.. If it does, then you need to look at if you have you modified any of the files that make up this module or are a part of the checkout process???Quote:
Originally Posted by DK_Scully
OK.. sorry this is a bit behind the times... had a major crash and had to rebuild my OS....
Yes, No_Account is a bug in the programming that should only appear if you have two conditions existing... the cart is at 0 dollars and you have the checkout using email only checked! this was occurring when you have free products and no account needed for getting them.... I've also had this ghost on me when I was trying to create a one page checkout... I wasn't passing the cart info along right...
On a normal install, this shouldn't popup unless you are giving things away or email only checkout....
So basically, this bit is setting everything to a default value, getting info 'No_Account' from your language file... reason I haven't even tried fixing this yet, I haven't needed it to work right, Theirs better mods to use for free downloads...Code:/* COWOA - Set all fields to No_Account for free products */
if ($_SESSION['cart']->show_total() == 0 and COWOA_EMAIL_ONLY == 'true') {
I didn't see any info on what you did to get the code to fire... commenting out the code would work too, but still not solving the cause of the problem, unchecking the allow email only checkout may work too...
I agree.. This is why I never bothered to fix it.. I simply found another way of creating free products.. The plus to the method I am using is that it doesn't require going through the checkout process.. The downside to the method I am using is you kinda lose the means to track AT LEAST the number of downloads.. In the end, I decided to forego tracking in exchange for avoiding the COWOA stuff that goes along with free products in general.Quote:
Originally Posted by davewest
Can you PM me the free download mods you suggest..
I've been away from sites that use COWOA for a while, but have received a request and want to make sure that the problem-to-be-solved will (ahem) be solved by the plugin.
The site that's requested the install is seasonal (like yearly seasonal) and as they're coming into high-season there are a lot of return customers that don't remember if they have an account and, if so, what their password is.
Can a customer with a registered account still check out using COWOA?
Once they create a permanent account with a email address, the customer can not use cowoa to checkout under that email address any longer. They can use a different email address to checkout.Quote:
Originally Posted by lat9
Darn, that's not the answer I wanted to hear.:down: I guess I'm looking at some one-off customizations.
OR you can perhaps run a SQL script to turn them into COWOA customers...Quote:
Originally Posted by lat9
Yes, SQL would be the quickest... the only question would be the password when one of the old customers change back to existing... but I don't recall seeing any past password checks for customers!Quote:
Originally Posted by lat9
Coding in a switch at the top of the customer page to convert all back to COWOA would be simple... adding one to the edit page would work to do one at a time... is this something to add!
I'm wont to unilaterally revert all accounts to COWOA just to appease the few, but your suggestion started a couple of brain cells firing. I could update the COWOA processing to check for an existing account and, if found, let the customer know and give them the option to convert their account to COWOA. My main concern with that processing is that it opens the site up for "malicious account resets".Quote:
Originally Posted by davewest
Well COWOA already does a check for an existing account.. When using the guest checkout if the visitor uses an email attached to a standard account, they are presented with a message that notifies the visitor of the existence of this account. The message also provides a link to the regular login form so they can login (where they can then reset their password if they've forgotten it) or notifies them that optionally they can use a DIFFERENT email address to continue to use the guest checkout.Quote:
Originally Posted by lat9
Yap.. ZC has a nice system for that already... I need to think about KISS more often.... :mellow:Quote:
Originally Posted by DivaVocals
Yep KISS!! People who shop online create internet accounts all the time (including yours truly) then occasionally forget the password (or even the login name) they've used. IMHO shopowners should concentrate on making sure the password reset process is simple or make sure that shoppers have other guest checkout options (like using a different email address). I think that the effort is better spent on streamlining the processes versus implementing processes which are designed to keep folks from having to go through the required actions needed to reset their password.. I don't think there's any empirical proof that the act of having to reset a password will make folks shop elsewhere..Quote:
Originally Posted by davewest
Speaking from my own online shopping behavior, if I want a particular product from this particular store (especially specialty stuff), I will simply reset my password (while silently cursing at myself for forgetting it). As long as the process for resetting the password is simple, then this should be a very painless exercise..
Just had a customer email me about the existing account issue when using guest checkout. She did not recall ever ordering from us. She is right, she never did but must have started the checkout process 2 years ago and went past account creation but never completed a purchase. She was utterly confused why it would not let her continue as a guest.
I totally agree that this is confusing. Why can't we let them checkout as guest anyway, even if they have an account but don't want to bother resetting the password? I would not care if there is another "guest" account created with the same email. Would it be possible to turn off the check for existing email if COWOA is used? Would this throw off other features?
The on-screen message in the latest version makes very clear what happened and why.. Open to options for different/improved wording if you think it's still not clear for customers..Quote:
Originally Posted by mydanilo
There are certain options that are dependent on whether the customer record created is a COWOA customer account or a STANDARD customer account. You are free to spend some time doing what would probably be a pretty massive rewrite to take into account all the business rules..Quote:
Originally Posted by mydanilo
Yep.. These are your options..Quote:
Originally Posted by mydanilo
- Your customer could simply reset the password for the account they created
- Your customer could use a different address to checkout (as suggested in the on-screen message)
- You can go into the DB and MANUALLY set this ONE customer to a COWOA type of customer. (perhaps in a future version the POSSIBILITY of doing this from the admin would be possible -- requires analysis to determine the IMPACT of such a change to a customer record if there are already orders in place)
Ok, I understand. This case just made me realize that this potentially turns off some repeat customers and was looking into finding a solution. I hoped a standard and COWOA account would be possible.
One customer having BOTH STANDARD & COWOA checkout options is possible if they use a DIFFERENT email address.. STANDARD vs COWOA is tied to the customer, not the ORDER.. Hence why it's NOT supported.. (and I'm not seeing a real business case to change the COWOA workflow to support this kind of alternate workflow)Quote:
Originally Posted by mydanilo
Do you have customers actually REQUESTING this or is this an assumption you are making based on ONE customer (which is clearly a ONE OFF instance)?? Because IMHO making changes to your store based on assumptions without empirical data is kinda a waste of effort..
I think it would be possible to code in switches to do COWOA only, Standard and COWOA, Standard only. Every account type has a password, even COWOA, so if you tried to do both for same email address, the password would be reset each time they checked out as guest!Quote:
Originally Posted by mydanilo
Every customer will have a different idea on checking out, if we can Keep It Stupidly Simple, they will get through it!
I don't think we would lose customers if we can explain what's happing and offer a password reset.
Well, I did not have many that called and asked why they can't proceed with placing an order but it opened up the question on how many get frustrated and leave? Last one mentioned that she only has one email address that she has been using forever and she also does not want to go through a stupid password reset as she put it. So not everybody has a second email handy ether. Some less computer savvy shoppers get stuck easier than we tech people think. Was just a thought to make it more fool proof.Quote:
Originally Posted by DivaVocals
One last thought. I have many customers with standard accounts going back many years, say they come back and don't remember that they created an account nor remember what password they used, they might simply try and use the COWOA to avoid any password reset procedures. It think this is not an unreasonable scenario. I do that too on sites where I just want to get this order done but don't want to jump through hoops getting my old account up to date. Also consider that a password reset is not so quick and simple. People need to wait for the email then use the cryptic generated pwd to get into the account, then would have to set their own new password that they actually will remember the next time. This all while they are really busy wanting just to do a quick checkout. I think this scenario is very real.
The less obstacles the better for conversion IMHO.
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?
And IMHO a tool to specifically deal with customers who have abandoned their cart is a BETTER tool to address the issue.. ESPECIALLY when you don't really know why they left. Sure it's easy to assume that the issue was because they forgot their account password, don't remember setting up an account, etc.. But what IF this isn't the real issue?? A guest checkout module can't analyze/resolve cart abandonment or other checkout issues..Quote:
Originally Posted by mydanilo
Sure.. After 17 years dealing directly with end users, I am well aware of less tech savvy user behavior..:cool: How this is manged in COWOA is not vastly different than how it works for some large retailers -- including the grand-daddy of online shopping sites -- Amazon.. If you have created an account on their site, you cannot use that same email for a guest checkout. So your options are to reset your password OR use a different email address.. (see screenprint)Quote:
Originally Posted by mydanilo
Attachment 14755
Right and again.. how COWOA handles it TODAY isn't vastly different than other online retailers..Quote:
Originally Posted by mydanilo
Right, and in a SECURE ecommerce site, I would HOPE that there is a little due diligence happening in the password reset process.. What you describe is how other secure e-commerce sites manage a password reset.. It's not like Zen Cart is doing something NO ONE else does... Perhaps the default flow could force a password change upfront upon entering the temp password. Currently it requires the customer to remember to go to the "Change Password" link which they may easily skip/forget..Quote:
Originally Posted by mydanilo
Right.. But I'm not sure that COWOA is doing anything any different than what the major retailers are doing.. They typically don't allow you to checkout as a guest with an email linked to a regular store account, and if your forget your password, you must go through similar steps as Zen Cart to reset it..Quote:
Originally Posted by mydanilo
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..Quote:
Originally Posted by 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..Quote:
Originally Posted by mydanilo
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..
Quote:
Originally Posted by DivaVocals
Quote:
Originally Posted by DivaVocals
Quote:
Originally Posted by DivaVocals
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_ACCOUNTQuote:
Originally Posted by jeking
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.Quote:
Originally Posted by Rizla
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??Quote:
Originally Posted by bwaikel
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..
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.Quote:
Originally Posted by jeking
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..Quote:
Originally Posted by davewest
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.
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..)Quote:
Originally Posted by dw08gm
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..Quote:
Originally Posted by dw08gm
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???
No idea what you are talking about..Quote:
Originally Posted by 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.
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.Quote:
Originally Posted by DivaVocals
Cheers
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.Quote:
Originally Posted by dw08gm
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.
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..Quote:
Originally Posted by dw08gm
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..
Right.. 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??Quote:
Originally Posted by dw08gm
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..
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..Quote:
Originally Posted by dw08gm
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??????Quote:
Originally Posted by dw08gm
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..
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.Quote:
Originally Posted by DivaVocals
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)Quote:
Originally Posted by jeking
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..
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..Quote:
Originally Posted by jeking
As always, you make compelling argument, I like your passion and drive, and really do appreciate your efforts to drag lesser folk kicking and screaming into the 21st century. Also good to read views of others. Sometiimes things just need to be beaten into shape, however brittle or immalleable...
Suggestion:
In the COWOA fieldset in \includes\templates\MyTemplate\templates\tpl_login_default.php
Whether
<?php (COWOA_STATUS == 'true')) { ?>
should be replaced by
<?php if (($_SESSION['cart']->count_contents() > 0) && (COWOA_STATUS == 'true')) { ?>
to only allow COWOA when customer has products in cart. Otherwise COWOA is visible to visitors proceeding directly to login. Or is this the intention of the original code.
This is a change I've applied to client stores.. Actually I thought it HAD been added to the Github repo.. Thanks for the reminder..Quote:
Originally Posted by dw08gm
Quote:
Originally Posted by dw08gm
Well this change IS in the COWOA code.. and I'm thinking that since you are looking for it to be in the "tpl_login_default.php" file that whatever changes you made when installing the beta version is the reason why you're not seeing the code.. (which is in the new tpl_login_default.php file) Sounds like you are not using some of all of the current COWOA beta code..Quote:
Originally Posted by DivaVocals
I am working with version 1.5.4 and just installed the COWOA addon.
When testing and going through the checkout process I get this warning and don't know how to fix it.
ENTRY_EMAIL_ADDRESS_COWOA_ERROR_EXISTS
Can anyone help with a fix?
Thank you in advance.
Which version of COWOA did you install?Quote:
Originally Posted by Maynards
I install COWOA 2.4
Your using an existing email address account to test COWOA with. The ZC system is designed to use the email address to create accounts same with COWOA. this prevents duplicate accounts and other problems. the fact your seeing ENTRY_EMAIL_ADDRESS_COWOA_ERROR_EXISTS means you are missing the define in your template english.php file, should be around line 200.Quote:
Originally Posted by Maynards
Try a different email address, check that you don't have an existing account, if the message stills triggers, make sure modules/YOUR_TEMPLATE/no_account.php was not modified or fully loaded.
The code is functioning as it should if an account with that email address exist!
Thanks davewest
I was using and existing email. I did not know it worked like that. This mod is new to me.
I typed in a fake email and it went through.
Thanks again. Greatly appreciated.
Perhaps a silly question but is not a customer supposed to be able to come back and create an account after checking out COWOA before? This is the old version I'm talking about, not your beta version - which I'm going to go get.
Yes.. back as far as I can remember that's how it works..Quote:
Originally Posted by delia
When a current cowoa costumer comes back and decides to create an account ether during checkout or standard, the past orders, shipping addresses all become theirs based on the email address given.
Well, that's what I thought!
Quote:
Originally Posted by dw08gm
Quote:
Originally Posted by DivaVocals
Just noticed my typo (in red).. Just for posterity, the file I MEANT to type is: tpl_login_cowoa_default.phpQuote:
Originally Posted by DivaVocals
Has anyone tried this plugin with version 1.5.4?
If you read through the last 2-3 pages of this thread or search for "1.5.4", you'll this question has been addressed..Quote:
Originally Posted by ianhg
Ok maybe I will re- phrase my question has anyone had any issues using cowoa 2.4 with version 1.5.4? I see that some post refer to version 1.5.3 and a beta version.
You CAN'T use v2.4 with 1.5.4 hence the discussions regarding the beta version..Quote:
Originally Posted by ianhg
For me, working fine and will take it live this weekend. Heavy modified ZC 1.5.4, responsive design.Quote:
Originally Posted by ianhg
Follow the install instructions, make backups, install and test on a test site before moving the files over to your main site. Use a compare program to compare files and don't just drop them.
If something not working right, come back and ask.. remember to give as much info as you can, we can't see what you did!
Gee your fast... so I'm corrected... the code works, but their is difference in ZC versions is why you shouldn't just drop files.... but the beta is working for me....
Thanks for following be reply, might leave until beta version has been fully approvedQuote:
Originally Posted by DivaVocals
Thanks good luck when you go live
Just so you know, it will be a while.. Pretty busy right now with paid work.. That's why I published the code on Github..Quote:
Originally Posted by ianhg