COWOA (for ZC v1.5.x)

Yep, I'm an idiot..... I had re-named the languages/YOUR-TEMPLATE/ to the name of my admin folder... This is what happens when you have been working your full time job all day and then start working on something else... Time to go home and sleep.

Thanks for the help!!

Quote:

---

Originally Posted by scotthead1st

Yep, I'm an idiot..... I had re-named the languages/YOUR-TEMPLATE/ to the name of my admin folder... This is what happens when you have been working your full time job all day and then start working on something else... Time to go home and sleep.

Thanks for the help!!

---

No problem glad you figured it out.

So now I cannot edit my orders through the admin section. I have Edit Order 4.1.2 installed. I did merge the core files. Any ideas? The edit orders section is completely blank.

Quote:

---

Originally Posted by scotthead1st

So now I cannot edit my orders through the admin section. I have Edit Order 4.1.2 installed. I did merge the core files. Any ideas? The edit orders section is completely blank.

---

Nothing to do with COWOA.. Ask your question on the Edit Orders support thread..

Quote:

---

Originally Posted by DivaVocals

Still sounds like you have another module which modifies the same files as COWOA which is the root cause of the issue..

---

wow so long to figure this out, just no time spend on this until today. So I removed mods one by one. End result, nothing to do with COWOA and everything to do with discount preview by Softwareguy. There is a file which I forgot to edit after uploading a new template. shipping_estimator.php (includes/modules/) for anyone stumbling upon this thread while searching for: "PHP Fatal error: Cannot redeclare class order in /home/.../public_html/includes/classes/order.php on line 1111"

I've searched the forum and haven't found a solution for what I'm trying to do (which is to avoid a ton of file-merging, commenting out, etc.)

I'm running v1.5.1 with many mods and customizations, including Minimum Customer Account Information. I book tours and only gather name, email and contact cell phone. No need for shipping or address info. They just enter name, email and contact cell and create password (& account) and then move to checkout and only enter card number and CVV pin and they're done.

I'd like to use the COWOA guest checkout exclusively; my customers don't even want to enter a password nor need any of the registered customer benefits. Is there a "quicky" way that you know of that I can just install the pertinent files to enable Guest Checkout, allowing me to do this and avoid merging nearly every file?

Thanks in advance for any advice or guidance...

The short answer is no... if you want a guest check out system that touches none of the core files you will need to write something custom for yourself..

Quote:

---

Originally Posted by swjake

I've searched the forum and haven't found a solution for what I'm trying to do (which is to avoid a ton of file-merging, commenting out, etc.)

I'm running v1.5.1 with many mods and customizations, including Minimum Customer Account Information. I book tours and only gather name, email and contact cell phone. No need for shipping or address info. They just enter name, email and contact cell and create password (& account) and then move to checkout and only enter card number and CVV pin and they're done.

I'd like to use the COWOA guest checkout exclusively; my customers don't even want to enter a password nor need any of the registered customer benefits. Is there a "quicky" way that you know of that I can just install the pertinent files to enable Guest Checkout, allowing me to do this and avoid merging nearly every file?

Thanks in advance for any advice or guidance...

---

Thank you for getting back. I installed in once on a test server site, but wasn't quite what I wanted. I'll reinstall on test server and play around with it and see what hacks I can get into.

Thanks again! It's a good mod!

But just to be clear: I was hoping there were a minimum of files I could install in order for the Guest checkout to function properly, or if I needed to install all the included files (tpl_shipping, etc). Thought someone might have used it exclusively for guest checkout and had a "shortcut". Then again, shortcuts get you in trouble...

Quote:

---

Originally Posted by swjake

Thank you for getting back. I installed in once on a test server site, but wasn't quite what I wanted. I'll reinstall on test server and play around with it and see what hacks I can get into.

Thanks again! It's a good mod!

But just to be clear: I was hoping there were a minimum of files I could install in order for the Guest checkout to function properly, or if I needed to install all the included files (tpl_shipping, etc). Thought someone might have used it exclusively for guest checkout and had a "shortcut". Then again, shortcuts get you in trouble...

---

Like I said.. this ADDS a guest feature into the default checkout process.. can't do that without some level of changes to the core checkout files.. But you are welcome to try and figure our how you can do this without touching any of the core checkout files..

Also you might want to keep in mind that COWOA will become part of the Zen Cart core functionality as of v1.6.. so any "hacks" you make will have to be done again..

Getting an error at the checkout_process page, I am testing my new cart and keep getting errors such are this:
Array ( [0] => This transaction has already been captured (OrderID : 7) )
I've tried uninstalling an re-installing and still not working, suggestions?

Wanted to assemble this info in ONE place. I had to search all over the forum for this information so I figured I'd help save others the trouble of looking for this data.

First, the salient point is this: Customers who DO NOT have a regular store account cannot USE or PURCHASE gift certificates. PERIOD. If you offer gift certificates, you MUST put something in the product description which indicates this or you will find your self doing a LOT of backend work to back out these sales transactions. See: Checkout without Account and Gift Certificates

If a customer converts from COWOA to a regular store account you may find that if you use any of the admin e-mail functions that they will get duplicate e-mails. This is particularly troubling if they have shopped more than once using COWOA, and then signup for a regular account using the same e-mail they previously used for COWOA. If you send this particular customer a gift certificate, you will find that they will receive MULTIPLE gift vouchers.

To fix this, I found this code:

Quote:

---

Originally Posted by damiantaylor

I think I've fixed the duplicate email address/duplicate email send bug.
Zen Cart doesn't usually allow more than one account to have the same email address so I needed to limit the number of emails sent to 1 if a specific email address was selected.
The duplicate emails can get costly when sending Gift Certificates from Admin :shocking:

In file includes/functions/audience.php, I have changed function get_audience_sql_query to:

Code:

---

  function get_audience_sql_query($selected_entry, $query_category='email') {
    // This is used to take the query_name selected in the drop-down menu or singular customer email address and
  // generate the SQL Select query to be used to build the list of email addresses to be sent to
  // it only returns a query name and query string (SQL SELECT statement)
  // the query string is then used in a $db->Execute() command for later parsing and emailing.
  global $db;
  $query_name='';
  $queries_list = $db->Execute("select query_name, query_string from " . TABLE_QUERY_BUILDER . " " .
                "where query_category like '%" . $query_category . "%'");
//                "where query_category = '" . $query_category . "'");

  while (!$queries_list->EOF) {
      if ($selected_entry == $queries_list->fields['query_name']) {
      $query_name  = $queries_list->fields['query_name'];
        $query_string = parsed_query_string($queries_list->fields['query_string']);
//echo 'GET_AUD_EM_ADDR_QRY:<br />query_name='.$query_name.'<br />query_string='.$query_string;
      }
    $queries_list->MoveNext();
  }
  //if no match found against queries listed in database, then $selected_entry must be an email address
  if ($query_name=='' && $query_category=='email') {
        $cust_email_address = zen_db_prepare_input($selected_entry);
        $query_name  = $cust_email_address;
        $query_string = "select customers_firstname, customers_lastname, customers_email_address
                              from " . TABLE_CUSTOMERS . "
                              where customers_email_address = '" . zen_db_input($cust_email_address) . "' limit 1";
    }
  //send back a 1-row array containing the query_name and the SQL query_string
  return array('query_name'=>$query_name, 'query_string'=>$query_string);
}

---

---

It was suggested that you should instead restrict the query to JUST COWOA customers.. the problem with that solution is that you will NOT be able to send e-mails to COWOA customers, and this may not be an entirely desirable result.

ENTRY_EMAIL_ADDRESS_COWOA_ERROR_EXISTS
appears when I go to check out as a guest. The only thing I can add is that this is only happening with Yahoo emails that may or may not have been used during a previous guest checkout.

Quote:

---

Originally Posted by DivaVocals

It was suggested that you should instead restrict the query to JUST COWOA customers.. the problem with that solution is that you will NOT be able to send e-mails to COWOA customers, and this may not be an entirely desirable result.

---

I tend to make a mess of things so had to spend some time looking back at my code... I started some time back with the first COWOA, then changed to FEC which had COWOA. Then I've modified things sense so not sure how this will look to you. I noticed it's still not been addressed in the new version of FEC.

I had the same issues with multiple email addresses due to more then one entry as COWOA users. Then I had one customer that after 6 checkouts without an account decided to create one. Now I had 5 entries as COWOA and one standard account with the same email.

I hate copping with such, so went back into the code and fixed the source of it all, lest it works for me.

I found that in includes/modules/YOUR_TEMPLATE/no_account.php creates the account, but never checks to see if one is already there. So I modified it as done in create_account which checks to see if COWOA account exists and updates it to become a standard account... with the modified code I'm checking for an existing COWOA account with the same email address and updating it instead of creating a new one. Thus, only one COWOA account exist for that same email address. I have the one account, but still get the orders and mailing addresses each time they order. Then if they do create a standard account, all the past orders, mailing address fall back to that user... I haven't found any problems so far.

Nab a bit of code on both sides of the modified section so to help where it all fits in...

