Simple and Easy 2 Question Create Account Page

[pricediscrimination]

Depends on how you "removed" the other stuff... My guess is that you did so by specifically deleting code, rather than turning off switches in the admin.

Yes, it was a stock file and first, all of the items described as being "too much" were disabled through the admin panel, and then the remaining (with exception of some of the text that I missed) were bounded by a single admin controlling switch for "ease" and expediency. As said was a rush job mostly to prove the possibility. More thought/action would be necessary to do it right... That would include one or more additional admin switches to encompass either the individual or a group of options to be disabled and to further remove the "checks" on the absent data, etc... At the level and time of writing, the "concern" was the ability to accommodate the request... The base action was provided with "caution" provided in the implementation.

Sorry I misunderstood and thought the code you put here was all set for only having email and password as Create Account questions. The admin>customer details area does not give options to shut off all the questions that are on the Create Account page.

It's too bad this thread was rudely interrupted by someone who doesn't see how this is an issue for a site in 2015. It's too bad that it's so difficult to make the create account page not ask for the customer's entire life story.

It should be up to the store owner to decide whether or not to require those questions for account creation. For an ecommerce platform that was packaged with the ability to purchase digital goods, and even free digital goods, it only makes sense that an address etc should be able to be shut off.

Thank you mc12345678, but I do not think it's possible to hack ZC to be up with the times.

[mc12345678]

Sorry I misunderstood and thought the code you put here was all set for only having email and password as Create Account questions. The admin>customer details area does not give options to shut off all the questions that are on the Create Account page.

It's too bad this thread was rudely interrupted by someone who doesn't see how this is an issue for a site in 2015. It's too bad that it's so difficult to make the create account page not ask for the customer's entire life story.

It should be up to the store owner to decide whether or not to require those questions for account creation. For an ecommerce platform that was packaged with the ability to purchase digital goods, and even free digital goods, it only makes sense that an address etc should be able to be shut off.

Thank you mc12345678, but I do not think it's possible to hack ZC to be up with the times.

Exactly... And that is what was presented... The same code that offers the opportunity to disable existing sections already programmed, plus the ability to "turn it all off" ***WITHOUT*** touching the code from that point forward...

It is perfectly "ready" for use, though in my testing I saw that I had left one language define outside of an exclusion group...

The result(s) of the above code, with turning off the built-in available features and modifying the minimums to 0, resulted in a login screen that asked for the email address and password I think was all that I left there... Whatever "minimum" was described as desired...

Having done it, having what looks like others repeating it and apologies, but if others are able to accomplish the task with the provided code/direction, then there is a reason for those that can not... Need to investigate *that* reason...

Further is it that *think* can not? Or can it not be done? It's been done and sorry, but creating some sort of a *challenge* to get further free assistance, doesn't do it for me...

[pricediscrimination]

Exactly... And that is what was presented... The same code that offers the opportunity to disable existing sections already programmed, plus the ability to "turn it all off" ***WITHOUT*** touching the code from that point forward...

It is perfectly "ready" for use, though in my testing I saw that I had left one language define outside of an exclusion group...

The result(s) of the above code, with turning off the built-in available features and modifying the minimums to 0, resulted in a login screen that asked for the email address and password I think was all that I left there... Whatever "minimum" was described as desired...

Having done it, having what looks like others repeating it and apologies, but if others are able to accomplish the task with the provided code/direction, then there is a reason for those that can not... Need to investigate *that* reason...

Further is it that *think* can not? Or can it not be done? It's been done and sorry, but creating some sort of a *challenge* to get further free assistance, doesn't do it for me...

The strange thing was that all the settings in admin were set to false.

Thank you for the free assistance. I was not creating any *challenge* for further free assistance. Just feeling discouraged.

[pricediscrimination]

In Admin > Customer Details there are only options for:
Email Salutation, Date of Birth, Company, Address Line 2, State, State - Always display as pulldown?, Create Account Default Country ID, Fax Number, Show Newsletter Checkbox.

Questions still being asked are name, city, state, zip, phone.

EDIT: these are controlled by Email Salutation. As you already said. Apologies.

[pricediscrimination]

mc12345678: you worked the code to do exactly what was asked in this thread. Thank you for your hard work and support. The code you presented works. You never questioned or dismissed what was trying to be achieved here, only set out to solve the problem. Thank you for that.

