Drupal Commerce Blog

What's happening in the world of Drupal Commerce.

Drupal Commerce 2.0 Enters Beta

During the Commerce 2.x session at DrupalCon Dublin we officially tagged Drupal Commerce 2.0-beta1, our first production ready release. This does not mean it is feature complete or bug-free, but it does mean that from this point on, we support updating between 2.x releases - a key requirement for production usage. Start a Drupal 8 eCommerce site today, and you will be able to update your way to the full 2.0 release and beyond.

Matt and Ryan at DupalCon Dublin
Photo credit Will Jackson during the "Launching online stores with Commerce 2.x on Drupal 8" session.

For a quick overview of our project philosophy and the improvements we've included in Commerce 2.x, watch our session from DrupalCon Dublin.

The session heavily features the Sport Obermeyer case study, one of the first major eCommerce projects built on Drupal 8 by Bluespark and Commerce Guys. Their project influenced and shaped Commerce 2.x development in a big way, validating our ideas and providing solid use cases for features like fancy attributes, promotions, coupons, and more.

Additionally, we helped build the project as a single site serving three unique customer personas with a different purchasing workflow for each one. That drove development on our add to cart and checkout flow APIs, ensuring they have the needed flexibility to allow parallel implementations from day one. In addition to the case study linked above, check out Matt Glaman's interview with Bluespark for more information.

So... what has changed since alpha4?

Drupal 8.2

Commerce 2.x now requires Drupal 8.2.

This is a reflection of our policy always to require the latest Drupal branch. This allows us to keep improving Core, moving code from Drupal Commerce and Entity API upstream into Drupal itself. For example, Drupal 8.2 includes the Plugin Form API, which we helped build after implementing it in Commerce for payments.

Speaking of payments...


Payments in Commerce 2.x

The beta release includes a very robust Payment API that represents a significant improvement over the API in Commerce 1.x. This time around we aimed to significantly reduce the amount of custom code / time required to integrate a new payment gateway.

  • Payment gateway plugins that store their configuration in configuration entities.
    No more going into Rules to input API credentials, there's now a UI for that. It even allows reordering payment gateways to affect their position in checkout.
  • Integrated tokenization support
    Supported in D7 through the Commerce Card on File module, this API is now built into Commerce. If the gateway supports it, customers will be able to save their credit cards for future use (with Commerce storing a PCI-safe token behind the scenes).
  • User interfaces for authorizing, voiding, refunding payments
    Modules no longer need to do this themselves, all relevant UIs are provided by Commerce.
  • More flexibility
    Each gateway can define custom fields for payment, a custom workflow, and any number of custom operations with their matching forms.

Right now the Payment API supports "on-site gateways," which is how we call gateways that support tokenization directly on the checkout page. Support for off-site gateways (via iframe or a full redirect) is already in progress.

Our first integrated gateway is Braintree. Owned by PayPal and providing a Stripe-like experience, it is the best in class when it comes to PCI compliance (level A, which is the lowest and easiest), usability, and developer experience.

Matt Glaman has also started work on the Authorize.net gateway. It is functional but doesn't yet include integration with the new Accept.js library (which reduces the PCI compliance requirements from D to A-EP).

Promotions and pricing

We now have a commerce_promotion entity type and an initial matching UI for defining promotions, along with their conditions and actions. The plan is to extend this UI with coupon support, deprecating both commerce_discount and commerce_coupon 7.x in one go.

We also spent much time working on the underlying API. There's now a price form element as well as a price value object that can be passed around or used for calculations. The value object uses a bcmath based Calculator under the hood.

We've also implemented adjustments as a replacement for the anonymous Commerce 1.x price components array, allowing for both line item and order level price changes. Adjustments are stored serialized, improving order refresh performance. The new order refresh API allows order processor classes to process orders and add taxes, promotions, control stock, etc.

Improved checkout UX

Creating an ideal checkout UX is an effort that will span multiple (pre)releases. With beta1 we are closer to our goal. Some elements have been added:

  1. Checkout progress block
  2. User registration (if anonymous checkout is disabled)
  3. Order summary sidebar

Checkout registration and progress bar

Fancy attributes

Fancy attributes on Sport Obermeyer catalog
Example taken from the Sport Obermeyer womens collection listing https://www.obermeyer.com/catalog/womens

Select attributes by clicking a color or an image. On the add to cart form or product listing.
Covered in a previous blog post.

Improved tests and testing infrastructure

Our test coverage has been significantly expanded. At the same time, all tests have been converted from the old Simpletest framework to the new phpunit+mink framework, making Drupal Commerce the first major contributed module to accomplish this. We have also improved the drupal_ti project for seamless Composer support in contrib projects for automated testing, which DrupalCI does not yet support.

