COWOA (for ZC v1.5.x)

Quote:

---

Originally Posted by robbie269

I cannot find where I can comment in GITHUB sorry.

---

Click the "Issues" tab, and if your issue isn't in the list of open issues (or in the list of closed issues, by clicking the Closed tab), then click the New Issue button to create one.

Quote:

---

Originally Posted by robbie269

Testing the new COWOA for v1.5.5 today. I cannot find where I can comment in GITHUB sorry.
One thing I did notice is that the sidebox off option during checkout includes the Logged of page. When I logoff the confirmation page fills half the screen and the rest is white. It has a "broken" look about it and I think the sideboxes should be on for the log off confirmation page as who cares if they go back to browsing.

---

If you'd prefer the logoff page with sideboxes, edit your \includes\templates\YOUR_TEMPLATE\common\tpl_main_page.php by removing logoff from the following list:

Code:

---

if (COWOA_SIDEBOX_OFF == 'true') { 
if (in_array($current_page_base,explode(",",'no_account,create_account,account,account_password,account_edit,address_book,account_history_info,account_newsletters,account_notifications,account_history,login,logoff,checkout_shipping,checkout_shipping_address,checkout_payment,checkout_payment_address,checkout_confirmation,checkout_process,shopping_cart,address_book_process')) ) {
    $flag_disable_right = true;
    $flag_disable_left = true;
  }
}

---

Quote:

---

Originally Posted by jeking

If you'd prefer the logoff page with sideboxes, edit your \includes\templates\YOUR_TEMPLATE\common\tpl_main_page.php by removing logoff from the following list:

Code:

---

if (COWOA_SIDEBOX_OFF == 'true') { 
if (in_array($current_page_base,explode(",",'no_account,create_account,account,account_password,account_edit,address_book,account_history_info,account_newsletters,account_notifications,account_history,login,logoff,checkout_shipping,checkout_shipping_address,checkout_payment,checkout_payment_address,checkout_confirmation,checkout_process,shopping_cart,address_book_process')) ) {
    $flag_disable_right = true;
    $flag_disable_left = true;
  }
}

---

---

Which is exactly what I was going to state as well..

Quote:

---

Originally Posted by ianhg

Thanks Guys for the links and speedy reply. Happy to test but which GitHub link is the best option?
Thanks.

---

BIG THANKS really goes to jeking who made up for my lack of free time..

I thought we added observers to COWOA! Maybe I missed something...

I've been busy converting mine which is not to bad, has some new interesting code in 1.5.5 that should make things interesting.. With the way COWOA is setup now, it behaves more like a standard account without the customer knowing it.. which leaves more control for admin and leaves many of the normal behaviour of ZC as is.

With this comes other issues such as accessing the account pages when one should not be able to. This issues occurs during checkout when the customer enters shipping/billing addresses and then email address. Once the checkout processes receives an email address, the session now has a customer ID.. If the customer drops the cart and does something else, like hard enters the url for the account pages, they then have access to areas they shouldn't get to as guests. The observer should catch that and redirect them back to the login page. Also at this time, the dropped cart is saved in the database. When the same email address is used again during checkout the saved cart is retrieved and then added to the new cart... normal for standard accounts, not for guest. another observer to catch and delete saved carts during the checkout process for COWOA accounts only..

Testing with COWOA v2.7 on a clean install of ZC 1.5.5 using the responsive template.

Attaching the observer and loader used in ZC 1.5.4 and 1.5.5 and COWOA 2.4 - 2.7 for testing.

Hi
I'm seeing that lines 69-86 of index_dashboard.php have a misspelling for the "class=right", such as :

Code:

---

      echo '<div class="row"><span class="left">' . BOX_ENTRY_COUNTER_DATE . '</span><span class="rigth"> ' . $counter_startdate_formatted . '</span></div>';

---

The code seems to have been corrected at least once and then reverted to "class="rigth" (commit: c4a35894a14d371c65ef90c13df1adba2016db38). I've searched the latest version of both v155 and COWOA 2.6/7 on github and can find definitions in many places (e.g. stylesheet.css) and usages for class="right" but class="rigth" appears only in index_dashboard.php and has no corresponding definition anywhere.

So, maybe another attempt to correct the spelling is in order?

Quote:

---

Originally Posted by davewest

I thought we added observers to COWOA! Maybe I missed something...

I've been busy converting mine which is not to bad, has some new interesting code in 1.5.5 that should make things interesting.. With the way COWOA is setup now, it behaves more like a standard account without the customer knowing it.. which leaves more control for admin and leaves many of the normal behaviour of ZC as is.

With this comes other issues such as accessing the account pages when one should not be able to. This issues occurs during checkout when the customer enters shipping/billing addresses and then email address. Once the checkout processes receives an email address, the session now has a customer ID.. If the customer drops the cart and does something else, like hard enters the url for the account pages, they then have access to areas they shouldn't get to as guests. The observer should catch that and redirect them back to the login page. Also at this time, the dropped cart is saved in the database. When the same email address is used again during checkout the saved cart is retrieved and then added to the new cart... normal for standard accounts, not for guest. another observer to catch and delete saved carts during the checkout process for COWOA accounts only..

Testing with COWOA v2.7 on a clean install of ZC 1.5.5 using the responsive template.

Attaching the observer and loader used in ZC 1.5.4 and 1.5.5 and COWOA 2.4 - 2.7 for testing.

---

Pushed to master in Github.

Quote:

---

Originally Posted by DivaVocals

