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.

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

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

Fancy attributes

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.

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.

Credits

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!