In a second blogpost we will focus on challenges we had in our first e-commerce project in Drupal 8.
Built on reusable (composer) components
Quite a few of the lower level API’s have been built as generic libraries that can be used outside of Drupal. This allows CommerceGuys to collaborate on those with other eCommerce systems outside of Drupal.
That means it is a requirement to use composer to maintain sites. That works great and is not a big problem for experienced developers, especially those used to other PHP frameworks or languages where a package manager is common. But it can be a problem for less experienced users and some hosting providers. The hosting provider we use for this project, platform.sh, has support for deploying projects using composer.
More functionality out of the box
Unlike Commerce 1.x, which provided only a minimal amount of features and required a lot of site building and customization, Commerce 2.x is closer to Commerce Kickstart than a plain Commerce 1.x installation. It includes a number of other modules like Inline Entity Form to improve UX as well as many features that previously required additional modules like storing and reusing payment methods, stores/marketplace and much more.
That makes it a lot easier to start a new commerce project, especially when adding it to an existing Drupal site or building custom install profiles.
Different terminology and product structure
Instead of using Nodes that reference products, by default Commerce now provides two entity types, Products and Product variations that provide a similar functionality with a considerably better UX. Payment methods from 1.x (e.g. Stripe or PayPal) are now called payment gateways and a payment method is a specific way a user paid, e.g. a specific credit card.
It takes a bit of time to get used to it, but the new terminology makes sense and should make it easier to learn commerce for new developers.
Opinionated, customization through code/templates
Commerce 2.x has an opinion as to how a shop and checkout process should look and work. It also has fewer configuration settings and options as experience has shown that less experienced users often break their installation with the wrong setting. At the same time, the mentioned flexibility makes it easier to customize for developers. One example is the checkout complete message. In 1.x this is a configuration setting, but we never have built a commerce site where just changing that text was sufficient. In 2.x, it is a twig template, which already offers a lot more flexibility in being able to implement a completion page that looks good. The confirmation mail is similar, it is built from a twig template and looks good out of the box.
Designed to be extended, parts replaced and changed
Almost everything is a plugin and there can be multiple variants of everything. That includes for example the checkout flow, there can be multiple variants of that and each uses a plugin. Any entity can be “bought” if it implements a certain interface, and it is also possible to do a checkout without any products at all. A lot of UI components are organized as reusable form elements.
Based on what we have seen so far, Commerce 2.x has a good balance between a good out-of-the-box shop and checkout experience while remaining flexible and customizable for developers.
Don't miss the second part of this blog series! We will go in detail about our experience of Drupal Commerce 2.x in a customer project.