Merged your PR this morning to my master repo. (https://github.com/DivaVocals/zen_COWOA) Made a few minor changes to both the v2.6 and 2.7 versions as well:

• Apply the usability updates present in COWOA v2.6 to v2.7 (changes to template and language files)
• MINOR updates to v2.6

This all needs to be tested.. I would LOVE to submit this puppy to the downloads, but before I will submit it I REALLY need the community to install it.. test it and provide REAL feedback so I know it that this has been thoroughly tested.

---

Diva and others. I've installed and tested this on 1.5.5 (minus the changes mentioned and and not seen any issues). I'll download the merged copy and see what's changed since I sent Jim my updates.

Quote:

---

Originally Posted by lucidlee

Hi
I'm seeing that lines 69-86 of index_dashboard.php have a misspelling for the "class=right", such as :

Code:

---

      echo '<div class="row"><span class="left">' .  BOX_ENTRY_COUNTER_DATE . '</span><span class="rigth"> ' .  $counter_startdate_formatted . '</span></div>';

---

The code seems to have been corrected at least once and then reverted to "class="rigth" (commit: c4a35894a14d371c65ef90c13df1adba2016db38). I've searched the latest version of both v155 and COWOA 2.6/7 on github and can find definitions in many places (e.g. stylesheet.css) and usages for class="right" but class="rigth" appears only in index_dashboard.php and has no corresponding definition anywhere.

So, maybe another attempt to correct the spelling is in order?

---

The mispelling of this class has been present in Zen Cart going back to at least v1.3.8 or v1.3.9. I corrected it in COWOA because it simply drove me NUTS..:laugh: Looks like I missed correcting it in the new v1.5.5 index_dashboard.php file. I just submitted a pull request to the repo to make this correction. Please download and confirm.

Also I want to make some additional updates to index_dashboard.php to pull the search form out of the table it's nested in. Forms inside of tables is invalid HTML, and I made similar corrections to the index.php file in the v1.5.4 compatible version of COWOA.

Quote:

---

Originally Posted by DivaVocals

Also I want to make some additional updates to index_dashboard.php to pull the search form out of the table it's nested in. Forms inside of tables is invalid HTML, and I made similar corrections to the index.php file in the v1.5.4 compatible version of COWOA.

---

Sorry I meant to say orders.php. I want to move the search form out of the table as was done in the v1.5.4 compatible version of COWOA.

Quote:

---

Originally Posted by jeking

Thank you. This one: https://github.com/DivaVocals/zen_COWOA

---

Tested with zencart version 1.5.5 seemed OK except I had an issue with missing Language files for checkout_success.php I needed to add the following:
define('HEADING_ORDER_NUMBER', 'Order #%s');
define('HEADING_DELIVERY_ADDRESS','Delivery Address');
define('HEADING_BILLING_ADDRESS','Billing Address');
define('HEADING_PAYMENT_METHOD','Payment Method');
define('HEADING_ORDER_DATE','Date:');
define('HEADING_ORDER_HISTORY','');
define('HEADING_QUANTITY','Qty');
define('HEADING_PRODUCTS', 'Item Name');
define('HEADING_TOTAL', 'Total');
define('TABLE_HEADING_STATUS_DATE', 'Date');
define('TABLE_HEADING_STATUS_ORDER_STATUS', 'Order Status');
define('TABLE_HEADING_STATUS_COMMENTS', 'Comments');
define('QUANTITY_SUFFIX', ' ea. ');
define('ORDER_HEADING_DIVIDER', ' - ');
Will be testing with PayPal soon.

quick question and hopefully someone will have a quick and easy answer. I have a client who simply wants only the checkout without account. This is not normal ecommerce but use of the shopping cart to sell information (sensitively) to cancer patients. For one reason or another - either they live or they die - they don't need to come back necessarily to buy another report.

So the client wants only the checkout without account so I need a redirect to only that page - not the login or the create account screen. I think I've done this before but it was a really long time ago. So quick answer to where to change the redirect and is there really only one place as I think I remember?

Quote:

---

Originally Posted by delia

quick question and hopefully someone will have a quick and easy answer. I have a client who simply wants only the checkout without account. This is not normal ecommerce but use of the shopping cart to sell information (sensitively) to cancer patients. For one reason or another - either they live or they die - they don't need to come back necessarily to buy another report.

So the client wants only the checkout without account so I need a redirect to only that page - not the login or the create account screen. I think I've done this before but it was a really long time ago. So quick answer to where to change the redirect and is there really only one place as I think I remember?

---

I had a client with the same request. However, it was a typical ecommerce site and I strongly recommended against it. He asked to to revert back a couple of weeks later after customer complaints.

If you search this tread, you should find the solution I used.

Well, it's certainly not what I want to do, believe me. We had a big wrangle about it.

What I did was go in and change the checkout link in the shopping cart page to this:

PHP Code:

---

<a href="' . zen_href_link(FILENAME_NO_ACCOUNT, '', 'SSL') . '">' . zen_image_button(BUTTON_IMAGE_CHECKOUT, BUTTON_CHECKOUT_ALT) . '</a>'; ?> 


---

I am adding a page (because this site has been up for years) that is for folks who have bought before just in case they come back and need to buy something else. That will have links to the login and my account, etc. But removed the links to the shopping cart as well so it's a crappy user experience for someone who did.

V

Quote:

---

Originally Posted by ianhg

Tested with zencart version 1.5.5 seemed OK except I had an issue with missing Language files for checkout_success.php I needed to add the following:
define('HEADING_ORDER_NUMBER', 'Order #%s');
define('HEADING_DELIVERY_ADDRESS','Delivery Address');
define('HEADING_BILLING_ADDRESS','Billing Address');
define('HEADING_PAYMENT_METHOD','Payment Method');
define('HEADING_ORDER_DATE','Date:');
define('HEADING_ORDER_HISTORY','');
define('HEADING_QUANTITY','Qty');
define('HEADING_PRODUCTS', 'Item Name');
define('HEADING_TOTAL', 'Total');
define('TABLE_HEADING_STATUS_DATE', 'Date');
define('TABLE_HEADING_STATUS_ORDER_STATUS', 'Order Status');
define('TABLE_HEADING_STATUS_COMMENTS', 'Comments');
define('QUANTITY_SUFFIX', ' ea. ');
define('ORDER_HEADING_DIVIDER', ' - ');
Will be testing with PayPal soon.

---

Good catch.. Made these updates..

Hi everybody

There seems to be a security issue with Cowoa. I just tested with ZC 1.5.5 and Cowoa 2.7 (latest in Github):

1. Person A makes an order from Zen Cart using Cowoa checkout using email [email protected]
2. Person B user makes a new account to Zen Cart using the same email address [email protected]
3. Person B now sees order that Person A made in step 1. which is the security issue I am talking about

This is due to registering doesn't use email confirmation by default... It isn't normally a issue if someone registers with a faulty email they have no access to, not really a major issue. However when using Cowoa, this reveals sensitive data about users and their order history.

I am currently trying to figure how to fix this problem in my customers site, and basically I'm rather unsure how to fix it. I suppose email-confirmation must be required when cowoa-account exists before upgrading it to a normal account. Or mark orders to cowoa-orders, and not display them to a non-cowoa users.

Quote:

---

Originally Posted by Jarkko

Hi everybody

There seems to be a security issue with Cowoa. I just tested with ZC 1.5.5 and Cowoa 2.7 (latest in Github):

1. Person A makes an order from Zen Cart using Cowoa checkout using email [email protected]
2. Person B user makes a new account to Zen Cart using the same email address [email protected]
3. Person B now sees order that Person A made in step 1. which is the security issue I am talking about

This is due to registering doesn't use email confirmation by default... It isn't normally a issue if someone registers with a faulty email they have no access to, not really a major issue. However when using Cowoa, this reveals sensitive data about users and their order history.

I am currently trying to figure how to fix this problem in my customers site, and basically I'm rather unsure how to fix it. I suppose email-confirmation must be required when cowoa-account exists before upgrading it to a normal account. Or mark orders to cowoa-orders, and not display them to a non-cowoa users.

---

I made a quick fix to this problem in my installation by modifying includes/modules/pages/account/header_php.php and includes/modules/pages/account_history/header_php.php with following line added to sql-query in both files:

Code:

---

AND    o.COWOA_order = 0

---

So account and account_history will only show orders that are not Cowoa-orders.

Also while testing I noticed that order_status -page can easily be brute-forced to give out information about orders for desired email. So I also took that feature off from the admin area, and deleted the includes/modules/pages/order_status -folder (since it kept working even after feature was disabled).

Quote:

---

Originally Posted by Jarkko

I made a quick fix to this problem in my installation by modifying includes/modules/pages/account/header_php.php and includes/modules/pages/account_history/header_php.php with following line added to sql-query in both files:

Code:

---

AND    o.COWOA_order = 0

---

So account and account_history will only show orders that are not Cowoa-orders.

---

While I don't have a fix to share, I do want to point out that this suggested fix is a bandaid solution IMHO, and probably not a desireable long term solution. If one starts out as a guest customer and decides to convert to a standard account using the same email address, I would think that the desired behavior is to see their entire order history (guest sales as well as standard account sales).

On an unrelated side note.. 2 more posts to my 10,000th post on this forum!! :clap:

It depends on your idea of security risk or user convenience.

My two pennies..

Yes, COWOA always had that issue so does other sites that use email address as the user ID. I don't think I've actually had a shopping site do a opt-in opt-out check on account creation or checkout like non-shopping sites do.. wouldn't be hard to code in, but its another announce to the shopper!

What I mean by opt-in opt-out, during the account sign up or creation you enter an email address, an email is sent with a standard is this you message, if so type in this number or click this link to finish or activate your account! I don't think you would get a customer to finish checking out if that happens... This is the only way I know of to prevent email address ID abuse for any site.... not just COWOA!

COWOA assumes that the email address is one of a kind which it is unless you gave it up and someone decide to reuse it for themselves, then comes to your shop and creates an account.. If your storing more then shipping addresses, order details.. like CC numbers!! then yes I can see this as more then a COWOA security issue. I've also thought about what if someone decides to use someone email address and creates an standard account or cowoa checkout... buys and ships to there address! As a business owner I'm assuming you are managing the billing/payment side with fraud protection.. I am!

Accessing a COWOA account by using the login side of ZC should be very hard.. COWOA accounts are protected with a password, for me, its a large hash, random character set, then salted... making a very hard password. I think ZC155 does this now which means I'll be switching that could out and using ZC call.

I agree that the order status code can use better sanitizing and protection... will work on that.

If you don't want your customers to see past orders, wouldn't be hard to code in a switch for that, but if you don't want them to find out the order status, then you can turn off or un-code that for your site if you wish to leave customers in the dark.. I don't hide the order status page and it's available to both cowoa and standard customers... I don't see a need or reason for someone to turn that feature off, but you can by not adding the page and link to your site.

Quote:

---

Originally Posted by davewest

It depends on your idea of security risk or user convenience.

My two pennies..

Yes, COWOA always had that issue so does other sites that use email address as the user ID. I don't think I've actually had a shopping site do a opt-in opt-out check on account creation or checkout like non-shopping sites do.. wouldn't be hard to code in, but its another announce to the shopper!

What I mean by opt-in opt-out, during the account sign up or creation you enter an email address, an email is sent with a standard is this you message, if so type in this number or click this link to finish or activate your account! I don't think you would get a customer to finish checking out if that happens... This is the only way I know of to prevent email address ID abuse for any site.... not just COWOA!

COWOA assumes that the email address is one of a kind which it is unless you gave it up and someone decide to reuse it for themselves, then comes to your shop and creates an account.. If your storing more then shipping addresses, order details.. like CC numbers!! then yes I can see this as more then a COWOA security issue. I've also thought about what if someone decides to use someone email address and creates an standard account or cowoa checkout... buys and ships to there address! As a business owner I'm assuming you are managing the billing/payment side with fraud protection.. I am!

Accessing a COWOA account by using the login side of ZC should be very hard.. COWOA accounts are protected with a password, for me, its a large hash, random character set, then salted... making a very hard password. I think ZC155 does this now which means I'll be switching that could out and using ZC call.

I agree that the order status code can use better sanitizing and protection... will work on that.

If you don't want your customers to see past orders, wouldn't be hard to code in a switch for that, but if you don't want them to find out the order status, then you can turn off or un-code that for your site if you wish to leave customers in the dark.. I don't hide the order status page and it's available to both cowoa and standard customers... I don't see a need or reason for someone to turn that feature off, but you can by not adding the page and link to your site.

---

**nods in agreement**:yes:

I should have been clear that I don't think this is a SECURITY issue.. It MIGHT be a NUISANCE issue if you actually have folks doing this..

I have no knowledge of anyone reporting this "issue" with regards to COWOA or Fast & Easy Checkout in any support post on this forum.

I don't think that there is any GAIN by any hacker or prankster trying to access a CUSTOMER side account. I suspect that the Zen Cart admins and community would have reported such and it would have been addressed.

Quote:

---

Originally Posted by delia

Well, it's certainly not what I want to do, believe me. We had a big wrangle about it.

---

Can't remember where it came from, but I already have a switch for COWOA only site... Basically turns off all and any login/logoff fields and checkout is pushed through as COWOA only. I use it at times for testing things and just kept it in the code.

Quote:

---

Originally Posted by davewest

I agree that the order status code can use better sanitizing and protection... will work on that.

---

OK... so looking at mine and the 2.6 order status pages, I had a bit of difference between them. So what I did was updated both to more consistent code with other ZC files. Changes to both template and header file was allot so fully replace for ZC 1.5.4 and 1.5.5.. I don't have anything less then 1.5.4 installed so not tested below that point.

What's new!
Spam and bot code testing by honey pot, not sure spam bot testing is really needed, but can't heart.
Delay for rapid hit abuse, change the delay time in the header define.
I think better sanitizing of the input fields.
Off switches for display of product, shipping, and payment fields.. defines are in the template, could code into the config, but not sure why!
Testing for customer that are logged in already, redirects them to the order history page instead of order status.
tests for non-existent email address's.
Added 'number' and 'email' to input fields for mobile tech... remove if this drives you nuts...

No changes in display was done, tables show up as responsive for me so left them alone. attaching zip

Quote:

---

Originally Posted by davewest

Can't remember where it came from, but I already have a switch for COWOA only site... Basically turns off all and any login/logoff fields and checkout is pushed through as COWOA only. I use it at times for testing things and just kept it in the code.



OK... so looking at mine and the 2.6 order status pages, I had a bit of difference between them. So what I did was updated both to more consistent code with other ZC files. Changes to both template and header file was allot so fully replace for ZC 1.5.4 and 1.5.5.. I don't have anything less then 1.5.4 installed so not tested below that point.

What's new!
Spam and bot code testing by honey pot, not sure spam bot testing is really needed, but can't heart.
Delay for rapid hit abuse, change the delay time in the header define.
I think better sanitizing of the input fields.
Off switches for display of product, shipping, and payment fields.. defines are in the template, could code into the config, but not sure why!
Testing for customer that are logged in already, redirects them to the order history page instead of order status.
tests for non-existent email address's.
Added 'number' and 'email' to input fields for mobile tech... remove if this drives you nuts...

No changes in display was done, tables show up as responsive for me so left them alone. attaching zip

---

Not sure how much of this zip file should be incorporated into the current COWOA beta.. Is this code for someone who wants a COWOA ONLY shop or is there anything in this zip file that should/could be incorporated into COWOA beta?? If there are only specific bits that should/could be incorporated, could you possibly submit those changes as a PR in the Github repo for COWOA since you know which bits should be incorporated?? Purty please... :blush:

Quote:

---

Originally Posted by DivaVocals

Not sure how much of this zip file should be incorporated into the current COWOA beta.. Is this code for someone who wants a COWOA ONLY shop or is there anything in this zip file that should/could be incorporated into COWOA beta?? If there are only specific bits that should/could be incorporated, could you possibly submit those changes as a PR in the Github repo for COWOA since you know which bits should be incorporated?? Purty please... :blush:

---

The zip was just the order status page. The COWOA only switch is not included. I'll look at github and see what I can do.. I disconnected my fork for I went down a different hole... just found a new rabbit to chase so may be taking it down again and rewriting it..

Quote:

---

Originally Posted by davewest

The zip was just the order status page. The COWOA only switch is not included. I'll look at github and see what I can do.. I disconnected my fork for I went down a different hole... just found a new rabbit to chase so may be taking it down again and rewriting it..

---

If this is just an update to the order status page, I can incorporate your zip file into COWOA..

Can I use the Cowoa Beta version on a live 1.5.5 website, as it all seems to be working OK? If not, do you know when it will be added to the plugins section?

I have a problem in 1.5.1 that I actually don't think is COWOA related but need to check to see if this rings a bell with anyone.

Free shipping over $50 is enabled and now that is the only shipping choice showing. Everything else disappears. The options do show when the total is under $50.

If this is due to COWOA, it would simply have been something I've never witnessed as most sites I work on don't do free shipping too. It's also such a subtle change and wouldn't impact every site that it just may not have been noticed before. I wouldn't bet on that though. and this is a 1.5.1 site.

and we also tried turning off the $50 free shipping to have it all start working normally again. So this has something to do with free shipping only as I suspected.

This particular cart does have a reoccurring error that was introduced last year. It was unnoticed til now though I still don't know what's causing it. In the shopping cart, the page does not display the estimate shipping information, and throws an error

Cannot redeclare class order in /home/xxxxxx/public_html/includes/classes/order.php on line 1054

There's nothing wrong with that file as I had uploaded the original one from 1.5.1 and the problem still occurs. I don't know if this is part of this problem or not so I hesitated to mention it. But... maybe.... it might give a clue as to what's going on.

was given the code to fix that php error so that is not part of the shipping options problem

Problem solved: Files which do
require(DIR_WS_CLASSES . 'order.php');

must be changed to

require_once(DIR_WS_CLASSES . 'order.php');

(notably includes/modules/shipping_estimator.php)

Yes, that was the error fix. Thanks, Scott.

still got no options showing up for shipping besides free

Quote:

---

Originally Posted by delia

Yes, that was the error fix. Thanks, Scott.

still got no options showing up for shipping besides free

---

is this just the shipping step page? or shipping/payment/order total page... i've tested for every shipping i could think of so will have to run some things down.. one issue comes to mind is to see if shipping is getting called which builds the list of active shiipping options..

i've had order,php error before... but found it wasn't needed again... deleted the extra calls.. will look into changing to require_once

i'm out of town now so don't have my work station with me to look at.

the issue is that only the free shipping shows on the shipping page and the estimate shipping.

I've got a client that's "kicking the tires" on the COWOA plugin. He noticed that you can't go through guest-checkout if you already have an account. Is there any way for that functionality to occur (other than deleting all customers' records)?

