Users should (optionally) be presented with the option to register an account during checkout. The account should then be created and the order assigned to it, when the order is completed.

Current to do list:

  1. Fix broken tests
  2. Extend test coverage
  3. Remove $order->data['commerce_checkout_login_register'] if a user has logged in in the mean time.
  4. Add a "Immediately create and login user upon registration" checkbox
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

rszrama’s picture

I wonder if this wouldn't better be included as an option in the Commerce Checkout Login module...

pcambra’s picture

I agree with moving this to commerce checkout login

rszrama’s picture

Project: Commerce Core » Commerce Checkout Login
Component: Checkout » User interface

Movin' it then. : )

burgs’s picture

What would be great is if we could have an option to integrate the register form into the checkout form, so that new users could fill in all the user register fields inline with their credit card and delivery info. On submit, the user gets created, the order gets associated with this new user, and then the order gets processed. If for some reason they register, but the payment doesn't go through, it would redirect to the checkout form, but as the newly logged in user.
I hope this fits inside the scope of this module, and if there's some help I can give, let me know.

jyee’s picture

subscribing

rcross’s picture

+1 - I'm surprised there is not a way to register users as part of the checkout process in the core commerce package. We're fighting this now and trying to figure out a work around.

rszrama’s picture

It happens normally during checkout completion (see the checkout completion rules). This issue is specifically for requiring registration prior to checkout - is that what you're looking for?

pcambra’s picture

#6 you can actually register users in checkout process, if anonymous users have the permission "access checkout" their account is going to be created. If you want additional fields there, you can use commerce fieldgroup panes module, create the same fields in the user account and in the order entity type and assign them using rules.

rcross’s picture

What i find odd is that it doesn't offer the registration step - it just creates the user. So any custom user/profile fields can't be automatically pulled in to be filled out. There is also no way to have someone specify their password when it is created.

@pcambra - i'll see if what you've said will work, though we're going down a different path at this point. It seems wrong though that someone would have to define these registration fields a second time and then map them to the profile in the rules definition when it would seem intuitive to have a "registration" pane that could just be put whereever it should be in the checkout process.

labman’s picture

Issue summary: View changes

I have the Commerce Extra Module which directs to a login, or registration link if the user is anonymous. The problem I have is that I cannot force the user to login or register as they can click on continue without doing either. This could be easily resolved by not allowing anonymous users to access the checkout, but, the problem there is that the cart link does not show to anonymous users so the user is left not knowing what to do next once they've added a product to the cart.

labman’s picture

#10 my problem is now sorted by using Commerce Checkout Redirect

suraj_vantagode’s picture

hi all, check self role in permission..to get register link for anonymous user

legolasbo’s picture

Title: please register link for anonymous users » Allow users to register during checkout
Version: 7.x-1.x-dev » 7.x-2.x-dev
Issue summary: View changes
Parent issue: » #2580227: [META] 2.0 release
RAWDESK’s picture

FileSize
63.77 KB

@labman,
I've been experimenting today with both #10 and #11 mentioned alternatives but neither one of them satisfy me in UX...
#10: more or less the same concerns as you mentioned
#11: if you don't set out a custom path, the enriched /user/ page is IMHO a UX monster.. especially with the question 'do you know your password ?" and the option to skip login and still continue anonymous! (sorry for the words towards the module's author)

I found my last resort while experimenting with Simple FB connect module which allows a ?destination= parameter set in its FB connect URL.
Here's what i came up with after writing some extensions to commerce_order.checkout_pane.inc form API hooks in a custom module, in order to attach more option in the account information pane :

function custom_couture_checkout_form_alter(&$form, &$form_state, $form_id) {
	if ($form['#form_id']=='commerce_checkout_form_checkout') {
  		global $user;
		dpm($form, 'custom_couture checkout_form_alter');
  		// If the Account Information pane is on the current checkout page and the
  		// user is not logged in...
  		if (!$user->uid && !empty($form['account'])) { 		
			$form['account']['login']['fb_login'] = array(
        		'#type' => 'item',

      		'#title' => t('Or quickly connect with facebook to create your account or login'),

        		'#markup' => '<a href="/user/simple-fb-connect?destination=' . current_path() . '"><img src="/sites/default/files/Facebook-login.png"></a>',

      	);
			$form['account']['login']['mail_confirm']['#description'] = t('Provide your e-mail address in the above fields to activate your account during this checkout.');      	
  		}
	} 
}

You can witness the result in attached screenshot.

Note: this is just a preliminary effort to have more login/register buttons enabled that are preferably simulated in modal mode, so the user still experiences he's in checkout mode !

Stay tuned ! :)

legolasbo’s picture

Assigned: Unassigned » legolasbo
FileSize
24.19 KB

@RAWDESK I forgot to assign this to myself but have been working on this all day yesterday. I've taken a whole new approach which also removes the UX monster. (No more AJAX!).

