Drupal Commerce 2.x for Drupal 8

Recent events, when Acquia announced its partnership with Magento, shook the Drupal community. Blog posts and tweets were written to ensure Drupal commerce is not neglected.

Do we need yet another commerce platform?

How can Drupal Commerce survive in the world of Shopify and WooCommerce, where setting a simple web shop takes a day or less? It makes sense that we ask ourselves if we even need a commerce solution for Drupal when there are so many doing it, and doing it more efficient. 

Let's step back and try to understand what e-commerce is, because it's not only a shop that sells notebooks online and ships them with UPS. We see more and more digital products, like downloadable apps, subscription-based services, ebooks, membership etc. Every solutions like can be its own business model not covered by a general solution. This is where I see Drupal Commerce.

What is new in Commerce 2.x?

Drupal Commerce branch for Drupal 8 was started in 2014 by Commerce Guys, who maintain the version for Drupal 7. It was built from scratch to fix all of the mistakes done in the initial release and to leverage the new Drupal 8 framework.

Currencies

When initially setting up Drupal Commerce, we will need to enable at least one currency. Commerce makes it easier by enabling us to import a currency from a pool of word's currencies supported by data from CLDR. 

Currencies in Drupal Commerce 2 have full support for locales and multilingual display and handle special cases like Arabic numbers out of the box.

Taxes

Taxes are hard, and every platform struggles to correctly handle all of the exceptions and special rules. Commerce 2.x will come with a new library for taxes that come with a new data model and tax resolver. Each tax rate can have more rates amounts that can depend on the location, context and date.

Stores

Stores are a completely new concept. In Drupal 7 we only had one instance of a store that had global settings like email and address. In Drupal 8 we can now create multiple stores that have different settings (email, address, default currency, tax settings, etc. ).

One thing to note is that each store will have its own cart and checkout. Even though it looks easy to set up a new store, it will be less likely you would want to set up multiple stores as it brings the overhead for customers.

Products

The new commerce comes with a new type of entity for Products. In D7, content (or node) types were used to display product information. This was confusing to many end users as they had to switch between Commerce and Content section. From the developer perspective, it is now easier to get to the product while looking at the items in the order.

Product variations

A product can have one or more variations, which are tracked by a unique stock keeping unit (SKU). In Commerce 2 the relationship is 1-to-1 as this is a common practice. In the previous version product variations needed to be created separately and then added to each product. This was improved with a module called Inline entity form, which is not required and implemented in Commerce 2.

Attributes

To separate one variation from another (i.e., different colors of a T-shirt), we use attributes. Commerce for Drupal 7 used taxonomy terms for setting up attributes. This was again confusing at Taxonomy lives separately from Commerce and was a bad UX practice. Now attributes are a separate entity managed inside Commerce section of the Drupal platform. Already, out of the box, it comes with an interface to bulk edit attributes of a certain type.

Fancy attributes

One other great feature of attributes is taken from the so-called "Fancy attribute" module in Drupal 7. This module enables us to use images or other content to select a variation based on an attribute instead of a boring dropdown. 

Orders

Like all the other items orders are entities, and we can create multiple types of orders. If we are selling two very different types of products (physical and digital), the flow and information would be different, and we can now have two completely different types of orders. Each order is completely configurable: emails, cart, views and workflows.

Order items and adjustments

From Commerce 1.x we know that each product place in the order was defined as a Line item. In Commerce 2.x, the line item was renamed to Order item, but it only holds purchasable products, wherein Drupal 7 line item was used for shipping costs and discounts.

Cart

If we have a shop with two different products, they added to two separate carts and checked out separately. This functionality comes out of the box. Each display of the card is provided by Views modules and can be completely customized to your needs.

Checkout flows

If we can have multiple order types and multiple carts, then it makes sense we can tailor the whole checkout flow based on the requirements. For example, to buy a website membership user need to have an account where physical products could be sold to anonymous users who will never need to login again.

Commerce 2.x comes with a default plugin "Multistep", which is similar to what we knew in Commerce 1.x. Instead of trying to override the default flow the best practice is not to implement a checkout plugin that will do exactly what we need it to be doing.

Payments

One of the limitations of Commerce 1.x was that the payments lived inside of Rules, so managing the configuration was not easy, and once a module (e.g., Paypal) was set; there was no way to reuse the payment gateway. In Commerce 2.x all of the payment gateways come as plugins that can have multiple instances. 

Right now only two major payment gateways are available for Drupal Commerce 2.x: Authorise.Net and Braintree.

Shipping

Drupal Commerce 2.x core module has implemented features from more than 20 contrib modules that we needed fro Drupal 7. The idea is that Commerce core needs to cover functionality need for the majority of e-commerce websites.

Shipping was not considered to be a must-have for all of the website (as mentioned at the beginning, digital products can become a niche for Drupal Commerce). Although creators of Commerce are well aware that there is still a big portion of websites that will need shipping in place.

Shipping can be very simple (flat rates) or can become very complex when introducing shipping services like UPS that calculate the price based on physical attributes of the package. Drupal Commerce 2.x Shipping takes into the account and introduces a new concept of boxing the products. Also, the shipping address is not attached to the order but the shipment. By default, there will be one shipment per order, but the underlying structure will allow us to build complex shipping logic.