Quote:

---

Originally Posted by delia

the issue is that only the free shipping shows on the shipping page and the estimate shipping.

---

still looking at this, but so far not getting an error to show up. I'm getting it to show with other shipping options over the set amount and not show when under set amount..

Quote:

---

Originally Posted by lat9

I've got a client that's "kicking the tires" on the COWOA plugin. He noticed that you can't go through guest-checkout if you already have an account. Is there any way for that functionality to occur (other than deleting all customers' records)?

---

so the customer with an account doesn't want to log in! I think this version of COWOA only has an off switch.. The one I've been playing with and running on my own site has an only COWOA switch which totally hides the account side of Zen Cart. Also an admin switch to change accounts to COWOA and back to Standard..

I think it would be possible to change the logic of COWOA to make it work. Currently not something in COWOA. We use the customer email address to figure out the user ID for both types of accounts and added password for the standard account. So some of the same rules would still need to be in place so when the account holder do login, they can see past orders.

twas settings. I had to look up how it was supposed to be done for later versions of zen cart. The settings for free shipping were different and working. So it wasn't the COWOA.

Quote:

---

Originally Posted by davewest

... so the customer with an account doesn't want to log in! I think this version of COWOA only has an off switch.. The one I've been playing with and running on my own site has an only COWOA switch which totally hides the account side of Zen Cart. Also an admin switch to change accounts to COWOA and back to Standard..