This is done by no longer enriching the checkout page but providing a new 'account' page where users can select if they either want to login, register or checkout anonymously.

Attached patch is a first working version of the new approach, still has several todo's that need fixing, but the basic checkout flow is in place.

RAWDESK’s picture

@legolasbo,
This approach looks promising.
Do you mean by new 'account' page an additional checkout page in front of the checkout ?
Maybe you also have to take a look at this similar module providing an additional page, providing 2 options:
drupal.org/project/commerce_extra_login_page

1- I am a registered user
2- I am not a registered user

Option 1 allows to login, but also here appearing UX monsters: there is no actually submit button to login! (you have to continue with next step, after which no confirmation is given you are actually logged in successfully.. something like "Welcome back John Doe, we have prepared some nice coupons for you which you can apply in your purchase")
Option 2 is just an informal by UI manageable description allowing continuation without login... but where can i provide my email address which is essential to create an account ??

So beware of these awful pitfalls whilst working on a better version of the lookalike :)

PS. If i find some time in the upcoming days, i'll test your latest patch.

legolasbo’s picture

Do you mean by new 'account' page an additional checkout page in front of the checkout ?

Correct

So beware of these awful pitfalls whilst working on a better version of the lookalike :)

How do you like the following screenshots (taken from last submitted patch)

User is already logged in:
authenticated user

User is anonymous:
anonymous user

RAWDESK’s picture

Hi legolaslo,
This looks a lot better then what i've already seen before in other alternative modules !

If possible i would offer the 'checkout as guest' as an UI configurable option, since i and probably many other won't be needing it. Checkout without an account (and necessary contact information) is rather the exception then the rule in e-commerce.

It would be awesome if you could also add a third option block "Social connect", where buttons like facebook, twitter and Google+ can be placed. Positioning could be done right beneath the other 2 blocks in a horizontal orientation.

Why i would put it as a seperate block ?
Because they'd either login (if already linked to an account) or register and login (if not already linked to an account).
So a module dependency with my recently integrated 'Simple FB connect' is feasible and I'd be glad to help you out plugging this one in to have a testcase..

Just let me know what you think of it...

Keep up the good work bro ! ;)

legolasbo’s picture

If possible i would offer the 'checkout as guest' as an UI configurable option, since i and probably many other won't be needing it.

That's the plan.

It would be awesome if you could also add a third option block "Social connect", where buttons like facebook, twitter and Google+ can be placed. Positioning could be done right beneath the other 2 blocks in a horizontal orientation.

I don't see that going in as a part of this issue, but could very well be done in a follow up.

Why i would put it as a seperate block ?
Because they'd either login (if already linked to an account) or register and login (if not already linked to an account).
So a module dependency with my recently integrated 'Simple FB connect' is feasible and I'd be glad to help you out plugging this one in to have a testcase..

As I said, let's work on this in a follow up. I'm thinking we could implement an API which your 'Simple FB connect' module can then implement to appear on the form.

legolasbo’s picture

Status: Active » Needs review
FileSize
27.54 KB
8.2 KB

Updated patch to now show correct account information on steps following the account register form submit. Also, the user now no longer loses his entered registration info upon using the back button, which is nice ;)

I expect this patch to fail testing, since basically everything has changed.

Status: Needs review » Needs work

The last submitted patch, 20: allow_users_to_register-1104226-20.patch, failed testing.

RAWDESK’s picture

Sorry for the late answer. Had a busy day today.
But if i understand correctly, it's too soon yet to assist in testing ?

legolasbo’s picture

Actually you can start testing. Most of the functionality is there. The following tasks are still outstanding.

  1. Make the ability to register follow core's settings. (if a user is allowed to create an account, show the registration form, hide it otherwise) - Currently working on this
  2. Make the checkout as guest button optional.
  3. Make the help text configurable
  4. Fix the broken tests - You can actually provide help in the form of a patch here
  5. Add new tests - You can actually provide help in the form of a patch here

After commit, follow up with:

  • Optional e-mail confirm field in the user register form.
  • Optionally add fields configured to show on core's registration form.
  • Create an API (or

something) for additional login methods/integrations.

RAWDESK’s picture

I'll take some time tomorrow to test it.

legolasbo’s picture

Issue tags: +Needs manual testing

The following tasks are still outstanding.

  1. Make the ability to register follow core's settings. (if a user is allowed to create an account, show the registration form, hide it otherwise)
  2. Make the checkout as guest button optional.
  3. Make the help text configurable - I've skipped the configurable part, but made it settings dependant. The text can easily be overridden in a form_alter
  4. Fix the broken tests
  5. Add new tests

After commit, follow up with:

  • Optional e-mail confirm field in the user register form.
  • Optionally add fields configured to show on core's registration form.
  • Create an API (or something) for additional login methods/integrations.

