Since introducing the customer portal, we've had many requests to allow customers to register separately from the checkout. This makes sense, even if it's not something we've "traditionally" supported via common use cases. The portal really allows for a ton of extra functionality, however.
Broadly, a customer registration form should address at least the following use cases:
Within the Foxy customer portal. Customers can login, or customers can create a new account.
Standalone. This use case is more for specific order flows where a customer may need to register and be approved for a tax-exempt account (common) or other specific customer-registration order flow requirements.
Details
The Element Itself
Add hCaptcha by default. (We may add an email verification step in the future, but at this point, email verification in an ecommerce context is very rare (and could be handled via Foxy's existing SSO and order creation flows), so we can ignore this. Further, the customer webhook could be used to handle extra registration steps.)
Include email, first name, last name, and password inputs.
In the future we may want to add some ability for custom fields to be added at this point, which could be added as public attributes to the customer. But that gets into other topics we can ignore for now.
Ideally we allow some degree of flexibility on the password complexity requirements. TBD, but fine with something that can prevent unambiguously weak passwords.
Include a TOS checkbox. I'd say we should piggyback on the store's template configuration both for the display/requirement configuration as well as for the URL.
Within the Portal
The customer portal settings object should likely get a new bool setting, default false, the enable customer registration. This probably should be close to the SSO setting (perhaps grouped with it in a "Customer Sign Up and Sign In" or "Customer Authentication" or some other grouping).
On the customer portal, if enabled, add a "Sign up" section below the current "Sign in" section.
On successful creation, the customer should be logged into the portal.
Bonus points if we can make it easy to take specific action in this particular flow. ie. "After a customer registers, I want to display a 'next steps' div that I control, with links to upload their tax exemption certificate."
Standalone
Basically the same as the "within the portal" functionality, but on successful customer registration, we need to allow for the admin to do one of the following:
Be redirected to another URL. Ideally in a way that allows the email and name fields to be included in the querystring. (So perhaps allowing some sort of syntax or template language so a user could specify something like https://forms.example.com/abc123?email=${email}&name_first=${customer_first_name} as their redirect URL.)
Trigger other javascript to do whatever is desired on page. Hide the registration element, display a thank you block, etc.
Since introducing the customer portal, we've had many requests to allow customers to register separately from the checkout. This makes sense, even if it's not something we've "traditionally" supported via common use cases. The portal really allows for a ton of extra functionality, however.
Broadly, a customer registration form should address at least the following use cases:
Details
The Element Itself
Within the Portal
Standalone
Basically the same as the "within the portal" functionality, but on successful customer registration, we need to allow for the admin to do one of the following:
https://forms.example.com/abc123?email=${email}&name_first=${customer_first_name}
as their redirect URL.)