---

It's not that they don't want to log in; the site's products are seasonal and the returning customers, many times, don't remember their password and can't "find" the password-forgotten emails to actually log in.

I started playing with the beta release - having not touched anybody else's version in a long time. I just recently made my version responsive - and ran into an issue with the beta release. I don't see how to create an issue on github - it's not a code thing but a usability issue that needs discussing. Shall I mention it here?

Quote:

---

Originally Posted by lat9

It's not that they don't want to log in; the site's products are seasonal and the returning customers, many times, don't remember their password and can't "find" the password-forgotten emails to actually log in.

---

That's why I changed my password reset system...

Quote:

---

Originally Posted by delia

I started playing with the beta release - having not touched anybody else's version in a long time. I just recently made my version responsive - and ran into an issue with the beta release. I don't see how to create an issue on github - it's not a code thing but a usability issue that needs discussing. Shall I mention it here?

---

It's always a pain degrading the template back to the basic, but the idea is that it would make it easier for the user to upgrade or match their site. With the new responsive basic adds another one to the list.. If I give up and do what I know, would that make it hard for a non-coder to modify and match their site! Perhaps a good discussing in a new thread for it's something to think about in all mods that modify template forms.

Quote:

---

Originally Posted by delia

I started playing with the beta release - having not touched anybody else's version in a long time. I just recently made my version responsive - and ran into an issue with the beta release. I don't see how to create an issue on github - it's not a code thing but a usability issue that needs discussing. Shall I mention it here?

---

No.. any discussions for the beta version need to be logged on Github.. not sure why you don't see the issues tab.. it's in the same location as any other Github repo: https://github.com/DivaVocals/zen_COWOA/issues

First of all thanks for the work on getting this going for 1.5.5. COWOA (guest checkout) is a great needed feature.

I have a question/request that I have brought up before. I would love to see the possibility to allow guest checkout even when there is already an existing registered account for this email. Is this technically possible without screwing up the zencart customer or order db's?