Please thoroughly test this patch manually. Anything you find now prevents an issue after commit. Especially play close attention to the security aspects like input escaping etc. I've paid great attention to the security, but it is always possible I missed things. I will start work on fixing/replacing the automated tests.

RAWDESK’s picture

Hi,
First important malfunction i've noticed is this:
After the anonymous user selected 'register and checkout', the next checkout page shows me indeed the registered user name and email address, but user's state remains anonymous apparently (global $user->uid not set).
See in my attached screenshot the result of that :
- Log in option still appears in my user menu
- Log in with facebook is still enabled (should be hidden with logged in user), but this symptom will disappear once your social plugin API is ready..
- In the occurrence the user logs in (with another account) after requesting registration, the subsequent checkout steps still shows the newly registered user.
- At the end the email notification of the new account registration is also sent, which is no longer necessary since logged in with another account.
- The order is assigned to the other (logged in) user.
- Also stepping back to this new account checkout page during checkout, it shows the other logged in user.

So where it technically comes to is you'll have to set the freshly registered user as logged in user (global $user) as soon as possible after your new account step. As such all confusion in other site widgets will disappear.
Note: my subsequent checkout page is showing a discount coupon entry form, where coupons will be set available for freshly registered customers. So i have to be aware of that fact... (global $user has no orders yet).

legolasbo’s picture

Thanks for your testing, your findings are really valuable.

Hi,
First important malfunction i've noticed is this:
After the anonymous user selected 'register and checkout', the next checkout page shows me indeed the registered user name and email address, but user's state remains anonymous apparently (global $user->uid not set).

This is by design to prevent people from creating bogus accounts in checkout processes which are never completed.

Incomplete information
The account information pane of the checkout step should display a disclaimer stating that the account will be created on checkout completion. (this disclaimer is already shown on the review pane). I will also add this disclaimer to the checkout pane's account information.

See in my attached screenshot the result of that :
- Log in option still appears in my user menu

The user is not logged in yet, so yes, login would still be shown. The disclaimer on the account information pane would explain that to the user.

- Log in with facebook is still enabled (should be hidden with logged in user), but this symptom will disappear once your social plugin API is ready..
/blockquote>
You are correct. this symptom will be resolved when the API is implemented. Until then, you could check if $order->data['commerce_checkout_login_register'] is set.

- In the occurrence the user logs in (with another account) after requesting registration, the subsequent checkout steps still shows the newly registered user.
- At the end the email notification of the new account registration is also sent, which is no longer necessary since logged in with another account.
- Also stepping back to this new account checkout page during checkout, it shows the other logged in user.

I will make sure these are prevented by ignoring and removing $order->data['commerce_checkout_login_register'] if a user has logged in in the mean time.

- The order is assigned to the other (logged in) user.

This is by design.

RAWDESK’s picture

You are actually sitting on drupal.org right ? :)
Thanks for the quick response!

Although i partially follow your "still to be created account" workflow, i do not fully agree with it from a user's perspective.
Okay.. you are putting a clear disclaimer on both account panes, but how many do you think are really going to read this ?
My guess, only a two out of a dozen.

Secondly, from a marketing pov it would be awesome to have all those accounts just in one list, nicely accompanied with their current order checkout status(es), for which i love Commerce far above Ubercart ! (a shopping cart is an order status).
Also plans with my client are setted out to push every new user account to Mailchimp and Mandrill for email marketing and more.
Without the account being created before order completion, this prospect means "ZIP" to my business client!

So, who really cares about the bogus accounts ? We certainly do!
Unless they are created by spam bots of course. But here we could hook into the Drupal captcha module as advised here

Summary: I'd appreciate if you left the option to postpone the account creation to checkout completion open in the config UI.
Means some additional work, but i am convinced you'll broaden your modules audience significantly.

legolasbo’s picture

I get e-mail notifications of issues I am subscribed to, and since I am actively working on this issue now, every update sparks my interest ;)

Your motivation is rock solid, and I was already considering a "Immediately create and login user upon registration" checkbox. You convinced me to implement it.

Current to do list:

  1. Fix broken tests
  2. Extend test coverage
  3. Remove $order->data['commerce_checkout_login_register'] if a user has logged in in the mean time.
  4. Add a "Immediately create and login user upon registration" checkbox
RAWDESK’s picture

Found some more time to work on the issue ? As i understood it, you were very close to finalizing it..

legolasbo’s picture

Assigned: legolasbo » Unassigned

I've been busy with some pressing client work. I'm hoping to be able to finish this work over the weekend if my family let's me ;)

Unassigning the issue for now. Feel free to help out by fixing some outstanding tasks from the to-do list.

RAWDESK’s picture

