Existing user - if they do not click the login button in the pane form, nothing happens - ie no authentication check of the password, no login, and order is not converted to an authenticated user order

Proposed changes:

Existing users

Require login of existing users - If enabled, the password field is required to proceed to the next checkout page. The customer will be logged in and the order converted to an authenticated user order

New users

Automatically create a user account for new customers - If enabled, a new user will be created based on the order's email address. The user is created on submit of the checkout page. This is similar to Commerce's default rule "on checkout complete" to create the user.

Automatically login the new user - If enabled, the new user will be logged in and the order converted to an authenticated user order.

With these changes, the order is associated with a user account on the initial checkout page. This solves many issues where the user account is created after payment processing has taken place.

Line 181 of this patch:$username = $order_wrapper->mail_username->value();
Is returning bool(false) for the $username

Seems the call to the entity_wrapper on line 178 is not having the desired results:$order_wrapper = entity_metadata_wrapper('commerce_order', $order);

Perhaps I'm missing some other required piece?

---
Upon further review the real issue is when I'm dealing with a non-shippable product in the shopping cart -- essentially Drupal validation is looking for shipping details and is throwing an error which is why the order entity_metadata_wrapper is coming up short. I'm brand new to Drupal so I'm trying to figure out how to turn off the shipping validation even when I'm disabling the shipping pane (e.g. $checkout_panes['customer_profile_shipping']['enabled'] = FALSE;). Something else is triggering the validation -- any ideas?

Looking at that section of the patch I saw some room for improvement. I re-ran the patch with loading the order object fresh and ensure that $order->mail is set. Please re-test and report back.

The shipping validation error - not sure on that one. The customer_profile_shipping pane and order field just capture the address. The shipping module has the shipping services that might be complaining about it.

Hide confirmation e-mail field when a user with the given mail address already exists

Added a new setting "Allow new customers to create a new account" to panes setting form

Bevhavior of that new option:

Wins the race condition against "Automatically create a user account for new customers" when both options are selected. That prevents the checkout process to create multiple accounts and doing weird stuff

Shows a username field with respect to USERNAME_MAX_LENGTH

Username gets validated by user_validate_name()

Shows two password fields if "E-Mail verification" is turned off in either core user module or Logintoboggan

If Logintoboggan is enabled, the password is validated with its rules (min-length, allowed characters)

Todo:

Send e-mail with activation link if user is not allowed to set its own password

Think about how to process when autologin after registration is disabled.Since the anonymous user was able to reach the checkout form, he also can proceed the checkout process without clicking the activation link in the activation e-mail. Then the order is still associated with an anonymous user instead the new one. That could lead to bad UX when this customer activates its account later and can't find his first order in his order history.However, if you assign the order to the not yet activated user, this could make trouble if the customer never activates his account and the account may be deleted due his inactivity by any "clean up" process.

Fixing a bug introduced by unsetting the mail confirmation field. Now, in the case of required login of a known mail address, it gets prepopulated with the address and hidden by a wrapper with display: none;

I don't have time to do it myself tonight but may tomorrow. With that said, a few minor issues:

1) We refocus on the mail_confirm input after an ajax call but do not do so when loading the register new user form (if enabled). The focus should be restored on account[login][register][name] once the register form is loaded.

2) If a new account is registered in this manner, emails normally sent to the new user by the system are skipped. At a minimum the user welcome email or commerce account created email (if enabled) should be forced programmatically.

Included your 2nd suggestion with a configuration to enable/disable the welcome e-mail.

However, since the creation of a new account is optional and since the registration form is not visible until you leave focus of the mail confirmation field, I think it would be bad practice to hijack the users focus and set it to an optional field.

Yeah Because of the way the registration form will render on the page after the ajax call (generally under the previous), the users screen will be staring the registration form in the face. The natural inclination is to tab through this, at least that's what a customer we walked through your patch felt.

"Although not a deal breaker, when I pushed tab after entering my email for a second time, a new box appeared but above the box my cursor tabbed to. I was annoyed that I had to scroll back up to fill out my information and create a new account. It would have been quicker to tab through the section after reading what it was than to stop and scroll up to see it was optional then scroll back down."

Not a big deal to me, but figured I would pass it along. That was quite fast by the way haggins