Currently you can not use the guest checkout with an already registered email. Say a returning registered customer comes back to our site and just wants to do a guest checkout this time, won't work. Reality is many customers are not remembering the correct password and dealing with the password reset function is more cumbersome to them than simply go with the guest checkout. So they go with guest checkout only to find out they can't because they have already a registered account with us with this email. Now frustration sets in and we ether loose the sale or I get frustrated calls from them. Some try the reset password function but the reset email lands in spam too often leading them to multiple tries at the reset function, more frustration sets in.

We IT folks might think this is not big deal, just use another email or go to your spam folder and look a bit harder.... well your average site visitor is not always that computer savvy.

Quote:

---

Originally Posted by mydanilo

I have a question/request that I have brought up before. I would love to see the possibility to allow guest checkout even when there is already an existing registered account for this email. Is this technically possible without screwing up the zencart customer or order db's?

---

Wasn't something I really needed but, anyway... current version with the split create account and no account pages would be difficult to do... In using a single page for both and changing the logic behind the password field. Add a password, it's a standard account, no password and it's a COWOA account... than adding another level to the logic is simple enough... adding a user view and deciding how I want to explain it to them is where I'm at now. I'm leaning towards a alert still info popup.

within my logic, Both account types do have passwords! In COWOA the password is generated and added to the account each time its used. The standard account password is controlled by the user. bypassing the cowoa password for existing account also has to be part of the code or the account user will never login again. Things to think about when you change yours.

OK, re-posting in this thread as was mentioned it would be the better place to ask:

I have a problem with Login as Customer with Master Password and COWOA installed on 1.5.4. I can use it perfectly with regular accounts. I can not login as customer with COWOA created accounts. What would make it fail just with COWOA accounts? It simply says email or password incorrect. I reinstalled all again to make sure I did not miss anything.

Quote:

---

Originally Posted by mydanilo

OK, re-posting in this thread as was mentioned it would be the better place to ask:

I have a problem with Login as Customer with Master Password and COWOA installed on 1.5.4. I can use it perfectly with regular accounts. I can not login as customer with COWOA created accounts. What would make it fail just with COWOA accounts? It simply says email or password incorrect. I reinstalled all again to make sure I did not miss anything.

---

I confirm I have the same problem. It may be something that has a logic however.
ciao

Logic says to prevent accidental access to areas you need to have an account for we need to block that from happing.. also helps to prevent hacks!

With that, Master Password wll not function for COWOA accounts and I see no reason to do a walk around for it.. Of course, logic says all you need is an email address and you can do the same as they without account!!

Quote:

---

Originally Posted by davewest

Logic says to prevent accidental access to areas you need to have an account for we need to block that from happing.. also helps to prevent hacks!

With that, Master Password wll not function for COWOA accounts and I see no reason to do a walk around for it.. Of course, logic says all you need is an email address and you can do the same as they without account!!

---

I agreen with what above. However, a COWOA has to input the email address and if after one year he comes back and try to login the login will be refused. He may then try to get a new password thinking he forgot it. He gets an email with the new password and then the login will be refused again. The COWOA will think ths site is broken and will go shopping somewere else. I think the COWOA, when tryng to login should receive a warning message saying "We know you purchased with us using this email ADDRESS, but you choose to not create a account. For your privacy, this is not allowing you to receive a new password neither to login with this eamil address. Please buy again without account or create a account if you like." Even better the essage should finish with " If you want to trasform your guest purchase in a account puchase click here and you will receive a password, at the email address used in the past, to login with that email address and make your purchases." Obviously the COWOA has to became a regular account in the db.
Ciao from Italy.
enzo

Quote:

---

Originally Posted by enzo-ita

I agreen with what above. However, a COWOA has to input the email address and if after one year he comes back and try to login the login will be refused. He may then try to get a new password thinking he forgot it. He gets an email with the new password and then the login will be refused again. The COWOA will think ths site is broken and will go shopping somewere else. I think the COWOA, when tryng to login should receive a warning message saying "We know you purchased with us using this email ADDRESS, but you choose to not create a account. For your privacy, this is not allowing you to receive a new password neither to login with this eamil address. Please buy again without account or create a account if you like." Even better the essage should finish with " If you want to trasform your guest purchase in a account puchase click here and you will receive a password, at the email address used in the past, to login with that email address and make your purchases." Obviously the COWOA has to became a regular account in the db.
Ciao from Italy.
enzo

---

COWOA 'Check Out With Out Account' is not the same as an Standard Account! Thus the account is for Admin to track, document orders and hopefully get paid. On the user side, there never was an account so there is no login, password so on so why would admin need to login! They already have more access/info then the user!

If a user comes back 5 seconds or 5 years, the account is the same, email address buys anything! there is no login or password they need to enter or you... Yes.. If when the user decides to create an account, than the existing info is converted and the user now has a password to manage.

The problem is more the other way around. The customer created a regular account and placed an order. Customer then comes back at another time and wants to do a guest checkout as he/she can't remember if or with what pwd he/she created an account. So guest checkout is on the order, but only to find out that it won't be possible with this email as there was previously an account registered. At that point, most are already frustrated and might or might not try the reset pwd function. Reset pwd emails land a lot in spam folder and leads to customer trying to reset several times, next frustration sets in. If they have not taken their business elsewhere by now they are really stubborn and must love my store tremendously! ;)

Is it really so hard to understand that this can't be good for business?

Well, the good new is Dr. Byte confirmed that the built in guest checkout in 1.6 will fix this. https://www.zen-cart.com/showthread....eat-an-account

Just a question now on when v1.6 will be ready.

Quote:

---

Originally Posted by Fourpaws

There is no option to "Subscribe to Our Newsletter" just HTML or Text Only choices.

Is it intentional that all customers that COWOA are automatically subscribed to the newsletter?

---

I'm having the same issue with my site. Is this normal?

Did anyone ever figure out the tickbox issue?

Never mind. I found it. For anyone else who is looking, you need to edit includes/templates/YOUR THEME/templates/tpl_modules_no_account.php

The code says:

<fieldset>
<legend><?php echo ENTRY_EMAIL_PREFERENCE; ?></legend>

<?php echo zen_draw_radio_field('email_format', 'HTML', ($email_format == 'HTML' ? true : false),'id="email-format-html"') . '<label class="radioButtonLabel" for="email-format-html">' . ENTRY_EMAIL_HTML_DISPLAY . '</label>' . zen_draw_radio_field('email_format', 'TEXT', ($email_format == 'TEXT' ? true : false), 'id="email-format-text"') . '<label class="radioButtonLabel" for="email-format-text">' . ENTRY_EMAIL_TEXT_DISPLAY . '</label>'; ?>
<br class="clearBoth" />
</fieldset>

It should say:

<fieldset>
<legend><?php echo ENTRY_EMAIL_PREFERENCE; ?></legend>
<?php
if (ACCOUNT_NEWSLETTER_STATUS != 0) {
?>
<?php echo zen_draw_checkbox_field('newsletter', '1', $newsletter, 'id="newsletter-checkbox"') . '<label class="checkboxLabel" for="newsletter-checkbox">' . ENTRY_NEWSLETTER . '</label>' . (zen_not_null(ENTRY_NEWSLETTER_TEXT) ? '<span class="alert">' . ENTRY_NEWSLETTER_TEXT . '</span>': ''); ?>
<br class="clearBoth" />
<?php } ?>