Code:

---

      // create billing address
      $sql_data_array = array('customers_firstname' => $firstname,
                              'customers_lastname' => $lastname,
                              'customers_email_address' => $email_address,
                              'customers_nick' => $nick,
                              'customers_telephone' => $telephone,
                              'customers_fax' => $fax,
                              'customers_newsletter' => (int)$newsletter,
                              'customers_email_format' => $email_format,
                              'customers_default_address_id' => 0,
                              'customers_password' => zen_encrypt_password($password),
                              'COWOA_account' => $cowoa,
                              'customers_authorization' => (int)CUSTOMERS_APPROVAL_AUTHORIZATION
      );
     
      ////////////bof modified for existing cowoa member ////////////////////////////////////
        // check if COWOA account exists for email_address
    $cowoa_accounts = 0;
    if (FEC_NOACCOUNT_COMBINE == 'true') {
      $cowoa_account = $db->Execute("SELECT customers_id, customers_default_address_id FROM " . TABLE_CUSTOMERS . "
                                    WHERE customers_email_address = '" . $email_address . "'
                                    ORDER BY customers_id DESC
                                    LIMIT 1;");
      $cowoa_accounts = $cowoa_account->RecordCount();
   
    }
    if ($cowoa_accounts > 0) {
      // cowoa account exists, use that
      $db_action = 'update';
      $sql_data_array['customers_id'] = $_SESSION['customer_id'] = $cowoa_account->fields['customers_id'];
      $sql_data_array['customers_default_address_id'] = $address_id = $cowoa_account->fields['customers_default_address_id'];
      $sql_data_array['COWOA_account'] = 1;
      $db_customers_where = 'customers_id = "' . $cowoa_account->fields['customers_id'] . '"';
    } else {
      $db_action = 'insert';
      $db_customers_where = '';
    }
    //end modified

      if ((CUSTOMERS_REFERRAL_STATUS == '2' and $customers_referral != '')) $sql_data_array['customers_referral'] = $customers_referral;
      if (ACCOUNT_GENDER == 'true') $sql_data_array['customers_gender'] = $gender;
      if (ACCOUNT_DOB == 'true') $sql_data_array['customers_dob'] = (empty($_POST['dob']) || $dob_entered == '0001-01-01 00:00:00' ? zen_db_prepare_input('0001-01-01 00:00:00') : zen_date_raw($_POST['dob']));

      zen_db_perform(TABLE_CUSTOMERS, $sql_data_array, $db_action, $db_customers_where); //added for modified cowoa

          if ($db_action == 'insert') {
      $_SESSION['customer_id'] = $db->Insert_ID();
    }

      $sql_data_array = array('customers_id' => $_SESSION['customer_id'],
                              'entry_firstname' => $firstname,
                              'entry_lastname' => $lastname,
                              'entry_street_address' => $street_address,
                              'entry_postcode' => $postcode,
                              'entry_city' => $city,
                              'entry_country_id' => $country);

      if (ACCOUNT_GENDER == 'true') $sql_data_array['entry_gender'] = $gender;
      if (ACCOUNT_COMPANY == 'true') $sql_data_array['entry_company'] = $company;
      if (ACCOUNT_SUBURB == 'true') $sql_data_array['entry_suburb'] = $suburb;
      if (ACCOUNT_STATE == 'true') {
        if ($zone_id > 0) {
          $sql_data_array['entry_zone_id'] = $zone_id;
          $sql_data_array['entry_state'] = '';
        } else {
          $sql_data_array['entry_zone_id'] = '0';
          $sql_data_array['entry_state'] = $state;
        }
      }
   
    if ($db_action == 'update') {
      $sql_data_array['address_book_id'] = $address_id;
      $db_address_table_where = 'address_book_id = ' . $address_id;
    } else {
      $db_address_table_where = '';
    }

    zen_db_perform(TABLE_ADDRESS_BOOK, $sql_data_array, $db_action, $db_address_table_where);

    if ($db_action == 'insert') {
      $address_id = $db->Insert_ID();

      $sql = "update " . TABLE_CUSTOMERS . "
                set customers_default_address_id = '" . (int)$address_id . "'
                where customers_id = '" . (int)$_SESSION['customer_id'] . "'";

      $db->Execute($sql);

      $sql = "insert into " . TABLE_CUSTOMERS_INFO . "
                            (customers_info_id, customers_info_number_of_logons,
                            customers_info_date_account_created)
                values ('" . (int)$_SESSION['customer_id'] . "', '0', now())";

      $db->Execute($sql);
  }
  //////////// eof modified for existing cowoa member ////////////////////////////////////
      if (enable_shippingAddress()) {
        // create shipping address

---

Hopefully it makes some scene to you... I've been running it like this for almost a year and haven't found any problems. Both in live and testing it's working out, running now on zencart 1.5.1


The other thing I did so I can just email COWOA users was to make a entry for it in the quary_builder. This is just my phpmyadmin dump. Could do the same for none standard accounts by adding a COWOA_account = 0 check.

Code:

---

INSERT INTO `query_builder` (`query_id`, `query_category`, `query_name`, `query_description`, `query_string`, `query_keys_list`) VALUES
(, 'email', 'COWOA Customers Only', 'Returns COWOA customers name and email address for sending mass emails (ie: for newsletters, coupons, GVs, messages, etc).', 'select customers_email_address, customers_firstname, customers_lastname from TABLE_CUSTOMERS where COWOA_account = 1 order by customers_lastname, customers_firstname, customers_email_address', '');

---

Quote:

---

Originally Posted by davewest

I tend to make a mess of things so had to spend some time looking back at my code... I started some time back with the first COWOA, then changed to FEC which had COWOA. Then I've modified things sense so not sure how this will look to you. I noticed it's still not been addressed in the new version of FEC.

I had the same issues with multiple email addresses due to more then one entry as COWOA users. Then I had one customer that after 6 checkouts without an account decided to create one. Now I had 5 entries as COWOA and one standard account with the same email.

I hate copping with such, so went back into the code and fixed the source of it all, lest it works for me.

I found that in includes/modules/YOUR_TEMPLATE/no_account.php creates the account, but never checks to see if one is already there. So I modified it as done in create_account which checks to see if COWOA account exists and updates it to become a standard account... with the modified code I'm checking for an existing COWOA account with the same email address and updating it instead of creating a new one. Thus, only one COWOA account exist for that same email address. I have the one account, but still get the orders and mailing addresses each time they order. Then if they do create a standard account, all the past orders, mailing address fall back to that user... I haven't found any problems so far.

Nab a bit of code on both sides of the modified section so to help where it all fits in...

Code:

---

      // create billing address
      $sql_data_array = array('customers_firstname' => $firstname,
                              'customers_lastname' => $lastname,
                              'customers_email_address' => $email_address,
                              'customers_nick' => $nick,
                              'customers_telephone' => $telephone,
                              'customers_fax' => $fax,
                              'customers_newsletter' => (int)$newsletter,
                              'customers_email_format' => $email_format,
                              'customers_default_address_id' => 0,
                              'customers_password' => zen_encrypt_password($password),
                              'COWOA_account' => $cowoa,
                              'customers_authorization' => (int)CUSTOMERS_APPROVAL_AUTHORIZATION
      );
     
      ////////////bof modified for existing cowoa member ////////////////////////////////////
        // check if COWOA account exists for email_address
    $cowoa_accounts = 0;
    if (FEC_NOACCOUNT_COMBINE == 'true') {
      $cowoa_account = $db->Execute("SELECT customers_id, customers_default_address_id FROM " . TABLE_CUSTOMERS . "
                                    WHERE customers_email_address = '" . $email_address . "'
                                    ORDER BY customers_id DESC
                                    LIMIT 1;");
      $cowoa_accounts = $cowoa_account->RecordCount();
   
    }
    if ($cowoa_accounts > 0) {
      // cowoa account exists, use that
      $db_action = 'update';
      $sql_data_array['customers_id'] = $_SESSION['customer_id'] = $cowoa_account->fields['customers_id'];
      $sql_data_array['customers_default_address_id'] = $address_id = $cowoa_account->fields['customers_default_address_id'];
      $sql_data_array['COWOA_account'] = 1;
      $db_customers_where = 'customers_id = "' . $cowoa_account->fields['customers_id'] . '"';
    } else {
      $db_action = 'insert';
      $db_customers_where = '';
    }
    //end modified

      if ((CUSTOMERS_REFERRAL_STATUS == '2' and $customers_referral != '')) $sql_data_array['customers_referral'] = $customers_referral;
      if (ACCOUNT_GENDER == 'true') $sql_data_array['customers_gender'] = $gender;
      if (ACCOUNT_DOB == 'true') $sql_data_array['customers_dob'] = (empty($_POST['dob']) || $dob_entered == '0001-01-01 00:00:00' ? zen_db_prepare_input('0001-01-01 00:00:00') : zen_date_raw($_POST['dob']));

      zen_db_perform(TABLE_CUSTOMERS, $sql_data_array, $db_action, $db_customers_where); //added for modified cowoa

          if ($db_action == 'insert') {
      $_SESSION['customer_id'] = $db->Insert_ID();
    }

      $sql_data_array = array('customers_id' => $_SESSION['customer_id'],
                              'entry_firstname' => $firstname,
                              'entry_lastname' => $lastname,
                              'entry_street_address' => $street_address,
                              'entry_postcode' => $postcode,
                              'entry_city' => $city,
                              'entry_country_id' => $country);

      if (ACCOUNT_GENDER == 'true') $sql_data_array['entry_gender'] = $gender;
      if (ACCOUNT_COMPANY == 'true') $sql_data_array['entry_company'] = $company;
      if (ACCOUNT_SUBURB == 'true') $sql_data_array['entry_suburb'] = $suburb;
      if (ACCOUNT_STATE == 'true') {
        if ($zone_id > 0) {
          $sql_data_array['entry_zone_id'] = $zone_id;
          $sql_data_array['entry_state'] = '';
        } else {
          $sql_data_array['entry_zone_id'] = '0';
          $sql_data_array['entry_state'] = $state;
        }
      }
   
    if ($db_action == 'update') {
      $sql_data_array['address_book_id'] = $address_id;
      $db_address_table_where = 'address_book_id = ' . $address_id;
    } else {
      $db_address_table_where = '';
    }

    zen_db_perform(TABLE_ADDRESS_BOOK, $sql_data_array, $db_action, $db_address_table_where);

    if ($db_action == 'insert') {
      $address_id = $db->Insert_ID();

      $sql = "update " . TABLE_CUSTOMERS . "
                set customers_default_address_id = '" . (int)$address_id . "'
                where customers_id = '" . (int)$_SESSION['customer_id'] . "'";

      $db->Execute($sql);

      $sql = "insert into " . TABLE_CUSTOMERS_INFO . "
                            (customers_info_id, customers_info_number_of_logons,
                            customers_info_date_account_created)
                values ('" . (int)$_SESSION['customer_id'] . "', '0', now())";

      $db->Execute($sql);
  }
  //////////// eof modified for existing cowoa member ////////////////////////////////////
      if (enable_shippingAddress()) {
        // create shipping address

---

Hopefully it makes some scene to you... I've been running it like this for almost a year and haven't found any problems. Both in live and testing it's working out, running now on zencart 1.5.1


The other thing I did so I can just email COWOA users was to make a entry for it in the quary_builder. This is just my phpmyadmin dump. Could do the same for none standard accounts by adding a COWOA_account = 0 check.

Code:

---

INSERT INTO `query_builder` (`query_id`, `query_category`, `query_name`, `query_description`, `query_string`, `query_keys_list`) VALUES
(, 'email', 'COWOA Customers Only', 'Returns COWOA customers name and email address for sending mass emails (ie: for newsletters, coupons, GVs, messages, etc).', 'select customers_email_address, customers_firstname, customers_lastname from TABLE_CUSTOMERS where COWOA_account = 1 order by customers_lastname, customers_firstname, customers_email_address', '');

---

---

Hey Dave...

Thanks for the share, and you are soooo right.. The e-mail list fix is a bandaid, but certainly not a long term solution.. ULTIMATELY what you posted is the RIGHT solution.. I'm afraid this is a bit over my limited skillset to figure out.. FEC's COWOA is just different enough from this module's COWOA to make it over my head to figure out what code to "borrow" from this.. I have an idea as to what I need to do, but it would be trial and error before I got it all worked out.. As an example, my first attempt to "borrow" the right code lead to a SQL duplicate record error.. I'll keep playing, but time is an issue for me, and I don't really have much to keep going at it by trial and error..

Hoping a more astute member of the community can jump in here and provide some guidance..

Again thanks for the share and the push in the right direction..

Quote:

---

Originally Posted by DivaVocals

Hey Dave...

Thanks for the share, and you are soooo right.. The e-mail list fix is a bandaid, but certainly not a long term solution.. ULTIMATELY what you posted is the RIGHT solution.. I'm afraid this is a bit over my limited skillset to figure out.. FEC's COWOA is just different enough from this module's COWOA to make it over my head to figure out what code to "borrow" from this.. I have an idea as to what I need to do, but it would be trial and error before I got it all worked out.. As an example, my first attempt to "borrow" the right code lead to a SQL duplicate record error.. I'll keep playing, but time is an issue for me, and I don't really have much to keep going at it by trial and error..

Hoping a more astute member of the community can jump in here and provide some guidance..

Again thanks for the share and the push in the right direction..

---

OK... may have to slow down for the holidays, but I'm redesigning one of my site with a responsive template. Decided to start fresh so all I have in right now is the template with the 1.5.2 base. I'll drop back and install the COWOA now so I can see where everything is and where to make the changes. Then test and pack it up for you if it works as my current version. This is the 'COWOA Updated and Combined for v1.5.x' right and not the integrated one! Although I'm not sure where the differences are.


Oh.. the duplicate database error comes if the code tries to insert a last login entry for a non-standard account.. the user is not truly logged in, so bounces an error on the customer ID..

I don't mind sharing... wasn't sure I was answering right, was trying to look up code and code a fix for my website at the same time... had to code in an checkbox telling me they read the instructions how to bid before they are allowed to bid... people are amazing... keeps me on my toes I guess. Well drop you a note when I'm done and ready to pass it off... don't have time to support a mod right now.

There are only two versionsof COWOA in the downloads.. one fir v1.3.9 and one for v1.5.x.

No worries on the time.. just appreciate you sharing your code.. :smile: Your response was the right answer.. shoulda been part of COWOA all along..

Quote:

---

Originally Posted by davewest

OK... may have to slow down for the holidays, but I'm redesigning one of my site with a responsive template. Decided to start fresh so all I have in right now is the template with the 1.5.2 base. I'll drop back and install the COWOA now so I can see where everything is and where to make the changes. Then test and pack it up for you if it works as my current version. This is the 'COWOA Updated and Combined for v1.5.x' right and not the integrated one! Although I'm not sure where the differences are.


Oh.. the duplicate database error comes if the code tries to insert a last login entry for a non-standard account.. the user is not truly logged in, so bounces an error on the customer ID..

I don't mind sharing... wasn't sure I was answering right, was trying to look up code and code a fix for my website at the same time... had to code in an checkbox telling me they read the instructions how to bid before they are allowed to bid... people are amazing... keeps me on my toes I guess. Well drop you a note when I'm done and ready to pass it off... don't have time to support a mod right now.

---

I installed COWOA a few weeks ago and everything seemed to be ok, now that I am testing it I notice that the email link takes the customer to the login page. I have searched and searched and I can't find the account_history_info&order page anywhere, how do I fix this?

I installed COWOA a few weeks ago and everything seemed to be ok, now that I am testing it I notice that the email link takes the customer to the login page. I have searched and searched and I can't find the account_history_info&order page anywhere, how do I fix this?

dwest ROCKS!!!

Just wanted to let everyone know that I am testing COWOA v2.5. I have setup a Github repository for COWOA. (https://github.com/DivaVocals/zen_COWOA) The upcoming release is in the v2.5 branch. If you want to test and provide feedback, this is the branch you want to download. The v2.6 branch is in anticipation of the upcoming release of Zen Cart v1.5.2. COWOA v2.6 is NOT ready for beta testing yet.

If you are testing v2.5, please provide feedback for beta releases of COWOA on Github, NOT in this support thread. Thanks.. Here's the changelog for v2.5

Quote:

---

COWOA Module for Zen Cart v2.5

CHANGELOG

v2.5 - 12/29/2013

• Add check to includes/modules/YOUR_TEMPLATE/no_account.php to look for an existing guest (COWOA) account with the same email address and update it instead of creating a new one. Thus, only one account exists for that same email address. If a customer does create a standard account, all the past orders fall back to that same user.(dwest)
• Additional improvements to onscreen text/labels
• Add additional steps arrows
• (This change is ONLY for those upgrading from cv2.4 or older versions of COWOA or converting from older versions of FEC/FEAC) Fixed the duplicate email address/duplicate email send bug. See: http://www.zen-cart.com/showthread.php?59189-My-Checkout-Without-Account-Mod&p=906772#post906772 (damiantaylor)

---

One note about the duplicate account modification (highlighted in red):
Dwests fix to prevent COWOA from creating duplicate guest accounts is awesome and it works perfectly.. However for shops who are upgrading from older versions of COWOA and those converting over from older versions of FEC/FEAC will STILL be left with multiple guest accounts which can wreak havoc if you are sending out customer e-mails or gift certificates. Admittedly while that last fix is an effective solution to this issue, it is not the BEST solution.. A BETTER fix to that last change would be if there was a way to SAFELY combine the duplicate guest customer records COWOA creates. I can articulate WHAT needs to be done, but the SQL script needed to execute this is a bit over my head to create.

The SQL script needed to do this would need to check that if there are multiple customer records and ONE of them is a standard account, that the standard account record is retained while the guest customer records are discarded. If there is no standard account then it will need to retain only the most recent guest account record while discarding the others.. The SQL needs to update all order records associated with the discarded customer record ID and re-associate them with the retained customer record ID.

Quote:

---

Originally Posted by lat9

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

---

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

Quote:

---

Originally Posted by lat9

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

---

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

Code:

---

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

---

Used in tpl_checkout_success_default.php as

Code:

---

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

---

the guest_id section still exist in ZenCart 1.5.2

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

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

Code:

---

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

---

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

Quote:

---

Originally Posted by lat9

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

---

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

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

Code:

---

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

---

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

Quote:

---

Originally Posted by lat9

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

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

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

---

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

@DivaVocals

Quote:

---

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

---

That chunk of code at the bottom of the tpl_order_status_default.php during your next testing/edits could possibly get removed. I may have to play a bit too, my page header is differnt for it too... due to how I'm using returns.

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

So tonight I was able to replicate this issue.

Quote:

---

Originally Posted by Scully

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

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

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

Thanks!!

---

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

BUT..

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

Quote:

---

Originally Posted by lat9

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

---

Quote:

---

Originally Posted by lat9

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

---

Quote:

---

Originally Posted by DivaVocals

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

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

Code:

---

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

---

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

---

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

Code:

---

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

---

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

Code:

---

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

---

Quote:

---

Originally Posted by DivaVocals

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

---

Actually, $_SESSION['customer_guest_id'] is set by the PayPal payment processing when a not-logged-in customer uses the express-checkout button to complete their purchase.

Quote:

---

Originally Posted by lat9

Actually, $_SESSION['customer_guest_id'] is set by the PayPal payment processing when a not-logged-in customer uses the express-checkout button to complete their purchase.

---

Agreed, but this whole codeblock still isn't working as expected, and it's totally noticeable if one is selling downloads..

Quote:

---

Originally Posted by osulywan

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

---

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

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

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

I removed the condition but kept "?>"

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

<?php
}
?>

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

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

Quote:

---

Originally Posted by mdawg

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

---

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

Hi Diva Vocals,

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

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

Thank you!
Magz

Quote:

---

Originally Posted by magz

Hi Diva Vocals,

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

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

Thank you!
Magz

---

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

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

Thanks Diva Vocals...

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

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

Quote:

---

Originally Posted by DivaVocals

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

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

---

Quote:

---

Originally Posted by magz

Thanks Diva Vocals...

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

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

---

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

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

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

Quote:

---

Originally Posted by Eldridge

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

---

Are Pick Up and Pay in Store payment and shipping modules... a single module? What??? Because I'll bet MONEY that you'd have the VERY SAME "issue" with the default checkout process (which COWOA follows).. So sure you COULD re-write the checkout process to accomodate your needs..

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

Quote:

---

Originally Posted by Eldridge

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

---

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

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

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

I'm not sure what's going on with your store, but it certainly seems like you may have other code which is causing this issue.. COWOA out the box wouldn't cause this issue (otherwise there would be MANY MORE folks reporting this same issue) I wish I had some insight to prvide, but it's difficult to troubleshoot an issue that cannot be reproduced..

That said have YOU tested this?? Can YOU re-create the issue.. If you can what were the exact steps to reproduce?? You say you received complaint(s) how many customers?? From ALL customer's ONE customer??? Is this a ONE time ocurrance or does it happen regularly??

Even if you could reproduce the issue, I still don't think it's a COWOA issue (again, because no one else has reported this issue) I suspect that the real issue is some other modification to your store which is being impacted by COWOA..

Quote:

---

Originally Posted by osulywan

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

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

---

Thanks for prompt response, DivaVocals.
We had a huge sale on 4/1. Did 656 orders in 24 hours. All of March I had 920 orders so it definitely could be related to congestion or simultaneous users which I consider more likely. There were items from 3 different customers landed in one customers basket. I have not attempted to reproduce but I found the evidence in customer_basket table. My store items are registrations that include first name and last name as TEXT option values which is how I know customer was correct. Customer_basket has customers_id as column. I saw the 7 rows with her customers_id in customer_basket. When I logged in as her, I saw the items, too. I simply deleted them from her cart to enable her to continue. The items that DID NOT belong in this ladies cart I found in 2 completed orders by 2 different customers less that one minute apart and close to the time I handled this complaint.

Quote:

---

Originally Posted by DivaVocals

That said have YOU tested this?? Can YOU re-create the issue.. If you can what were the exact steps to reproduce?? You say you received complaint(s) how many customers?? From ALL customer's ONE customer??? Is this a ONE time ocurrance or does it happen regularly??

Even if you could reproduce the issue, I still don't think it's a COWOA issue (again, because no one else has reported this issue) I suspect that the real issue is some other modification to your store which is being impacted by COWOA..

---

I have not been able to reproduce this but I purged customer_basket and customer_basket_attributes rows prior to 3/15/2014. I have never had this kind of volume before. My "inventory" (I.e. events) are perishable. When their over, their over. I was hoping for some insight into how COWOA handles basket/cart merge? Perhaps some insight (a file name maybe) of how Zen Cart handles basket/cart merge. I am very early in my investigation. COWOA was the last update I did. I love the way it works and I think it has improved my conversion rate. Get everything out of the way between the customer and the cash register, if you know what I mean. Since I am registering people for events, it is embarrassing to see strangers showing up in your cart at check out.

One other item. I know COWOA prevents customers from checking out without an account if their email address is already on file with an account. I think I tested that. I have found a few customers in my customer table with the same email address. It very well could be I have some other problem going on.

You may see my site here https://www.mellew.com/reg/
Any hints or insight is appreciated.

I have no additional insight to offer.. as I previously stated, I really don't think the problem is COWOA. COWOA simply adds a mechanism for guest check out it doesn't alter the checkout flow or process that is all still stock Zen Cart functionality... Plus without a problem I can't recreate I don't know how I could help you any further...

Quote:

---

Originally Posted by osulywan

Thanks for prompt response, DivaVocals.
We had a huge sale on 4/1. Did 656 orders in 24 hours. All of March I had 920 orders so it definitely could be related to congestion or simultaneous users which I consider more likely. There were items from 3 different customers landed in one customers basket. I have not attempted to reproduce but I found the evidence in customer_basket table. My store items are registrations that include first name and last name as TEXT option values which is how I know customer was correct. Customer_basket has customers_id as column. I saw the 7 rows with her customers_id in customer_basket. When I logged in as her, I saw the items, too. I simply deleted them from her cart to enable her to continue. The items that DID NOT belong in this ladies cart I found in 2 completed orders by 2 different customers less that one minute apart and close to the time I handled this complaint.

I have not been able to reproduce this but I purged customer_basket and customer_basket_attributes rows prior to 3/15/2014. I have never had this kind of volume before. My "inventory" (I.e. events) are perishable. When their over, their over. I was hoping for some insight into how COWOA handles basket/cart merge? Perhaps some insight (a file name maybe) of how Zen Cart handles basket/cart merge. I am very early in my investigation. COWOA was the last update I did. I love the way it works and I think it has improved my conversion rate. Get everything out of the way between the customer and the cash register, if you know what I mean. Since I am registering people for events, it is embarrassing to see strangers showing up in your cart at check out.

One other item. I know COWOA prevents customers from checking out without an account if their email address is already on file with an account. I think I tested that. I have found a few customers in my customer table with the same email address. It very well could be I have some other problem going on.

You may see my site here https://www.mellew.com/reg/
Any hints or insight is appreciated.

---

Quote:

---

Originally Posted by osulywan

Thanks for prompt response, DivaVocals.
We had a huge sale on 4/1. Did 656 orders in 24 hours. All of March I had 920 orders so it definitely could be related to congestion or simultaneous users which I consider more likely. There were items from 3 different customers landed in one customers basket. I have not attempted to reproduce but I found the evidence in customer_basket table. My store items are registrations that include first name and last name as TEXT option values which is how I know customer was correct. Customer_basket has customers_id as column. I saw the 7 rows with her customers_id in customer_basket. When I logged in as her, I saw the items, too. I simply deleted them from her cart to enable her to continue. The items that DID NOT belong in this ladies cart I found in 2 completed orders by 2 different customers less that one minute apart and close to the time I handled this complaint.

I have not been able to reproduce this but I purged customer_basket and customer_basket_attributes rows prior to 3/15/2014. I have never had this kind of volume before. My "inventory" (I.e. events) are perishable. When their over, their over. I was hoping for some insight into how COWOA handles basket/cart merge? Perhaps some insight (a file name maybe) of how Zen Cart handles basket/cart merge. I am very early in my investigation. COWOA was the last update I did. I love the way it works and I think it has improved my conversion rate. Get everything out of the way between the customer and the cash register, if you know what I mean. Since I am registering people for events, it is embarrassing to see strangers showing up in your cart at check out.

One other item. I know COWOA prevents customers from checking out without an account if their email address is already on file with an account. I think I tested that. I have found a few customers in my customer table with the same email address. It very well could be I have some other problem going on.

You may see my site here https://www.mellew.com/reg/
Any hints or insight is appreciated.

---

Did you by any chance post a link containing the zenid at the end? This is known to cause people sharing carts

Quote:

---

Originally Posted by Design75

Did you by any chance post a link containing the zenid at the end? This is known to cause people sharing carts

---

and if this is the issue it's still NOT a COWOA issue.. it's a ZEN CART issue..

Quote:

---

Originally Posted by DivaVocals

and if this is the issue it's still NOT a COWOA issue.. it's a ZEN CART issue..

---

:yes: I agree, but just thought to try to get the OP on the right track.

Quote:

---

Originally Posted by Design75

:yes: I agree, but just thought to try to get the OP on the right track.

---

I KNEW there was a method to your madness as usual!!!:laugh:

Quote:

---

Originally Posted by osulywan

One other item. I know COWOA prevents customers from checking out without an account if their email address is already on file with an account. I think I tested that. I have found a few customers in my customer table with the same email address. It very well could be I have some other problem going on.

---

This is "normal" and not truly an issue with the current version of COWOA, but there probably should only be ONE customer record per e-mail address. With DaveWest's help I have an update to COWOA that currently is only available on GitHub which changes this so only ONE customer record per e-mail is created. page back a few pages in this support thread to get to the GitHub repo URL with this new version of COWOA..

Version 2.0c Dated August 29, 2010 installed

Can I up date my 1.5.1 cart to the new version 2.4 or do I need to uninstall and reinstall new. I see that the instruction refer to 2.3-t2.4

Sorry if this has been answered if so I missed it.

Sorry if this is not the place for this... but...

I have my zen cart working nicely... and the COWOA plugin...

I have an issue with the emails sent when a customer uses the 'Guest Checkout'

the email sent to the customer doesnt have Template Keywords replaced with the correct text.
if you sign up, and checkout, it all works as it should.

Could someone point me in the right direction to solve this problem...?

Cheers, and thanks in advance

Attachment 13965

Quote:

---

Originally Posted by 00falcon

Sorry if this is not the place for this... but...

I have my zen cart working nicely... and the COWOA plugin...

I have an issue with the emails sent when a customer uses the 'Guest Checkout'

the email sent to the customer doesnt have Template Keywords replaced with the correct text.
if you sign up, and checkout, it all works as it should.

Could someone point me in the right direction to solve this problem...?

Cheers, and thanks in advance

Attachment 13965

---

Didn't you post this same question in the FEC support thread?? which module are you using??

Quote:

---

Originally Posted by 00falcon

Sorry if this is not the place for this... but...

I have my zen cart working nicely... and the COWOA plugin...

I have an issue with the emails sent when a customer uses the 'Guest Checkout'

the email sent to the customer doesnt have Template Keywords replaced with the correct text.
if you sign up, and checkout, it all works as it should.

Could someone point me in the right direction to solve this problem...?

---

So... two possibilities.. you missed uploading the language file (estra_definitions/checkout_process.php) or missed editing/uploading the (class/order.php) class file.

First you'll have to figure out what mod you installed... FEC is different :huh:

When trying to use the module with a FREE DOWNLOAD Virtual product, the "Order Review" page is empty.

My guess is that it has something to do with not having any Payment Options selected (since the product is free). Any ideas how to allow a free virtual product to be checked out?

By the way, if I turn off the COWOA module, it's still the same behavior. I'm on 1.5.1.

Quote:

---

Originally Posted by Jeff_Mash

When trying to use the module with a FREE DOWNLOAD Virtual product, the "Order Review" page is empty.

My guess is that it has something to do with not having any Payment Options selected (since the product is free). Any ideas how to allow a free virtual product to be checked out?

By the way, if I turn off the COWOA module, it's still the same behavior. I'm on 1.5.1.

---

NOTE: In order to get around this, I had to come up with a workaround. I had to set my free virtual item with a price of $1.00. I then had to give my customers a $1.00 Off Coupon to use during the checkout. That is the ONLY WAY I have found to complete the checkout using this module with only a free virtual item in the cart.

I am still hoping that someone here can help pinpoint the reason why it's not working, and how to allow free virtual items to be purchased alone during the checkout using this module.

As you pointed out the issue persists even with this module off.. That's the clue that the issue is not with this module but with the way virtual products are configured.. I would suggest checking out some of the threads on configuring virtual products nd make sure you've got yours configured correctly..

Quote:

---

Originally Posted by Jeff_Mash

NOTE: In order to get around this, I had to come up with a workaround. I had to set my free virtual item with a price of $1.00. I then had to give my customers a $1.00 Off Coupon to use during the checkout. That is the ONLY WAY I have found to complete the checkout using this module with only a free virtual item in the cart.

I am still hoping that someone here can help pinpoint the reason why it's not working, and how to allow free virtual items to be purchased alone during the checkout using this module.

---

Okay - I found a fix, thanks to Ajeh in the following thread:
http://www.zen-cart.com/showthread.p...download/page4

Basically, if you open your templates/tpl_checkout_confirmation_default.php file, you will see the following line somewhere in there:

Code:

---

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

---

That's basically saying, "Show the contents of the shopping cart as long as the value is NOT zero." Well, since we are dealing with a free item, nothing is being displayed, and thus a blank page is being shown.

So to fix it, I simply did this and changed the value to negative one:

Code:

---

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

---

Hope that helps out someone.

Downloaded and installed COWOA for Zen 1.5. Of course I backed up my site before I did that. That was good! when I reloaded the site, all the formatting when crazy. Instead of being in normal format, it was the full width of the screen. Using Responsive Avonlee Contempo template bt Picaflor. Any assistance would be greatly appreciated.

Quote:

---

Originally Posted by Chuck Cory

Downloaded and installed COWOA for Zen 1.5. Of course I backed up my site before I did that. That was good! when I reloaded the site, all the formatting when crazy. Instead of being in normal format, it was the full width of the screen. Using Responsive Avonlee Contempo template bt Picaflor. Any assistance would be greatly appreciated.

---

COWOA is designed around the basic template that comes with Zen Cart. If you just replaced the files with your modified template files, then it would mess things up. The instructions list files that need to be compared and modified if you are not using the basic templates design.

If you did the change on a live site, I would upload the backup files that COWOA replaced and use a compare program to modify the files or open both files in two instances of a text editor and look for the COWOA markers to make the changes.

Back in Oct, Scully pointed out a problem with clicked COWOA download links leading to a "Session Has Expired" error instead of the purchased file that was never solved [http://www.zen-cart.com/showthread.p...5-x%29/page39].

The best guess answer presented was that 'it is something with the server, and maybe specific to your site'.

But I am getting the exact same issue, and the Session-Expired error happens ONLY on COWOA orders and not the normal 'create account' orders. (ZC 1.5.1, COWOA 2.4)

The error is the same on both the Order Confirmation page and when a customer accesses the download via the Order Status link in the confirmation email. In both COWOA locations, the downloadable file is not presented when the download link is clicked, but rather the Session Expired error appears (with the text to either login or 'sorry, cart can't be restored'). Obviously, this angers the COWOA customer because they have no way of accessing what they just paid for.

The links presented for an account-creation user work exactly as expected on the order confirmation and order status pages, so I believe the situation is specific to COWOA.

I saw that the COWOA order confirmation page tpl_checkout_success_default.php had a COWOA-specific download module, so I've already tried combining the two download presentations if/then for each option. Everything 'presents' properly when I do so, but the COWOA download links still go to session error when clicked.

Any ideas? Thank you...

NEVER MIND!

The solution was presented in that exchange, but it wasn't clear to Scully then or to me when I read it. But now that I've re-read the entire exchange again, the answer is to go to the COWOA Admin and turn to 'false' the option "Enable Forced Logoff".

When I setup the module, I assumed that making that option 'true' would allow the user the option to log off after completing his or her checkout. I didn't get that it would automatically log the user off AND disable access to any and all downloadable file links.

A person selling downloads in Zen Cart MUST HAVE the the COWOA Admin option "Enable Forced Logoff" set to 'false' -- or else the customer has no opportunity to download their purchase, ever!

BTW, in the COWOA admin, the explanation for the 'Enable Forced Logoff' is NOT correct.

It says:

Enable The Forced LogOff Function of COWOA?
Set to True so that a Customer that uses COWOA will be logged off automatically after a sucessfull checkout. If they are getting a file download, then they will have to wait for the Status E-Mail to arrive in order to download the file.


But in reality, setting the option to 'true' also disables the status email download links, too. That's why having this option set to 'true' will make a download customer curse you! LOL

it's a KNOWN bug.. This part of the code has not worked correctly in some time..

Quote:

---

Originally Posted by AllenFreeman

BTW, in the COWOA admin, the explanation for the 'Enable Forced Logoff' is NOT correct.

It says:

Enable The Forced LogOff Function of COWOA?
Set to True so that a Customer that uses COWOA will be logged off automatically after a sucessfull checkout. If they are getting a file download, then they will have to wait for the Status E-Mail to arrive in order to download the file.


But in reality, setting the option to 'true' also disables the status email download links, too. That's why having this option set to 'true' will make a download customer curse you! LOL

---

Explained here: http://www.zen-cart.com/showthread.p...80#post1237580

Quote:

---

Originally Posted by DivaVocals

it's a KNOWN bug.. This part of the code has not worked correctly in some time..

---

Quote:

---

Originally Posted by DivaVocals

it's a KNOWN bug.. This part of the code has not worked correctly in some time..

---

What... another bug!

OK... so downloads was working for me on one of my old sites... most be me again!

Recreating by doing a clean install
Zen Cart 1.5.2,
responsive template,
email archive manager 1.7b,
integrated COWOA 2.4 for ZC 1.5.2
xamp php 5.5.11

so.. no code edits, using downloads as designed, if a payment method was used that had an order status as Pending (default), no download would show as expected. Admin would have to change the status to Processing, add a comment for the buyer to access the download by using the order status page or account history if they have an account. Once email and order ID was entered, the download button would show on the status page or account page as expected. I wouldn't send the product download link by email or run the risk of many free downloads occurring.

This is where it gets interesting, if I use a payment method that has an order status of Processing, the download button should appear on the checkout success page. Well It seems to be blocked at line 122, and a session kill at line 80 for COWOA users, but not for account holders.

I'll leave the session destroy switch in place, uses, 'false' allow downloads to work, 'true' do zen_session_destroy() no downloads for COWOA users. So, line 82 section of code is modified to this;

includes/templates/YOUR_TEMPLATE/templates/tpl_checkout_sucess_default.php

Code:

---

if (isset($_SESSION['customer_guest_id']) || ($_SESSION['COWOA'])) {

---

line 122 remove the COWOA check;

Code:

---

if (DOWNLOAD_ENABLED == 'true') require($template->get_template_dir('tpl_modules_downloads.php',DIR_WS_TEMPLATE, $current_page_base,'templates'). '/tpl_modules_downloads.php');

---

We need to fix the download link for COWOA users so they don't think they have a account history page. Copy tpl_modules_downloads.php from the default template folder to yours and change line 86 to something that works for you..

includes/templates/YOUR_TEMPLATE/templates/tpl_modules_downloads.php

Code:

---

<p><?php if(!($_SESSION['COWOA'])) { printf(FOOTER_DOWNLOAD, '<a href="' . zen_href_link(FILENAME_ACCOUNT, '', 'SSL') . '">' . HEADER_TITLE_MY_ACCOUNT . '</a>');
  } else {
    printf(FOOTER_DOWNLOAD_COWOA);
  }?></p>

---

Add to the language page for checkout success so it makes sense...

includes/languages/english/checkout_success.php

Code:

---

define('FOOTER_DOWNLOAD_COWOA', 'You can also download your products at a later time using the Order Status page.');

---

Play with this on a testing environment first, I didn't spend allot of time testing it out, but seems to work for me..

Damn Dave.. I love you! On a plane waiting for takeoff.. as soon as I get home gonna test this and confirm the results..
Did I mention how awesome you are.. again..

Quote:

---

Originally Posted by davewest

What... another bug!

OK... so downloads was working for me on one of my old sites... most be me again!

Recreating by doing a clean install
Zen Cart 1.5.2,
responsive template,
email archive manager 1.7b,
integrated COWOA 2.4 for ZC 1.5.2
xamp php 5.5.11

so.. no code edits, using downloads as designed, if a payment method was used that had an order status as Pending (default), no download would show as expected. Admin would have to change the status to Processing, add a comment for the buyer to access the download by using the order status page or account history if they have an account. Once email and order ID was entered, the download button would show on the status page or account page as expected. I wouldn't send the product download link by email or run the risk of many free downloads occurring.

This is where it gets interesting, if I use a payment method that has an order status of Processing, the download button should appear on the checkout success page. Well It seems to be blocked at line 122, and a session kill at line 80 for COWOA users, but not for account holders.

I'll leave the session destroy switch in place, uses, 'false' allow downloads to work, 'true' do zen_session_destroy() no downloads for COWOA users. So, line 82 section of code is modified to this;

includes/templates/YOUR_TEMPLATE/templates/tpl_checkout_sucess_default.php

Code:

---

if (isset($_SESSION['customer_guest_id']) || ($_SESSION['COWOA'])) {

---

line 122 remove the COWOA check;

Code:

---

if (DOWNLOAD_ENABLED == 'true') require($template->get_template_dir('tpl_modules_downloads.php',DIR_WS_TEMPLATE, $current_page_base,'templates'). '/tpl_modules_downloads.php');

---

We need to fix the download link for COWOA users so they don't think they have a account history page. Copy tpl_modules_downloads.php from the default template folder to yours and change line 86 to something that works for you..

includes/templates/YOUR_TEMPLATE/templates/tpl_modules_downloads.php

Code:

---

<p><?php if(!($_SESSION['COWOA'])) { printf(FOOTER_DOWNLOAD, '<a href="' . zen_href_link(FILENAME_ACCOUNT, '', 'SSL') . '">' . HEADER_TITLE_MY_ACCOUNT . '</a>');
  } else {
    printf(FOOTER_DOWNLOAD_COWOA);
  }?></p>

---

Add to the language page for checkout success so it makes sense...

includes/languages/english/checkout_success.php

Code:

---

define('FOOTER_DOWNLOAD_COWOA', 'You can also download your products at a later time using the Order Status page.');

---

Play with this on a testing environment first, I didn't spend allot of time testing it out, but seems to work for me..

---

I have a question. This all module it to make is easier and faster...just why to ask my customers all these data if he/she is not going to open account? Is the is a way to disable some of the fields required to be fill out in billing info?
http://www.polish-your-art.com/bouti...age=no_account
I already done this with standard create account but can not find a file where these quest or no account data are included.
http://www.polish-your-art.com/bouti...create_account
I got now let info needed to create account then in billing info for COWOA. I would like to have it the same way. I am selling only downloadable product and also do not need shipping. Is the is a way to remove or to skip this step when buying downloadable product?

Quote:

---

Originally Posted by Marta van Eck

I have a question. This all module it to make is easier and faster...just why to ask my customers all these data if he/she is not going to open account? Is the is a way to disable some of the fields required to be fill out in billing info?
http://www.polish-your-art.com/bouti...age=no_account
I already done this with standard create account but can not find a file where these quest or no account data are included.
http://www.polish-your-art.com/bouti...create_account
I got now let info needed to create account then in billing info for COWOA. I would like to have it the same way. I am selling only downloadable product and also do not need shipping. Is the is a way to remove or to skip this step when buying downloadable product?

---

I'm hoping that DivaVocals will forgive me for hijacking this thread:lookaroun, but it sounds like "Minimum Customer Account Information" (http://www.zen-cart.com/downloads.php?do=file&id=1465) might be of help. That plugin will allow you to significantly reduce the number of fields required to create an account, but it is not integrated with COWOA, so your customers will need to create an account if you use it. Note also that some people who sell only downloadable products still want to capture the customer's address information during account creation, since some customers will be paying via credit card.

Thank you lat9 for your answer. I think that add will not help me. I already got let info for customers who are willing to create an account. But this COWOA looks like a good alternative for those who do not like filling to much info on unknown server. It all looks and work ok after all small changes I made according what davewest wrote. The only think I do not want to is too much info to collects. I do not need street and state and country because nothing will be shipped. And telephone...also do not need it. It work smooth and I like the mod very much , just I afraid some customers will not be willing to write those data. So maybe someone know how to disabled this?

Quote:

---

Originally Posted by lat9

I'm hoping that DivaVocals will forgive me for hijacking this thread:lookaroun, but it sounds like "Minimum Customer Account Information" (http://www.zen-cart.com/downloads.php?do=file&id=1465) might be of help. That plugin will allow you to significantly reduce the number of fields required to create an account, but it is not integrated with COWOA, so your customers will need to create an account if you use it. Note also that some people who sell only downloadable products still want to capture the customer's address information during account creation, since some customers will be paying via credit card.

---

Quote:

---

Originally Posted by Marta van Eck

Thank you lat9 for your answer. I think that add will not help me. I already got let info for customers who are willing to create an account. But this COWOA looks like a good alternative for those who do not like filling to much info on unknown server. It all looks and work ok after all small changes I made according what davewest wrote. The only think I do not want to is too much info to collects. I do not need street and state and country because nothing will be shipped. And telephone...also do not need it. It work smooth and I like the mod very much , just I afraid some customers will not be willing to write those data. So maybe someone know how to disabled this?

---

Why wouldn't this help?? lat9 gave you a VERY VIABLE solution that WILL solve your issue.. I think lat9 is saying that you can try to apply the changes in her mod to the no_account page since it is based on the create_account page.. (IJS...)

I understand that this mod will make possible to reduce to minimum data that are now required in COWOA? I just have change it by hand, apply the changes to no_ ccount page from create _account? Is this mean no_account in COWOA is equivalent to create_ account in standard procedure?

Quote:

---

Originally Posted by Marta van Eck

I understand that this mod will make possible to reduce to minimum data that are now required in COWOA? I just have change it by hand, apply the changes to no_ ccount page from create _account? Is this mean no_account in COWOA is equivalent to create_ account in standard procedure?

---

Yes.. Here's the dirty little secret of ANY "checkout without account" process.. you still have to collect BILLING/SHIPPING data.. So YES the "create account" and "no account" processes are the SAME.. If you look at the code for these two pages you will see that the code on these pages is similar.. On the back end the ONLY difference between the two customer records is the COWOA flag.. One customer can skip the process of entering their billing/shipping information on any subsequent visits to your store because they can login in and bypass this part of the checkout, the other customer can either create an account or enter their billing/shipping information on any subsequent visits.

This is what some customers want to avoid.Filling any billing info. OK thank you for help. I will try to compare both file, use the mod and then see if this helps. I also got Paypal express checkout. Seems this let to avoid to create account and also do not require any billing info. SO maybe some customers will use this method. Thanks again.

Quote:

---

Originally Posted by Marta van Eck

This is what some customers want to avoid.Filling any billing info. OK thank you for help. I will try to compare both file, use the mod and then see if this helps.

---

You are VERY wrong.. If you are accepting PayPal or credit cards, then BILLING information is required, and this is something your customers CANNOT avoid entering.. Your customers CANNOT pay via credit card on ANY site without entering BILLING information.. Your customers cannot pay via PayPal on ANY site without entering billing information.. You are spinning your wheels trying to FIX an issue that doesn't require FIXING..

Quote:

---

Originally Posted by Marta van Eck

I also got Paypal express checkout. Seems this let to avoid to create account and also do not require any billing info. SO maybe some customers will use this method. Thanks again.

---

Wrong again.. BEHIND the scenes an account is created in Zen Cart because an order record needs to be tied to a customer record.. BEHIND THE SCENES PayPal is also collecting this information because they need to have BILLING DATA (name, address, etc). Have you EVER paid with PayPal and NOT had to enter billing data (because you don't have a PayPal account) or confirm billing data on file (because you created a PayPal account and have your WHAT?? BILLING DATA on file)

You are spending an AWFUL lot of time on something that TRULY isn't as big of a problem as you are making it out to be.. But good luck with your shop..

Quote:

---

Originally Posted by DivaVocals

You are VERY wrong.. If you are accepting PayPal or credit cards, then BILLING information is required, and this is something your customers CANNOT avoid entering.. Your customers CANNOT pay via credit card on ANY site without entering BILLING information.. Your customers cannot pay via PayPal on ANY site without entering billing information.. You are spinning your wheels trying to FIX an issue that doesn't require FIXING..

Wrong again.. BEHIND the scenes an account is created in Zen Cart because an order record needs to be tied to a customer record.. BEHIND THE SCENES PayPal is also collecting this information because they need to have BILLING DATA (name, address, etc). Have you EVER paid with PayPal and NOT had to enter billing data (because you don't have a PayPal account) or confirm billing data on file (because you created a PayPal account and have your WHAT?? BILLING DATA on file)

You are spending an AWFUL lot of time on something that TRULY isn't as big of a problem as you are making it out to be.. But good luck with your shop..

---

I know that PAYPAL behind the scenes create the customers data ( credit card too)...but then the lazy customers do not have to do this. I do not want to repair an issue. There were already before some questions in this thread how to reduce the number of billing information. I just got some complains of customers who want to buy but they ask why i do need sooooo many information. I know that buying without billing info is not possible but if this happens behind the scenes some customers think it did not happens and they are happy they did not have to fill any info. I think today people got less trust about leaving their data of foreign serwer. But I must thank for the add . I am using it and still some customers were able to give that data without complaining.

Quote:

---

Originally Posted by Marta van Eck

I know that PAYPAL behind the scenes create the customers data ( credit card too)...but then the lazy customers do not have to do this. I do not want to repair an issue. There were already before some questions in this thread how to reduce the number of billing information. I just got some complains of customers who want to buy but they ask why i do need sooooo many information. I know that buying without billing info is not possible but if this happens behind the scenes some customers think it did not happens and they are happy they did not have to fill any info. I think today people got less trust about leaving their data of foreign serwer. But I must thank for the add . I am using it and still some customers were able to give that data without complaining.

---

**sigh**

You are STILL mistating/misunderstanding how COWOA works..

"lazy customers" (your words) still MUST enter BILLING information.. PayPal and other credit card processors REQUIRE THIS. There is NOWHERE in any part of the checkout process "lazy customers" DO NOT have to provide this data..

Guest checkout features only SKIP the step of creating a username and password.. COWOA also adds "order step" features to the checkout process (for both standard and guest checkout processes) which help customers CLEARLY see where they are in the checkout process.




Comments added for the benefit of anyone following this thread so that misinformation is clarified

I just installed this to my new site, and in spite of doing so in exactly the same way as every other mod I've uploaded, it seems to have had no effect at all on the site, is there more I need to do after uploading that I'm somehow missing?

Quote:

---

Originally Posted by kitutal

I just installed this to my new site, and in spite of doing so in exactly the same way as every other mod I've uploaded, it seems to have had no effect at all on the site, is there more I need to do after uploading that I'm somehow missing?

---

Did you turn it on? (from the admin config)

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

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

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

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

Hi
Looking through the file structure.... Am I correct in assuming there is only one file (audience.php) to upload IF we are upgrading?
OR do I need to overwrite all files?

Thanks

Quote:

---

Originally Posted by Rizla

Hi
Looking through the file structure.... Am I correct in assuming there is only one file (audience.php) to upload IF we are upgrading?
OR do I need to overwrite all files?

Thanks

---

no.. you would not be correct.. all the changes I've listed in the changelog would involve MORE than just one file.

It was the singular file in the update dir that through me.... So, this file needs to also be ported across? I presume the SQL is the same? or maybe not lol

Quote:

---

Originally Posted by Rizla

It was the singular file in the update dir that through me.... So, this file needs to also be ported across? I presume the SQL is the same? or maybe not lol

---

You can choose to cherrypick files to do this upgrade or you can simply follow best practices and upload the new version.. the changelog I listed involves MANY file changes.. use file comparison software to see all of the changes.. I believe the readme was updated to explain the changes and install/upgrade.

I only had one file to merge - English.php
Installed as new and over wrote all files

SQL uninstalled and re-installed but I get a 'yellow' error: Note: 2 statements ignored. See "upgrade_exceptions" table for additional details.

I go to admin config and select COWOA but there are no contents....

URGENT please as this in on my live site

Thanks

Panic ye NOT!

It's working......

Somehow it's all showing in config now

All good and I like the layout much better.

May have found one bug (not sure)

After testing if a customer places an item in the cart and then goes to checkout, creates an account (either way) but at some point they decide to empty the cart.... there appears to be no way to log-out.

Close down and come back and the system states 'Login' in the header bar, upon clicking it I fine I'm still logged in. There is no log-out button.

I have, for now, set auto logoff on completion but completing the sale was the only way to get logged off.

Ring any bells?

And another...

Can't login as returning customer on checkout page. Just get blank white screen.

Sorry to be a pain but any idea how long to fix?

On returning customer login the log shows:

[18-Jul-2014 14:35:52 Europe/London] PHP Fatal error: Call to undefined function password_needs_rehash() in /home/metalpix/public_html/includes/modules/pages/login/header_php.php on line 68

Quote:

---

Originally Posted by Rizla

And another...

Can't login as returning customer on checkout page. Just get blank white screen.

Sorry to be a pain but any idea how long to fix?

---

I am on vacation.. will look at it when I return next week.. It's a beta version, and I posted it on Github for testing puposes before submitting to the free plugins.. if anyone forks my repo and submits a change before I return, then that would be awesome.. That's the whole reason I created a Github repo.. to encourage contributors/collaboration.. However, I will not able to look at or work on this 'til I return..

Guessing I missed something that v1.5.3 adds to this file..

Quote:

---

Originally Posted by Rizla

On returning customer login the log shows:

[18-Jul-2014 14:35:52 Europe/London] PHP Fatal error: Call to undefined function password_needs_rehash() in /home/metalpix/public_html/includes/modules/pages/login/header_php.php on line 68

---

Quote:

---

Originally Posted by DivaVocals

Guessing I missed something that v1.5.3 adds to this file..

---

I installed github version, on a ZC 1.5.3 test site, with responsive sheffield blue and links manager installed, could not get it to reproduce the error!! I did a full checkout with out an account, stopped and added, deleted then finely deleted all items, no problems... created an account, checked out same, no problems... can not recreate the error.. login/logoff is performing as should be... COWOA is performing as expected.... if I trashed the login script on common/tpl_header.php I can get login/logoff issues, but I have to destroy all of it... Without looking at your files, I would have to say you need to go back and recopy the files over. If you have a heavy modified site, you may have to do some editing to get common/tpl_header.php coded right.
I will have to see how much space I have left then maybe do a fork for the installation issue fix...

Hi Dave
I have checked and re-checked tpl_header.php and there is really no change to the file apart from version.

Can you make a purchase using 'returning customer' ?

If so, then I may have missed a merge and will re-check

Please Ignor

Using Beyond Compare (now) and found some merges from original template file.... So log off is now working

Quote:

---

Originally Posted by davewest

I installed github version, on a ZC 1.5.3 test site, with responsive sheffield blue and links manager installed, could not get it to reproduce the error!! I did a full checkout with out an account, stopped and added, deleted then finely deleted all items, no problems... created an account, checked out same, no problems... can not recreate the error.. login/logoff is performing as should be... COWOA is performing as expected.... if I trashed the login script on common/tpl_header.php I can get login/logoff issues, but I have to destroy all of it... Without looking at your files, I would have to say you need to go back and recopy the files over. If you have a heavy modified site, you may have to do some editing to get common/tpl_header.php coded right.
I will have to see how much space I have left then maybe do a fork for the installation issue fix...

---

Thanks for verifying things Dave.. Honestly, I didn't think there was an issue with the modules files.. As I USUALLY do, I spent a fair bit of time working on this version before publishing the Github repo here.. I have made quitea few changes this go around, and want to make sure it all worked before shring.. I felt that Rizla's issue was more likely an install issue due to errant merges or files not being copied over. That said it's POSSIBLE that the install SQL might require a once over.. So I APPRECIATE the assist sir!

I can confirm that I have gone through every file and merged where required, and they were template files only. Hence my 'log off' now appears.

I have also removed and re-installed twice today including the SQL and can confirm that on my site at least, returning customer does not work.
I get the following error in the logs:

[19-Jul-2014 16:32:34 Europe/London] PHP Fatal error: Call to undefined function password_needs_rehash() in /home/metalpix/public_html/includes/modules/pages/login/header_php.php on line 68

IF, I enter an incorrect password in the 'existing customer' fields then it correctly displays the system error that no one exists with that user name or password, as expected.

If I fall to my backup with the original COWOA, then all works.

Hope this helps

Quote:

---

Originally Posted by Rizla

Hi
Looking through the file structure.... Am I correct in assuming there is only one file (audience.php) to upload IF we are upgrading?
OR do I need to overwrite all files?

Thanks

---

Going back through your post to try and figure out what your doing.... not giving us much to go on. but this file audience.php is a core ZC file, not part of COWOA! not modified by COWOA...

Quote:

---

[19-Jul-2014 16:32:34 Europe/London] PHP Fatal error: Call to undefined function password_needs_rehash() in //includes/modules/pages/login/header_php.php on line 68

---

COWOA does not mess with how ZC handles passwords, password_needs_rehash() is not a COWOA function, just hides things when someone checks out thinking they did not create an account.... does not change how existing accounts work!

I can not recreate the problem so guessing you did something else from your comments that's not an COWOA issue. are you doing this on a test site or live! hopfully you are working on a test site... I would re-install ZC and start over...

<Sigh> Please take the time to a least read through ALL the threads.... That asked BEFORE I contemplated installation!
Dave, I asked a simple question.... Can you make purchase through 'Returning Customer' ??

'IF' you CAN.... Then I have something 'a' miss... You have not given me an answer o that question.

All files that are 'template' related I have now 're-merged' Originally using winmerge but swapped for beyond compare. All template file are merged correctly. Hence my original problem went away. (log out) as stated!

All the other files are a simple over write of the COWOA files from the old version (or am I mistaken?)

COWOA was working fine, until the upgrade and now I have the one issue.... Somewhere it 'aint reading the DB although it does as far as entering an invalid P/W... That it will pick up on.

So..." password_needs_rehash()" is NOT an error through the new COWOA then? As NOTHING has changed BUT the installation of the new COWOA.... Curious to say the least

"I can not recreate the problem so guessing you did something else from your comments that's not an COWOA issue. are you doing this on a test site or live"

LIVE

"I would re-install ZC and start over... " There is a thing called BACK-UP reinstall... lol forget it!

Now Dave... Can you use the 'returning customer' ?? ALL I ASKED

Quote:

---

Originally Posted by davewest

I installed github version, on a ZC 1.5.3 test site, with responsive sheffield blue and links manager installed, could not get it to reproduce the error!! I did a full checkout with out an account, stopped and added, deleted then finely deleted all items, no problems... created an account, checked out same, no problems... can not recreate the error.. login/logoff is performing as should be... COWOA is performing as expected....

---

As above... yes... I can create new, login/logout, delete, and recreate accounts and all is good... COWOA doesn't affect how ZC functions as to accounts, only hide the fact that an account was created during checkout...

Quote:

---

"I would re-install ZC and start over... " There is a thing called BACK-UP reinstall... lol forget it!

Now Dave... Can you use the 'returning customer' ?? ALL I ASKED

---

If you are talking non-account returning, yes no problem... if your asking about account holders, yes, no problem... restoring form a GOOD backup yes... bad one.... not so good...
Without looking at your site we are working with only what your willing to tell us... maybe I missed this... but what is it your working with!
is this a new ZC1.5.3 or an upgrade? if so, how did you do the upgrade!
What version of PHP, MySQL is it running on

Anyway... running out of time and I don't seem to be helping you much.... off to work I go.. hope to be back in 14-28 days...

Quote:

---

Originally Posted by davewest

Going back through your post to try and figure out what your doing.... not giving us much to go on. but this file audience.php is a core ZC file, not part of COWOA! not modified by COWOA...

---

Actually there is a "bandaid fix" to the duplicate customer records for those upgrading to the latest version of COWOA.. This change is not required for new installations of COWOA. It relates to this issue: https://github.com/DivaVocals/zen_COWOA/issues/5. A true solution to this issue would eliminate the need for this modification to the includes/functions/audience.php file for those upgrading from older versions of COWOA..

Thanks for trying to help out Dave.. I'd like to add to what you've posted here..

Rizla, in my ORIGINAL post announcing the latest version of COWOA, I made it clear that it was a BETA release for TESTING feedback BEFORE submission to the plugins section here. If you go to the original post, I made the subject line so this was CRYSTAL clear..

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

Quote:

---

Originally Posted by DivaVocals

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

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

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

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

---

I also made sure the readme for the Github repo CLEARLY states that this is a BETA release

Quote:

---

This is a development version of COWOA only

If you are looking to install the latest version from zencart please visit this page

If you need basic installation help, and the included readme does not help you, please visit the COWOA Support Thread

---

While this release came from changes I made for a number of my clients on their live stores, and I have tested it, I STILL would NOT suggest anyone install this BETA version on a live store UNLESS and UNTIL they too have done their own testing on a DEVELOPMENT STORE.. Which is why I posted the link to the Github repo to get TESTING feedback and make any changes required before submitting this new version of COWOA to the Zen Cart downloads. This was NEVER meant to be a "sneak preview/early release" version. If it was I would have clearly stated this.

Dave is right, at this point we cannot help you because we CANNOT recreate your test findings.. You need to roll back your live store, then create a proper dev/test clone of your store which is the ONLY PLACE you should be installing this version of COWOA to make SURE it works in your setup BEFORE moving it over to your live site. Testing should NEVER be done on a live store.. This is NO DIFFERENT than how any other Zen Cart upgrade should work whether it's the core code or a new/updated module..

You also need to provide a LOT more information than you have provided.. (Zen Cart version, what version of COWOA you are upgrading from, and any other relevant information)

Quote:

---

Originally Posted by davewest

As above... yes... I can create new, login/logout, delete, and recreate accounts and all is good... COWOA doesn't affect how ZC functions as to accounts, only hide the fact that an account was created during checkout...



If you are talking non-account returning, yes no problem... if your asking about account holders, yes, no problem... restoring form a GOOD backup yes... bad one.... not so good...
Without looking at your site we are working with only what your willing to tell us... maybe I missed this... but what is it your working with!
is this a new ZC1.5.3 or an upgrade? if so, how did you do the upgrade!
What version of PHP, MySQL is it running on

Anyway... running out of time and I don't seem to be helping you much.... off to work I go.. hope to be back in 14-28 days...

Quote:

---

Originally Posted by Rizla

<Sigh> Please take the time to a least read through ALL the threads.... That asked BEFORE I contemplated installation!
Dave, I asked a simple question.... Can you make purchase through 'Returning Customer' ??

'IF' you CAN.... Then I have something 'a' miss... You have not given me an answer o that question.

All files that are 'template' related I have now 're-merged' Originally using winmerge but swapped for beyond compare. All template file are merged correctly. Hence my original problem went away. (log out) as stated!

All the other files are a simple over write of the COWOA files from the old version (or am I mistaken?)

COWOA was working fine, until the upgrade and now I have the one issue.... Somewhere it 'aint reading the DB although it does as far as entering an invalid P/W... That it will pick up on.

So..." password_needs_rehash()" is NOT an error through the new COWOA then? As NOTHING has changed BUT the installation of the new COWOA.... Curious to say the least

"I can not recreate the problem so guessing you did something else from your comments that's not an COWOA issue. are you doing this on a test site or live"

LIVE

"I would re-install ZC and start over... " There is a thing called BACK-UP reinstall... lol forget it!

Now Dave... Can you use the 'returning customer' ?? ALL I ASKED

---

---