Drupal Commerce Blog

What's happening in the world of Drupal Commerce.

Commerce 2.0-alpha4 released

Almost two months and seven thousand lines of code later, here's Commerce 2.0-alpha4. This release brings checkout and revamped product attributes. We've also added upgrade path APIs in preparation for beta1. Meanwhile, we helped push Drupal 8.1 out the door, and fixed many Inline Entity Form bugs.

Reminder: Commerce 2.x alphas are NOT production ready. No upgrade path is provided between alphas. A full reinstall is needed each time.

Drupal 8.1

Six months ago we helped create the Entity API module using the generic entity code from Drupal Commerce. For Drupal 8.1 we moved a lot of that functionality into core. The list includes:

  • add-page and add-form route generation (+ controllers)
  • Rendered entity views handler
  • Base entity property generation
  • RevisionableContentEntityBase (+ RevisionLogInterface)
  • Param converter and route enhancer for revisions

The Entity API module still exists, but is now two thousand lines of code lighter. We'll continue to expand it and then move those APIs into Drupal 8.2.

We also continued to improve the Composer integration in core. Thanks to recent bug fixes, adding Commerce 2.0 to an existing Drupal 8.1 site is now as easy as:

# Add the Drupal Packagist repository before downloading your first module.
composer config repositories.drupal composer https://packagist.drupal-composer.org
# Download Commerce.
composer require "drupal/commerce 8.2.x-dev"

This downloads all dependencies, including both Drupal modules and PHP libraries. Goodbye, Composer Manager! Read more about it in our installation documentation.


To date we have done three major iterations of the 2.x checkout API, addressing user and developer feedback going back to the earliest 1.x releases.

The checkout form is now rendered by a checkout flow. Checkout flows are plugins providing multi-step forms that can be configured by store administrators. This configuration is stored in matching commerce_checkout_flow config entities. Each order type can have its own checkout flow. Developers who want to implement a completely custom checkout flow can now easily do so by providing a checkout flow plugin. Others can rely on our default checkout flow implementation which uses checkout panes. The checkout pane configuration UI is AJAX powered and resembles the "Manage display" field UI:

The new checkout flow configuration form.

We've spent a lot of time researching checkout UX. You can find our initial conclusions in this issue. The current implementation is still unstyled and unfinished, but it already contains some interesting improvements:

  1. "Login or continue as guest" checkout pane:
  2. Redesigned review pane (including edit links leading to the original step, better markup):
  3. Contextual action buttons ("Continue to review", "Pay and complete purchase")

Upcoming work includes a checkout progress block, the cart summary, and reusing addresses. See this meta issue for more information.

Product attributes

In our products blog post we talked about simplifying product attributes (such as Color and Size) by removing support for option fields and using only taxonomy. This was a move in the right direction, but it still left us with the problem of mixing Attribute related taxonomy vocabularies (such as Color) with content vocabularies (such as Tags). The taxonomy term creation screen also allows only creating one term at the time, which was criticized by clients in the D7 times.

We fixed this by creating entity types for attributes and their values (commerce_product_attribute and commerce_product_attribute_value). This allowed us to create a more optimized UI, which allows creating and reordering multiple values at the same time:

Adding values to a product attribute.

Naturally, these entities are still fieldable. Any additional fields on the attribute type (e.g. image or price fields) will show up for editing beneath each value's Name field.

The next step was to create an API for managing attribute fields. Attribute fields are entity reference fields on product variations which point to a specific attribute value assigned to the variation. Thanks to this API we now allow users to select attributes on the product variation type form, automatically creating entity referenced fields as needed:

Adding product attributes to a product variation type.

These changes significantly improve the user experience for merchants and site builders.

Next steps

Our focus for the upcoming week is merging an initial version of the Payment API. You can follow along this issue to be notified when that happens,

Bojan Zivanovic
Posted: Apr 28, 2016


WeBla cedric_a on May 3, 2016

Allowing merchants to chose a checkout flow per product is a great feature.
I imagine it would allow merchant to set different payment services in each checkout flow, or not ?

matt on May 5, 2016

Really excited about the possibilities offered by commerce 2.x. Do you have any information on supported payment methods/gateways that will be available upon release? I can't seem to find anything on that front.

bojanz Bojan Zivanovic on May 7, 2016

Payment gateways are mostly a community effort.
We ourselves are planning to support Braintree on launch. I'm looking for volunteers to port Stripe and Paymill, since those would be very similar to Braintree.
I'm also hearing rumors of porting authorize.net from Acro media, based on one of their client sites.
That leaves PayPal as the big unknown (when will it happen,and sponsored/coded by which company).

I'll share more information once I have it.

tim@ellemeet.net tim on May 5, 2016


Since Platform.sh supports node.js a headless drupal commerce settup with node.js serving the front-end comes to mind. How achievable will this be once the new commerce is finished?

bojanz Bojan Zivanovic on May 7, 2016

JS front-ends for ecommerce websites have been very rare, and I'm guessing it's due to how much work you have to do on the JS side. No matter what Commerce gives you, you need to reinvent half of it in JS (cart, checkout, some form of payments). Core provides REST endpoints for all entity types, so it will be possible, for those willing to invest significant resources into the experiment.

tim@ellemeet.net tim on May 7, 2016

But would it make sense? DC is great at backend logic (like Drupal itself). We were experimenting with it because of Drupal 8 Rest obviously. Indeed we figured interaction (adding to cart, etc) would be the most complicated. But we assumed this might be possible with a custom module which would interact between nodejs and DC.

tim@ellemeet.net tim on May 7, 2016

Also a headless Drupal Commerce with a general REST API would make sense for iOS and Android apps (at least here in the Netherlands customers buy using apps a lot in 2016) and to ease implementation of fullfilment, stock , etc. Or am I completely off track here?