You can read more about this effort at https://drupalcommerce.org/blog/45322/commerce-2x-unit-kernel-and-functi....

Another big improvement is automatic testing of coding standards, performed by phpcs and the Coder module, implemented by Lars Olesen (our community Commerce Kickstart maintainer). This has resulted in a number of coding standard fixes and lead to cleaner code.

Improved translation support

Products and variations can now be translated thanks to improvements in the Inline Entity Form module sponsored by Acquia. Product attributes and their values can also be translated... in one screen.

Translating a Color product attribute

Commerce Migrate

Many new eCommerce sites are created by importing products and orders from a previous system. To make this easier, we built Commerce Migrate, our first 2.x contrib. It has received over 40 commits from multiple contributors and now supports migrating from Ubercart 6, Ubercart 7, and Commerce 1. We took a sanitized database export for each environment, then wrote tests to ensure a successful import.

There are still plenty of open issues to resolve edge cases, but with your help, we are confident we can have a stable release in time for Commerce 2.0.

The Ubercart 6 migration was created by creativepragmatic and significantly improved by b_sharpe. The Commerce 1 migration was created by Matt Glaman and significantly improved by harings_rob.


This release could not have happened without Matt Glaman, my colleague and co-maintainer, who was sponsored by Bluespark and Thinkbean to work on Commerce 2.x. Outside of Commerce Guys, Commerce 2.x has had 51 contributors so far, contributing 324 commits of all sizes. Moreover, this does not even count the contributions to our library and our other modules, such as Inline Entity Form, Entity API, Address, Profile, etc.

Special thanks to Acro Media and Vox Teneo for dedicating several of their own developers in key areas.

We're simply overwhelmed by the support and contributions we've received from the Drupal community and broader PHP community. Thank you. : )

What's next?

Our work is not done! We need to complete the Payment API, add back the temporarily removed commerce_tax module, extend promotions. In parallel, we need to make sure Shipping gets made. However, our primary focus is addressing your bugs, and answering your questions. See you in the issue queues!

Bojan Zivanovic
Posted: Oct 6, 2016


Paul Driver on October 6, 2016

Great write-up and great to hear that commerce 2.0 is out of the gates. It will be interesting to learn more about the payment integration improvements. I would also be interested to know which D8 base theme was chosen for Sport Obermeyer.

Paul Driver

Hoa Le on October 7, 2016


I follow http://docs.drupalcommerce.org/v2/install.html to install drupal commerce to my existing site.

but this step: composer require "drupal/commerce 2.x-dev" but I got the message:

Problem 1
- The requested package drupal/commerce could not be found in any version, there may be a typo in the package name.

Potential causes:
- A typo in the package name
- The package is not available in a stable-enough version according to your minimum-stability setting
see for more details.

I tooks me some days but still could not install. Any one can help me?

Thank you.

bojanz Bojan Zivanovic on October 7, 2016

Could not reproduce your issue on a fresh install.

Following the docs I:
1) Downloaded Drupal 8.2.0, switched to that directory ("cd drupal-8.2.0")
2) Ran 'composer config repositories.drupal composer https://packages.drupal.org/8'
3) Ran 'composer require "drupal/commerce 2.x-dev"'
The process completed successfully. You can open an issue in our issue queue for more help.

basscleff94010 on March 2, 2017

Like the comment above, I can't download the commerce package using your instructions. I believe it is because you have an updated version of commerce code. Here is what I did and resulting composer error:

$ composer require "drupal/commerce 2.x-dev"
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

Problem 1
- Installation request for drupal/commerce 2.x-dev -> satisfiable by drupal/commerce[2.x-dev].
- drupal/commerce 2.x-dev requires drupal/address ~1.0 -> satisfiable by drupal/address[1.x-dev, 1.0.0-rc4, 1.0.0-rc3, 1.0.0-rc2, 1.0.0-rc1, 1.0.0-beta4, 1.0.0-beta3, 1.0.0-beta2, 1.0.0-beta1] but these conflict with your requirements or minimum-stability.

bojanz Bojan Zivanovic on January 3, 2017

All contrib functionality is developed by the community, or driven by client funding.

I doubt we'll work on affiliate functionality since we've never had a client that needed it.
It's a great example of a feature that should be built by the community.

Subscriptions are a major use case so there is a big chance that a client might fund us to work on it in 2017.
I'd be fine with seeing someone from the community develop it before us, though.

I would be happy to provide direction to anyone willing to lead/code or fund such efforts,

jons jons on June 15, 2017

All great stuff - but could you point to more info on how to implement adjustments/order refresh API