Have been busy too under client pressure, and bills keep coming in.. But! this issue is worth investing time in. It enhances the customer's shopping experience and as such leaves a good reference for future prospects.
I'll see what i can do in the upcoming week about todo 3 and maybe 4 too.

legolasbo’s picture

Extend test coverage

Still not 100% test coverage, but most paths are covered. Also found and fixed a few minor bugs while writing the tests.

Could still use some manual testing, especially testing of wrong input and other strange things users might do.

Status: Needs review » Needs work

The last submitted patch, 33: allow_users_to_register-1104226-33.patch, failed testing.

The last submitted patch, 33: allow_users_to_register-1104226-33.patch, failed testing.

The last submitted patch, 33: allow_users_to_register-1104226-33.patch, failed testing.

legolasbo’s picture

FileSize
466 bytes
45.58 KB
legolasbo’s picture

Status: Needs work » Needs review
RAWDESK’s picture

Hi Chris, i was just engaging back into your issue, just to inform you about another nice login/register alternative UI i saw on http://www.inspirepilots.com/login
They combined the login with a additional registration option. But just for your information...

Thanks for the update today. I'll do some manual testing and report back a.s.a.p. !

RAWDESK’s picture

Just tried to test your patch, but something went wrong with patch at #39.
I've applied it directly to the 7.x-2.x dev branch, but the expected changes did not occur during tests. Also admin UI is inaccessible (no config option on modules page).
I've tried to apply patch #39 on #20 patched version, but then Turtoise SVN patch application threw me an error.

legolasbo’s picture

Status: Needs review » Needs work

I guess something went wrong while formatting the patch, I will reroll it later this week.

legolasbo’s picture

@RAWDESK,

I had some time to take a look at the patch, but it applies without any problems to the latest 2.x-dev. I've tried git apply and patch -p1 and both worked flawlessly.

jimmynash’s picture

I had no problems applying the patch in #39 to the recent dev using -p1

Aside from that I am liking where this is going.

One question, I'm using the Email Registration module since I don't like users to have to create usernames.

Is there a reason why the Register half of the account pane is doing the registration through Form API rather than getting the normal user/register form?
Not saying this is wrong, but it doesn't get altered to just collect an email address like the normal one does with the Email Registration module.

legolasbo’s picture

@jimmynash,

It's just that form validation and user creation gets a lot more complicated when trying to re-use the user/register form. We could however add support for the Email registration module in a follow up issue.

jimmynash’s picture

@legolasbo

Understood. Looking through it that makes sense.

I don't want to derail this issue and from what I can tell it works fine from a simple registration test.
I like the idea here but need the simplified registration form for my workflows. I'll keep this one on my radar.

Nice work so far!

RAWDESK’s picture

@legolasbo,

Applying patch #39 on latest 2.x-dev also finished succesfully on my side using Turtoise SVN.
To be sure, applied the patch again using Git and SourceTree's Client, installed it but i have to throw the same conclusion as before :
The checkout account admin allows to uncheck anonymous checkout, but this only removes the "Checkout anonymous" button in the pane and not what i expected to be as a "user identified bogus customer"... Remember what i wrote about that earlier.

So i guess, these items on the todo list is still open ?
3. Remove $order->data['commerce_checkout_login_register'] if a user has logged in in the mean time.
4. Add a "Immediately create and login user upon registration" checkbox

See added manual test attachments showing more or less the same test results as before

legolasbo’s picture

@RAWDESK,

You are correct, unchecking "allow anonymous checkout" only prevents the user from checking out without registering or logging in.

So i guess, these items on the todo list is still open ?
3. Remove $order->data['commerce_checkout_login_register'] if a user has logged in in the mean time.
4. Add a "Immediately create and login user upon registration" checkbox

These issues are indeed still open, I still have to find time to work on those. My last patch was only updated with automated tests and small bugfixes to existing functionality. I will fix the last 2 points (with test coverage) when I have more time to do so.

legolasbo’s picture

Status: Needs work » Needs review
FileSize
60.07 KB
33.37 KB

Spent some time refactoring the tests in the patch today. They are a lot more clean and focussed now, which allows me to implement the outstanding tasks more easily. I will probably work on those in the coming days.

Status: Needs review » Needs work

The last submitted patch, 50: allow_users_to_register-1104226-50.patch, failed testing.

legolasbo’s picture

Status: Needs review » Needs work

The last submitted patch, 52: allow_users_to_register-1104226-52.patch, failed testing.

  • legolasbo committed 21642b4 on 7.x-2.x
    Issue #1104226 by legolasbo, RAWDESK: Allow users to register during...
legolasbo’s picture

Status: Needs work » Fixed

Fun fact, 82% of the module has been rewritten in this patch! A major clean up and new approach to the problem space.

9 files changed, 1142 insertions(+), 548 deletions(-)
rewrite commerce_checkout_login.module (82%)

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.