Ask most Drupal Commerce 2.x users what their #1 missing feature is, and they'll say it’s the ability to store and reuse customer information for future purchases, i.e. the “address book”. On Drupal 7, we provided this functionality through the Commerce Addressbook module. For Drupal 8 we felt this functionality was important enough to make it a core feature, and we started working on initial address book patches soon after releasing Commerce 2.0. We didn’t anticipate how wide-reaching implementing our ideal solution would be.

Early community feedback demonstrated the patches we were working on weren’t stable enough to be integrated into Commerce. We took a step back to rethink our data model, the way we use the Profile module, and the way we handle inline forms. In February, we released Commerce 2.12 with a brand new inline form API ready to be built upon. In March we made it possible to duplicate entity bundles, opening the door to using different profile types for billing and shipping information. In April we started the effort that culminated on August 29th in the 2.14 release.

Let’s see what we’ve accomplished!

Default Address Book UX

When returning customers reach the checkout form, the default address is pre-selected. They can choose a different saved address, edit the selected address, or enter a completely new address. When entering a new address, they can choose whether it should be added to the address book or used on the current order only. We’re using the “address” terminology here, but what’s being reused is an entire profile along with any additional fields (e.g. phone number).

This UX should look familiar if you’ve used Commerce Addressbook. The part that may surprise you is that the same functionality is now present in the admin UI:

We’ve never before supported profile reuse on the order edit form, but we knew we needed to go the extra mile this time to ensure our UX worked for both customers and administrators.

Additionally, sites may wish to restrict customers to only having a single active address, usually for subscription billing purposes. In Drupal 7, this was supported by the Commerce Single Address module, but for Drupal 8, we’ve made this possible out of the box. To enable it, you’ll edit your customer profile type(s) and uncheck the “Allow multiple profiles per user” checkbox. The UI will adapt automatically:

Notice how the “Select address” option is now gone. The address book will always reflect the last entered address, which will be pre-filled at checkout.

We also added an "Address book" tab to user pages, allowing customers to manage their addresses. If the site uses different profile types for billing and shipping, profiles will be grouped accordingly:

What if I don’t want billing information?

There are cases in which it might not make sense to collect billing information. For this we have another new feature: you can turn off billing information collection on a per-gateway basis:

This allows sites to collect billing information when paying by credit card but not when paying with "Cash on Delivery" (or any other such “manual” payment gateway). For backwards compatibility reasons, each gateway needs to opt-in to this feature through a special annotation key. We’ve already updated Authorize.net, Braintree, and Stripe, and we’re tracking other gateways in this issue.

Behind the scenes

Bringing these features to core took months of work, partly because we had to improve multiple project dependencies to make this possible. For example, we released Address 1.7 in early June with several related (and important) bug fixes.

However, our biggest focus was on the Profile module, which was ported early in the Drupal 8 cycle and needed a lot of cleanup. We tagged several release candidates leading up to last week’s Profile 1.0 release. The whole effort resolved over 60 issues, essentially rewriting most of the module. This work makes the module more maintainable, giving every Drupal user, Commerce or not, a valuable tool.

We’ve also released a new Commerce Shipping beta, adding the ability to override the profile type per shipment type, resolving over a dozen bugs, and adding address book test coverage.

The address book widget did introduce conflicts with some JavaScript used by on-site gateways, breaking user/{user}/payment-method forms. We released Commerce Authorize.Net 1.2 with a fix and will follow that up soon with fixes for our Braintree and Stripe integrations. We are notifying other potentially affected gateways and tracking their status in this issue.

That's all for this update! Join us in the #commerce channel on Drupal Slack to provide feedback, share congratulations, and discuss future plans.