[mc12345678]

In Admin > Customer Details there are only options for:
Email Salutation, Date of Birth, Company, Address Line 2, State, State - Always display as pulldown?, Create Account Default Country ID, Fax Number, Show Newsletter Checkbox.

Questions still being asked are name, city, state, zip, phone.

With email salutation (ACCOUNT_GENDER) turned off(false), the "other" fields get disabled... (as you found out).

mc12345678: you worked the code to do exactly what was asked in this thread. Thank you for your hard work and support. The code you presented works. You never questioned or dismissed what was trying to be achieved here, only set out to solve the problem. Thank you for that.

Welcome (and hopefully this accomplishes/completes response to both things :) )

And again, for those that come across this thread/plan, the choice at the time was to simply repeat using

if (ACCOUNT_GENDER == 'true') {

to encompass the content to be removed... To provide finer control, a separate constant would need to be created in the admin configuration options to refine that and replace the ACCOUNT_GENDER part... Further, groups/combinations of settings could be controlled like an ACCOUNT_ADDRESS option to address all of the addresses, or maybe an option like, ACCOUNT_EMAIL_ONLY which when set to false would disable all fields except the desired Email and password option(s)... Options are at that point totally up to the individual implementing the above code, which is further why I didn't try to do a complete design analysis for implementation. Just get 'er done. :)

I also did not mean to be, well mean... As said before, these things can be done, and one should not just give up... At one point I think I did mentally work through the whole backlink part, but hadn't implemented it to provide that part (again left it for the next venturous individual. :) ) Also I didn't want to delve too far into this 1) if it didn't provide the desired affect 2) if it affected other items on which I'm working, and 3) if it was gonna' cause heartache to the "community" by getting shot down from the get go. :)

I still warn... There are aspects about the modifications that have not been evaluated for program flow in an "indirect" operation... Was able to step through a "normal" checkout process and site visit, but didn't investigate things like product that do not require an address for shipping, stepping backwards through the checkout process, failed payments, sideboxes, ez-pages, other plugins, etc...

Long and short, glad you were able to get it to work... :) Welcome to the 2015s.

[pricediscrimination]

to encompass the content to be removed... To provide finer control, a separate constant would need to be created in the admin configuration options to refine that and replace the ACCOUNT_GENDER part... Further, groups/combinations of settings could be controlled like an ACCOUNT_ADDRESS option to address all of the addresses, or maybe an option like, ACCOUNT_EMAIL_ONLY which when set to false would disable all fields except the desired Email and password option(s)... Options are at that point totally up to the individual implementing the above code, which is further why I didn't try to do a complete design analysis for implementation. Just get 'er done. :)

I also did not mean to be, well mean... As said before, these things can be done, and one should not just give up... At one point I think I did mentally work through the whole backlink part, but hadn't implemented it to provide that part (again left it for the next venturous individual. :) ) Also I didn't want to delve too far into this 1) if it didn't provide the desired affect 2) if it affected other items on which I'm working, and 3) if it was gonna' cause heartache to the "community" by getting shot down from the get go. :)

I still warn... There are aspects about the modifications that have not been evaluated for program flow in an "indirect" operation... Was able to step through a "normal" checkout process and site visit, but didn't investigate things like product that do not require an address for shipping, stepping backwards through the checkout process, failed payments, sideboxes, ez-pages, other plugins, etc...

Long and short, glad you were able to get it to work... :) Welcome to the 2015s.

Your kindness, patience, understanding, and ability to teach are to be admired. Thanks to you and others like you on this forum for taking the time to help others.

Excited to be in the 2015s, we'll see where it goes from here

[DivaVocals]

It's too bad this thread was rudely interrupted by someone who doesn't see how this is an issue for a site in 2015. It's too bad that it's so difficult to make the create account page not ask for the customer's entire life story.

yep that's me.. "rudely" interrupting.. this is cute..

[davewest]

includes/init_includes/overrides/init_header.php:

/* Check for invalid countries in customer's address book.
 * If a customer is logged in, check to see that the customers' address(es) still contain valid countries.
* If not, redirect to the address-book page for changes.
*/
if  ($_SESSION['customer_id'] && $_GET['main_page'] !=  FILENAME_ADDRESS_BOOK_PROCESS && $_GET['main_page'] !=  FILENAME_LOGOFF && ($_GET['main_page'] ==  FILENAME_CHECKOUT_SHIPPING || $_GET['main_page'] ==  FILENAME_CHECKOUT_PROCESS || $_GET['main_page'] ==  FILENAME_CHECKOUT_CONFIRMATION)) {
  $addresses_query = "SELECT  address_book_id, entry_country_id as country_id, entry_firstname as  firstname, entry_lastname as lastname
                      FROM   " . TABLE_ADDRESS_BOOK . "
                      WHERE  customers_id = :customersID
                      ORDER BY firstname, lastname";

  $addresses_query = $db->bindVars($addresses_query, ':customersID', $_SESSION['customer_id'], 'integer');
  $addresses = $db->Execute($addresses_query);

  while (!$addresses->EOF) {
    if (zen_get_country_name($addresses->fields['country_id'], TRUE) == '') {
       $messageStack->add_session('addressbook',  sprintf(ERROR_TEXT_COUNTRY_DISABLED_PLEASE_CHANGE,  zen_get_country_name($addresses->fields['country_id'], FALSE)),  'error');
      $_SESSION['navigation']->set_snapshot (array('mode' => 'SSL', 'page' => FILENAME_CHECKOUT_SHIPPING));
      zen_redirect (zen_href_link(FILENAME_ADDRESS_BOOK_PROCESS, 'edit=' . $addresses->fields['address_book_id'], 'SSL'));
    }
    $addresses->MoveNext();
  }
}

Thanks... didn't think to look there for catching it.

For me I wanted COWOA and standard account to work as normal, adding a catch so checkout would require a billing/shipping address... I added two new pages, one for registering, one for catching the address and what not during checkout. I also had to create a false inactive Country/State so admin wouldn't freak out.

My Catch..

/* Check for invalid countries in customer's address book.
 * If a customer is logged in, check to see that the customers' address(es) still contain valid countries.
* If not, redirect to the address-book page for changes.
*/
if  ($_SESSION['customer_id'] && $_GET['main_page'] !=  FILENAME_ADDRESS_BOOK_PROCESS && $_GET['main_page'] !=  FILENAME_LOGOFF && ($_GET['main_page'] ==  FILENAME_CHECKOUT_SHIPPING || $_GET['main_page'] ==  FILENAME_CHECKOUT_PROCESS || $_GET['main_page'] ==  FILENAME_CHECKOUT_CONFIRMATION || $_GET['main_page'] ==  FILENAME_CHECKOUT)) {
  
  $addresses_query = "SELECT  address_book_id, entry_country_id as country_id, entry_firstname as  firstname, entry_lastname as lastname
                      FROM   " . TABLE_ADDRESS_BOOK . "
                      WHERE  customers_id = :customersID
                      ORDER BY firstname, lastname";

  $addresses_query = $db->bindVars($addresses_query, ':customersID', $_SESSION['customer_id'], 'integer');
  $addresses = $db->Execute($addresses_query);

  while (!$addresses->EOF) {
    if ((zen_get_country_name($addresses->fields['country_id'], TRUE) == '') || (zen_get_country_name($addresses->fields['country_id'], TRUE) == 'GAccount')) {
       $messageStack->add_session('addressbook',  sprintf(ERROR_TEXT_COUNTRY_DISABLED_PLEASE_CHANGE,  zen_get_country_name($addresses->fields['country_id'], FALSE)),  'error');
      $_SESSION['navigation']->set_snapshot (array('mode' => 'SSL', 'page' => FILENAME_CHECKOUT_SHIPPING));
       if ($_SESSION['cart']->count_contents() > 0) {
      zen_redirect (zen_href_link(FILENAME_GUEST_ACCOUNT, 'action=doprocess', 'SSL'));
      }else{
      zen_redirect (zen_href_link(FILENAME_DEFAULT));
      }
    }
    $addresses->MoveNext();
  }
}

[pricediscrimination]

This hack works very well, infinite thanks to mc12345678.

Strangely, when the new account is created, nothing related to the account is recorded in Admin > Customers. It makes sense that until the customer adds their address to the address book there won't be any data in the address fields, but the customer's email address isn't there either. Neither is any info in the ID# box.

This info is also not added to the Admin area even when data is input on the Edit Account Info page.

Only when an address book entry is made, then the data is viewable in the Admin.