<?php echo zen_draw_radio_field('email_format', 'HTML', ($email_format == 'HTML' ? true : false),'id="email-format-html"') . '<label class="radioButtonLabel" for="email-format-html">' . ENTRY_EMAIL_HTML_DISPLAY . '</label>' . zen_draw_radio_field('email_format', 'TEXT', ($email_format == 'TEXT' ? true : false), 'id="email-format-text"') . '<label class="radioButtonLabel" for="email-format-text">' . ENTRY_EMAIL_TEXT_DISPLAY . '</label>'; ?>
<br class="clearBoth" />
</fieldset>

I have COWOA 2.7 (BETA) working on my 1.5.5 install. I've done some initial testing and everything seems to be working.

So firstly, thank you to everyone who has contributed to keeping this mod up to date!

Secondly, in order to have COWOA not completely break my template, I completely skipped copying includes\templates\MY_TEMPLATE\common\tpl_header.php AND tpl_main_page.php

I tried to merge the COWOA files with my current tpl_header.php and tpl_main_page.php, but they seem to be completely different and I can't even tell what should be merged (my current files are quite old, i think my template was designed for 1.3.9).

Am I missing out on any functionality by skipping these two files? Am I going to run into errors? It doesn't seem to be throwing anything into the error log for now.

Thanks for any help!

Quote:

---

Originally Posted by LightBrown

I have COWOA 2.7 (BETA) working on my 1.5.5 install. I've done some initial testing and everything seems to be working.

So firstly, thank you to everyone who has contributed to keeping this mod up to date!

Secondly, in order to have COWOA not completely break my template, I completely skipped copying includes\templates\MY_TEMPLATE\common\tpl_header.php AND tpl_main_page.php

I tried to merge the COWOA files with my current tpl_header.php and tpl_main_page.php, but they seem to be completely different and I can't even tell what should be merged (my current files are quite old, i think my template was designed for 1.3.9).

Am I missing out on any functionality by skipping these two files? Am I going to run into errors? It doesn't seem to be throwing anything into the error log for now.

Thanks for any help!

---

If you don't merge tpl_main_page.php, the option for turning off sideboxes during checkout will not work.
If you don't merge tpl_header.php, the Logoff and My Account will display when users are checking out without an account.

Quote:

---

Originally Posted by jeking

If you don't merge tpl_main_page.php, the option for turning off sideboxes during checkout will not work.
If you don't merge tpl_header.php, the Logoff and My Account will display when users are checking out without an account.

---

Thanks for the info. I don't plan on turning off the sideboxes during checkout, so tpl_main_page.php should be fine, and I already removed the My Account button completely. So i guess I am good to go!

I installed the COWOA and in the admin tools, I get no choices. I did a fresh install of zencart 1.5.5a and the COWOA. Still no joy.

Did I miss something? I followed the directions to the 'T'.

Quote:

---

Originally Posted by IATIA

I installed the COWOA and in the admin tools, I get no choices. I did a fresh install of zencart 1.5.5a and the COWOA. Still no joy.

Did I miss something? I followed the directions to the 'T'.

---

Just to check, which version of COWOA did you install? The latest COWOA version downloaded from the Zencart website or the 1.5.5 Beta version from Github? The version hosted on Zencart will not work with 1.5.5

I downloaded from here. I will check out github.

Thanks

Alright. I finally got it up and running. New issue.

I have a list instead of the menu. I tried "toggle navigation" but that did nothing.

Quote:

---

Originally Posted by IATIA

I have a list instead of the menu. I tried "toggle navigation" but that did nothing.

---

I don't know what you are referring to here. The COWOA menu?

I miserably failed in merging COWOA (v2.7 - 03/25/2016 Updated for Zen Cart v1.5.5) into 1.5.5d with Winchester Responsive. What is the status on this for 1.5.5d? Does anyone have files merged with any responsive templates that work? Would consider starting with pretty much any template as long as COWOA works. Yes, that important to me. I have to mention that I also installed the one page checkout. So maybe the combination of the two just got too much for me. Looking for guidance where to go from here. As of now I am sticking with 1.5.4 until I have a solution. Read the good discussion on github but they are all from 2015. https://github.com/DivaVocals/zen_COWOA is there a newer version available? Or simply wait for 1.6?

Quote:

---

Originally Posted by mydanilo

I miserably failed in merging COWOA (v2.7 - 03/25/2016 Updated for Zen Cart v1.5.5) into 1.5.5d with Winchester Responsive. What is the status on this for 1.5.5d? Does anyone have files merged with any responsive templates that work? Would consider starting with pretty much any template as long as COWOA works. Yes, that important to me. I have to mention that I also installed the one page checkout. So maybe the combination of the two just got too much for me. Looking for guidance where to go from here. As of now I am sticking with 1.5.4 until I have a solution. Read the good discussion on github but they are all from 2015. https://github.com/DivaVocals/zen_COWOA is there a newer version available? Or simply wait for 1.6?

---

don't wait for 1.6 it is miles away from being ready, don't be surprised to see a 1.5.6 first :smile:.

Quote:

---

Originally Posted by Design75

don't wait for 1.6 it is miles away from being ready, don't be surprised to see a 1.5.6 first :smile:.

---

Exactly what I'm afraid of. So any help to get this going is appreciated.

I'd love to help, but I have to many things going on right now.

Quote:

---

Originally Posted by mydanilo

Exactly what I'm afraid of. So any help to get this going is appreciated.

---

Getting closer: I had to not use includes\templates\MY_TEMPLATE\common\tpl_header.php AND tpl_main_page.php from this mod and used my templates version. Now it at least works, sort of. One page checkout also works in combination. More testing needed and I will post back.

Successfully merged COWOA with One Page Checkout and Edit Order. Pretty happy.

One thought, can I convert a COWOA customer into a regular account somehow? I understand it would require setting a password, but that should be no problem with the reset password function. The master password mod comes to mind as well. Why do I ask? I still look for a way to help a customer by phone and just log in with whatever COWOA or regular account in my store and do an order for them. Any thoughts?

Quote:

---

Originally Posted by mydanilo

Successfully merged COWOA with One Page Checkout and Edit Order. Pretty happy.

One thought, can I convert a COWOA customer into a regular account somehow? I understand it would require setting a password, but that should be no problem with the reset password function. The master password mod comes to mind as well. Why do I ask? I still look for a way to help a customer by phone and just log in with whatever COWOA or regular account in my store and do an order for them. Any thoughts?

---

I know that this version has some limits, but when I get time to finish adding some things I'll upload mine. The way COWOA works now is with a switch. So adding a flip and switching from one to the other is possible which I already did.

COWOA does create a password when a COWOA account is created. Why log into that account anyway! Nether the customer or you would need to ever login to a COWOA account! It behaves the same for both!

