About two years ago, I reported on our first experiences with Drupal Commerce, and even then, the e-commerce framework for Drupal 7 proved to be an incredibly powerful tool. However, with time, new projects and challenges arise, putting existing tools to the test. Now I can say with certainty that two years ago I only scratched the surface of the iceberg.
Increased Demands
Last year, we had the opportunity to venture into something new in e-commerce. In most cases, a web shop only covers the initial steps in the sales process of physical goods. In the case of Garden Gnome Software, a project we worked on last year, it was about the distribution of digital goods, specifically software licences. There are no staff to take and process orders. The entire process, from product presentation to delivery, is completely managed by the shop system.
Extending Drupal Commerce
Admittedly, Drupal Commerce cannot do this out of the box. But thanks to the solid foundation of Views and Rules, it is well known that extending functionality is not difficult.
The basic API of Rules is as simple as it is powerful. Custom Conditions and Actions are easy to implement (see documentation). The licences purchased by customers were implemented as custom Entity Types. Thanks to the Entity API, these are automatically compatible with Rules and can be easily generated or modified within the Drupal Commerce purchase process.
Practical additional modules for Rules that were used include Conditional Rules and the Rules Bonus Pack. The former enables conditional branching within a rule's actions. In principle, this can always be solved using Rules Components. In some cases, where the branched path consists of only a few actions and is not reused elsewhere, you gain more clarity with less configuration effort. The Rules Bonus Pack is actually an experimental module for potential Rules features, will never be in a stable state, and should therefore be used with caution. However, features like loading entities from a View and integration with Panels can be invaluable.
Product Variants and Configurable Products
In my last post on Drupal Commerce, I mentioned the conceptual hurdle one faces when accustomed to other shop systems. A reminder: a t-shirt in three different colours and four different sizes is not a configurable product but an aggregation of 12 products displayed in the same product display. This makes sense for this case, as they can also have different SKU numbers, prices, and stock levels.
However, this does not mean that the opposite approach is impossible. In the case of Garden Gnome Software, the products sold are licences. These can be ordered in any quantity and additionally have a variable number of included Seats, i.e., workstations for which they can be used. However, it makes no sense to create a separate product variant for every possible number of seats.
The solution is not too complicated: Line Items in Drupal Commerce represent individual lines of an order. For example, "3 red shirts in size L". However, Line Items are also Entities, and like Nodes or Products, they can be equipped with additional fields. So, in addition to the built-in field for the order quantity, a Seats quantity was quickly introduced. The value contained therein naturally impacts the final price, which can be easily solved with Product Pricing Rules.
More exciting was the ability to change the number of Seats in the shopping cart. Since the Commerce shopping cart is also nothing more than a View – or rather a Form View – a Views Field Handler needs to be implemented to add a form field. How this works can be learned from the example of the Views Handler for the order quantity.
Checkout and Delivery
One point whose complexity is easily underestimated is the automatic completion of an order. As soon as payment is received, the order is set to the completed status and the purchased licences are generated. Sounds simple, but it isn't. Some important points to consider:
For good reason, Drupal Commerce does not automatically complete an order when it has been fully paid. However, there is an event called "When an order is first paid in full", which is triggered as soon as the Order Balance reaches 0.
When the Order Balance reaches 0 is sometimes unpredictable, depending on the payment provider. We had cases where Paypal announced the clearing hours later, and at the same time, cases where the order was already fully paid before the user had even completed the checkout process. The latter case primarily leads to problems because Commerce only generates accounts for anonymous customers upon full order completion. This makes sense, as you don't want to fill your database with user accounts from abandoned orders. However, it leads to problems if you rely on a User ID already existing when the transaction is completed, to which you want to assign a newly created licence.
If you try to solve the problem directly with complex Rules Conditions, you quickly risk getting bogged down in a swamp of race conditions. I would advise instead to process the subsequent steps directly in the Rules Scheduler, which represents a far more stable and simpler solution.
Conclusion
Drupal Commerce has once again impressively proven that it is probably the most flexible e-commerce framework on the market. Such flexibility naturally requires a bit of know-how to implement, but acquiring this pays off. And the roadmap for Commerce 2.0, together with Drupal 8, offers great hope for truly significant developments.