However, our site doesn't use user names but only email addresses. In such a case, when creating a new user account and letting the user set his password, the user name field isn't needed (shouldn't be mandatory).

@papalapapp
How do you disable usernames for the default registration process? Is there any configuration option I didn't see so far?
In the meantime you should be able to modify the form with hook_form_alter() to change its behavior.

with the latest patch (#16) i think we can move this issue to "reviewed & tested by the community" as it does what it says.

- imho opinion this should definitely be commited
- maybe a good helper (description) text it's needed for the Account information E-mail address form element.
So the anonymous user will know what to expect there - but this is another (general) issue.

@haggins
I mixed it up a little. The user name is indeed mandatory in my installation. But users get their account created during their first order via the Immediate Login module which doesn't ask for a user name, it sets the email address in for that.

Since this shop doesn't have any functions like komments, messages, personal ratings etc, there is no usecase for separate user names and therefor left out. Just wanted to throw that in. Making it optional would be basically to fill it with the email address if it is left blank.

I had some issues with Safari trying to autocomplete the email and password fields and causing errors. I added the following to resolve it at the end of function commerce_checkout_login_form_commerce_checkout_form_alter:

The following form_set_error code should be moved from "commerce_checkout_form_alter" to "commerce_checkout_login_checkout_form_refresh" cos if there is another ajax callback for the form like a postal code check in address field then i will be getting form error continuously cos email field is empty. This is why form set error is used in form alter that is called in every ajax request.

My fix actually didn't work, and the issue is a result of using LoginToboggan to allow logging in with your user name or password. With that in place, Safari (and possibly others) stores your login info and tries to populate the email address field with your username (if you've logged in with your username in the past) after the ajax call, which then causes the form to fail because your email is gone and replaced by your username.

Haggins np Dude! instead we have to say big thank you for making this great patch!!!

One thing we should change is that a registration form can be very complex(with lots of fields, like user profile) too so instead of showing username and password for registration on checkout page we should show a link to the registration page and after user submits the form he/she will be redirected back to the checkout page, or we should show the full registration form on checkout page.

Seems to me there's no reason to disable commerce_checkout_login_new_user_create when commerce_checkout_login_allow_registration is enabled. They can work together, if user use ajax form to register that's fine, if they don't then this module should automatically create new user.

The implementation in the current patch does not degrade gracefully. When javascript is disabled you are able to continue checkout using any existing e-mail address without logging in. Only when you go back to the checkout pane will you be asked for the password. I will work on a fix somewhere in the coming days.

Reworked the patch quite a bit, but it now gracefully degrades and makes use of the actual validation and submission callback options provided by commerce in stead of attaching validation handlers to the submit buttons.

I've also removed the now redundant and possibly confusing login button. The customer can now just enter his/her details and continue checkout. The account pane will be validated along with the other panes on form submission using the continue button.

These changes should probably also be made to the the user register functionality. But I think it's best to leave that refactoring for a follow up issue.

Thanks legolasbo. The downside of removing the additional login button is, that already saved addresses from commerce_addressbook cannot be used as the user object won't be available at the first checkout page.

[x] Require login of existing users.
[ ] Automatically create a user account for new customers
[x] Allow new customers to create a new account
[x] Automatically login the new user.
[x] Send welcome e-mail after creating a new user.

no, only the commerce one which comes with commerce checkout - "Create a new account for an anonymous order"

Could this be causing an issue?

I do have a VERY complex setup with commerce licence/licence billing, i will have to bench this and try it with the next commerce shop i set up to see if it might have been the way my current site was set up, it is too far past standard to be disabling modules and such now.

I appreciate the troubleshooting help though and hopefully I can test it soon.

nyleve101CreditAttribution: nyleve101 as a volunteer commented 13 July 2015 at 16:51

Hi @legolasbo,

I also experienced this problem on a vanilla drupal installation with Commerce Recurring 2.x. I entered a previously unregistered email address on Checkout and then clicked 'back' on the Review order page. When I returned to the checkout page I also experienced the issue @capfive mentioned of seeing " xxx is already a registered user, please put in the password to continue" despite there being no password field. This issue didn't occur with patch 27.

@legolasbo: can you automatically login the user after entering the valid password ? since there is no login button now. if you can, then the saved address can be shown to logged in user (saved address from commerce_single_address or commerce_addressbook)

btw, the rule "Create a new account for an anonymous order" should be disabled or not with this patch?

legolasboCreditAttribution: legolasbo as a volunteer commented 10 September 2015 at 07:18

@rei,

With the patch, the module now does the following (default settings, no special actions needed):

Automatically Verify e-mail address after it has been entered using AJAX (if javascript is disabled, this verification will happen on form submit). If the address exists, add a password field to the form.

On form submit it will then do the following:
If a new address is entered,

However, rather than allowing them to set a password, maybe set them up with something that needs to be changed and set a message AFTER the order complete with a link to /user/%uid/edit to set their password.

However, rather than allowing them to set a password, maybe set them up with something that needs to be changed and set a message AFTER the order complete with a link to /user/%uid/edit to set their password.

Allowing them to choose a password is a feature. By default the user will have an automatically generated password. Setting a link to /user/%uid/edit to set the password will not work however, since they need to know their original password. The only way they can change the password is by clicking the link in the confirmation mail.

For security, the flood control should be implemented.

Great idea, thanks.

@rei,

I have had time to think about this and I think I've thought of a way to prevent the infinite loop. So I will work on automatically logging in the user.

I would vote to not log in a new user in until they successfully complete the order. Your existing password code for a new user could also be put in a custom pane after the payment pane, so they can set their password and get logged in before the 'order complete' pane. However that might require a module like commerce_rules_extra to make a conditional rule to only show the pane for anonymous users.

legolasboCreditAttribution: legolasbo as a volunteer commented 15 September 2015 at 11:09

@Blasthaus,

Thanks for pointing out how to allow a password change. I'll also work on changing that. I agree that not logging in the user until the order is completed successfully is a good idea. In fact, the user probably shouldn't be created until then.

cameronbprinceCreditAttribution: cameronbprince as a volunteer commented 16 September 2015 at 06:27

I'm also glad to see some progress with this module. I use it on nearly all the e-commerce sites I set up, warts and all.

I tested the #60 patch and it works well and does seem to resolve the loop Safari was getting into. Unfortunately, I had to roll it back due to new accounts being created prior to checkout completion. This is a confusion point for users as they see the site magically change from not logged in to logged in between checkout steps. It would also equate to additional required maintenance to clean up accounts created and not used when carts are abandoned. Finally, the normal welcome email is never sent, so the user has no way of knowing how to set their password.

Attached patch addresses the issues raised in #63. The option to choose a password has been removed again, but the link to /user/%/edit is still absent. I will work on that and the other comments when I have more time on my hands.

I have become the maintainer of the module and have started work on a new branch where I've rewritten the basic functionality of the module and added tests. Most of what my previous patches have been doing is way out of scope for this issue. I am therefor not going to continue along that path and will refocus future effort on the initial feature request, which is to require a logged in user before being able to checkout. Any other features added in the previous patches are still on the table for 2.x but will each be in issues of their own.

legolasboCreditAttribution: legolasbo as a volunteer commented 5 October 2015 at 14:08

Status:

Needs work

» Fixed

I've taken a look at the original issue.

Current module:

Existing user - if they do not click the login button in the pane form, nothing happens - ie no authentication check of the password, no login, and order is not converted to an authenticated user order

This is correct for 7.x-1.x-dev, but in 7.x-2.x-dev the password field is always required to place an order using an existing e-mail address. Also the login button has been removed and account verification now occurs upon continuation of the checkout process. This also ensures graceful degradation when javascript is disabled.

Proposed changes:

Existing users
Require login of existing users - If enabled, the password field is required to proceed to the next checkout page. The customer will be logged in and the order converted to an authenticated user order

As stated above, the password field is now always required.

New users
Automatically create a user account for new customers - If enabled, a new user will be created based on the order's email address. The user is created on submit of the checkout page. This is similar to Commerce's default rule "on checkout complete" to create the user.
Automatically login the new user - If enabled, the new user will be logged in and the order converted to an authenticated user order.
With these changes, the order is associated with a user account on the initial checkout page. This solves many issues where the user account is created after payment processing has taken place.

As stated in this quote, Commerce's default rule allows for user creation on order completion. Creating accounts before order completion will result in many new accounts being created without checkout being completed. That in turn will result in a lot of unused accounts and customer confusion as stated in #66 and #68. Besides that it would also block anonymous checkouts completely. Any changes to user creation are therefor out of scope and should in my opinion take place on a separate issue.

For the reasons mentioned above I believe that the original issue is fixed appropriately in 7.x-2.x-dev and this issue can be considered fixed.

As stated in this quote, Commerce's default rule allows for user creation on order completion.

But it doesn't allow the user to choose their password and won't log them in after the transaction.

I am looking for a way to allow user creation while going trough the checkout, instead of the checkout redirect option that add a step to the checkout. Having a panel that takes care of either making the user log in or creating their account would be a perfect match.