Customer/Owner: Select the product, do the payment/shipping address, enter the email address and that's it! If the phone customer doesn't have an email address then use one of yours or have a shop address just for that reason. That's one thing nice about COWOA is phone in orders can be processed without the customer ever needing Internet or email access and ZC still functions without any problems.

Quote:

---

Originally Posted by davewest

I know that this version has some limits, but when I get time to finish adding some things I'll upload mine. The way COWOA works now is with a switch. So adding a flip and switching from one to the other is possible which I already did.

COWOA does create a password when a COWOA account is created. Why log into that account anyway! Nether the customer or you would need to ever login to a COWOA account! It behaves the same for both!

Customer/Owner: Select the product, do the payment/shipping address, enter the email address and that's it! If the phone customer doesn't have an email address then use one of yours or have a shop address just for that reason. That's one thing nice about COWOA is phone in orders can be processed without the customer ever needing Internet or email access and ZC still functions without any problems.

---

Yes I do want to login as the COWOA customer. I have customers call for phone orders. I always ask if they ordered before. If yes, I have the billing and shipping already in Zen Cart so why not use it and produce a new order? No need to hand enter that again. Would be truly awesome if this could be changed.

Add the master password mod and you can log into a COWOA account. There are a lot of reasons to need to access a COWOA account. We also need to change them to a regular account sometimes for store credit (mod) or if they purchase gift certificates, once we change it to a regular account we log in using master password and change the password to a temp one that they can change. It would be nice to have an admin control to do this instead of having to go into the DB and change the customer from COWOA = 1 to 0. That would be the biggest feature I would like to see.

As far as adding customers, creating orders, I don't see a need to do this with COWOA!

But I did find and tested something that would work for you.. In the plugin section you can find three plugins that do just what you need. I installed on a ZC1.5.4 and they did work, not the way I would like, but they do create customer, order and edit order which lets you add or remove products. Look for admin_new_customer then admin_new_orders and edit_orders-4.1.7..

Follow the instructions and suggested install order. The new order can be used to create a past COWOA customer order! With the edit order then allows you to add products. It works. I may change the code and create something that works for me.. If I only sold products, then this would be something else, but for me the store front still works better.

To add this function would make COWOA even larger and harder for folks to install and maintain/update is why I wouldn't suggest it become part of COWOA. Plus with the three mods supported and working why add another one.

With the changes I did to my site cowoa, master password does not work for COWOA accounts. When you change things so anyone with or without an account can do COWOA, I had to change how account access was performed or account holders would be auto logged in..

I really appreciate this addon which I found after Fast And Easy Checkout wasn't available for Zen Cart 1.55!

I've been testing a new site with COWOA 2.7 beta and Zen Cart 1.55e with Picaflor Azul's responsive_sheffield_blue template, and after installing COWOA, the admin layout is fairly regularly corrupted on subsequent installations as I practice installing my site. I fix it by replacing the \YOUR_ADMIN\includes\stylesheet.css included with COWOA with the default file provided by Zen Cart 1.55e. I was wondering, is there a reason that that stylesheet is included in the beta, as that file is not in the file list for the stable release?

Another issue I have is with \includes\templates\YOUR_TEMPLATE\common\tpl_header.php. In the stable release version notes it is noted that I should look for the COWOA word that is just before all the entries. I'm guessing that hasn't been done yet on the beta version? That file is so different than responsive_sheffield_blue's tpl_header.php that I just don't have the programming knowledge and capabilities to do a merge even with merging software to help me. So I have been replacing the COWOA file with my customized tpl_header.php file for responsive_sheffield_blue. What I want is to force all customers to use COWOA as discussed here: https://www.zen-cart.com/showthread....12#post1270212 . I have successfully altered my template's tpl_header.php, but if I overwrite it with the COWOA version it breaks my header layout completely so right now I am just forgoing all the COWOA header capabilities.

I know from earlier in this thread: https://www.zen-cart.com/showthread....in#post1137200 that not using the addon's tpl_header.php means I am not getting all the benefits of COWOA. Do you have any suggestions for me on what portions are necessary, or do I just lose out until I'm better at php? At least I have the site working! Thanks for the great addon!

Does anyone know if this plugin would work with westminster_new template by Picaflor Azul's?
I am using zencart 155e

Yes it does, just read here if you run into some issues. But I got it going and it's working fine.

Quote:

---

Originally Posted by mydanilo

Yes it does, just read here if you run into some issues. But I got it going and it's working fine.

---

Thanks for the reply

I do read that there is some issues with installing this plugin using zencart 155. I am not much of a coder so I did not know if I should tackle this plugin.

I have been using this plugin on my current site of zencart 154d and about 50% of my customers use it.

I gave it a try adding the COWOA plugin on version zencart 155e using westminster_new template by Picaflor Azul.

I don't know what I did wrong but I do not have the option to check out as a guest and also I noticed the my admin panel has change formats. Instead of 3 columns of information, everything is layed out horizontally.

I did go to the config/cowoa settings and marked everything as true.

Any ideas where I should start. I do not get any errors in my logs file.

Found the problem. I did not load some tpl files.
COWOA work great.

One thing though is that my admin panel format has changed as I said prior to this post.
Can anyone tell me what I did wrong and how I can get it back to view 3 columns of information vs. everything being horizontal?

Quote:

---

Originally Posted by Maynards

Found the problem. I did not load some tpl files.
COWOA work great.

One thing though is that my admin panel format has changed as I said prior to this post.
Can anyone tell me what I did wrong and how I can get it back to view 3 columns of information vs. everything being horizontal?

---

Not sure but check one more time that you uploaded everything into the proper locations, template override locations etc. You could also do a compare of the modified files with your install before you uploaded COWOA. Did you do some file merge? Maybe something went wrong there. Just some general thoughts.

I just made a stupid mistake, I was kind of tired and needed to have the module up and running. I have ZC 1.5.3, yes didn't upgrade it yet, because of lack of time ...
BTW been playing with the latest on a non-live store for months. My problem is I forgot to insert the SQL before modifying the files ... so as a result the scripts are looking for tables that didn't exist ...
What's the best solution?
1. GO to PHPmyAdmin and insert the SQL staments myself or
2. Restore all the admin files to normal while and then use the standard SQL install from Admin?

Quote:

---

Originally Posted by icecold

I just made a stupid mistake, I was kind of tired and needed to have the module up and running. I have ZC 1.5.3, yes didn't upgrade it yet, because of lack of time ...
BTW been playing with the latest on a non-live store for months. My problem is I forgot to insert the SQL before modifying the files ... so as a result the scripts are looking for tables that didn't exist ...
What's the best solution?
1. GO to PHPmyAdmin and insert the SQL staments myself or
2. Restore all the admin files to normal while and then use the standard SQL install from Admin?

---

Well I fix it myself, just restored My_Admin/index.php logged in and used Tools > Insert SQL Patches
:)

I have another problem which is really weird all my definitions are working fine ....
Except for these two ... that are already defined and present, but they still show up as non defined ... Why this is happening, they are there ... :blink:

Quote:

---

Originally Posted by icecold

I have another problem which is really weird all my definitions are working fine ....
Except for these two ... that are already defined and present, but they still show up as non defined ... Why this is happening, they are there ... :blink:

---

Fixed I inadvertently upload the files to my catalog includes ... so i just moved it up to the Admin ...
:oops:

Hi fellow Zen Cart-ers,

We have a one time use per customer coupon we offer to first time buyers. Unfortunately, we have a customer that has been using COWOA and has been able to reuse the coupon every single time she checks out. I looked at the customer list and it looks like she is getting assigned a new ID # every time she shops even though she is using the same billing/shipping/email address.

Attachment 17037

Is there a way to get around the cart treating her like a new customer every time she uses COWOA?

We are using Zen Cart 1.5.4 and COWOA 2.4

Any help will be appreciated.

Quote:

---

Originally Posted by thegoodlifestore

Hi fellow Zen Cart-ers,

We have a one time use per customer coupon we offer to first time buyers. Unfortunately, we have a customer that has been using COWOA and has been able to reuse the coupon every single time she checks out. I looked at the customer list and it looks like she is getting assigned a new ID # every time she shops even though she is using the same billing/shipping/email address.

Attachment 17037

Is there a way to get around the cart treating her like a new customer every time she uses COWOA?

We are using Zen Cart 1.5.4 and COWOA 2.4

Any help will be appreciated.

---

Obvious questions:
Is she really getting a new ID# (verify in Customers)?
Is in this Coupon settings Max. uses per customer set to 1?
IMHO in ZenCart you cannot have two customers having the same email address.
However, I see the different ID#'s in your post...:unsure:

In COWOA 2.7 a customer ordering for the second time w/o account, using the same email address, does not get a new (different) ID# and an existing Customer Referral 1st Discount Coupon has not been changed.

jpda

Quote:

---

IMHO in ZenCart you cannot have two customers having the same email address.

---

Verified in ZC 1.5.5e and ZC 1.5.4

jpda

COWOA v2.7 for ZC 1.5.4 has a check for an existing COWOA account in includes/modules/YOUR_TEMPLATE/create_account.php.
Does COWOA v2.4 has such a check?

jpda

Quote:

---

ZenCart you cannot have two customers having the same email address.

---

True..

Past COWOA used a method of placing a dot in-front of the email address to hid it from ZC. around 2.7 this was changed to a column setting to ID the account type and behave accordingly. Upgrading is the best fix, but may also leave a mess in user accounts so a follow up with phpmyadmin to correct database issues would also be advised.

Quote:

---

Originally Posted by davewest

True..

Past COWOA used a method of placing a dot in-front of the email address to hid it from ZC. around 2.7 this was changed to a column setting to ID the account type and behave accordingly. Upgrading is the best fix, but may also leave a mess in user accounts so a follow up with phpmyadmin to correct database issues would also be advised.

---

I see that COWOA 2.7 is still in development? So that makes me a little nervous about upgrading. And what kind of database issues might be caused by upgrading?

PLUS ... I am seeing in the install instructions for 2.7 that "COWOA 2.7 IS NOT COMPATIBLE WITH VERSIONS OF ZEN CART PRIOR TO ZEN CART 1.5.5."

Thanks for the pointers to the COWOA 2.7 files.

I played around and added the code that checks for an existing COWOA customer to the existing 2.4 install and it seems to be working. I tried checking out several times and it only created one new customer/ID whereas before the cart was creating a new customer/ID each time I tried to checkout with the same e-mail address.

There are two checks that needed to be added.
One in: includes/modules/YOUR_TEMPLATE/create_account.php
One in: includes/modules/YOUR_TEMPLATE/no_account.php

Thanks again for getting me pointed towards a solution to my problem. :)

Quote:

---

Originally Posted by thegoodlifestore

I see that COWOA 2.7 is still in development? So that makes me a little nervous about upgrading. And what kind of database issues might be caused by upgrading?

PLUS ... I am seeing in the install instructions for 2.7 that "COWOA 2.7 IS NOT COMPATIBLE WITH VERSIONS OF ZEN CART PRIOR TO ZEN CART 1.5.5."

---

The install set contains a separate folder for ZC 1.5.4.

jpda

Quote:

---

Originally Posted by jpda

The install set contains a separate folder for ZC 1.5.4.

---

I did see that after I posted the message. Thanks again everyone for the pointer to the COWOA 2.7 files.

I am trying to install COWOA 2.4 (most recent version to download) and everything goes well until I install the SQL patch.

Specifically the larger chunk "INSERT INTO configuration (configuration_id, configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, date_added, use_function, set_function) VALUES .... "

Every time I try to add that I receive an error. All other lines go in fine. Please advise.

Using ZenCart 1.5.5

Quote:

---

Originally Posted by dpeterson

I am trying to install COWOA 2.4 (most recent version to download) and everything goes well until I install the SQL patch.

Specifically the larger chunk "INSERT INTO configuration (configuration_id, configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, date_added, use_function, set_function) VALUES .... "

Every time I try to add that I receive an error. All other lines go in fine. Please advise.

Using ZenCart 1.5.5

---

Search this thread for the version on GitHub. 2.4 is not designed for ZC 1.5.5.

thank you! should I uninstall everything done to this point and just start over with the git hub version?

thank you! should I just uninstall what I did so far and then just reinstall the git hub version?

Quote:

---

Originally Posted by dpeterson

thank you! should I uninstall everything done to this point and just start over with the git hub version?

---

If you want to be thorough, you should remove what you've done an start fresh with the correct version.

am I just not seeing how to download the file or does everything just need to be inserted manually?

Look for the Clone or Download button on the right side.

https://github.com/DivaVocals/zen_COWOA

Click and then select Download ZIP.

just found it thank you very much

I recently installed COWOA into Zen Cart and the admin home page changed. Is that related? Is there a way to turn back to the three panels with boxes? All the top line menus are now listed as hyperlinks. Thank you!

Attachment 17318

Quote:

---

Originally Posted by dpeterson

I recently installed COWOA into Zen Cart and the admin home page changed. Is that related? Is there a way to turn back to the three panels with boxes? All the top line menus are now listed as hyperlinks. Thank you!

Attachment 17318

---

Try refreshing the admin first. If that does not work, look at YOUR_ADMIN/includes/stylesheet.css Compare your current version to the ZC default. The one in the plugin should be fine, but compare to be sure.

COWOA edits the index.php page of admin. In ZC 1.5.5 a index_dashboard.php was added which should be edited not index.php

Replace the index.php with the original file and use the index_dashboard.php file to make your edits.

Quote:

---

Originally Posted by jeking

Try refreshing the admin first. If that does not work, look at YOUR_ADMIN/includes/stylesheet.css Compare your current version to the ZC default. The one in the plugin should be fine, but compare to be sure.

---

Yes, the file was different, just loaded up the original and worked perfect thank you!