Hey, fellow Drupalists! January has been such a busy month at Centarro that we haven't been able to blog about the exciting improvements we've made to Commerce Core since last year's 2.21 release. We've worked specifically to improve the merchant experience to make our clients' lives easier, and we hope the changes will excite you as well.

Order management improvements

Starting on the order view page, we've had multiple client projects where order state transitions should be approved only when an order is paid in full. It's easy enough to alter the transition form to make that a hard requirement, but as with most things eCommerce, it isn't always a requirement. Moving the state transition buttons to the top of the sidebar and placing the order balance right above them makes it easier for merchants to take the next step of processing an order that much faster:

Because the rendering of the order view page is controlled by a Twig template, existing sites will need to reproduce Commerce Core's code change to move the state transitions up / make room for the order balance. Existing sites using the default template will still need to edit their order type(s) to enable the new Order balance field for display.

We also spent some time improving the order Payments tab. Generally speaking, we worked to surface more details about each attempted / completed transaction in the payments list. The Authorized and Completed times are now displayed in their own columns where applicable, and AVS codes will also be displayed along with gateway specific labels when available: 

Surfacing the AVS response code is essential for helping merchants combat fraud. Additionally, as with the order View tab, we've summed the amount of completed payments to show a pending order balance / make it obvious when an order has been paid in full.

Logging more order activity

Reconstructing what happened to an order when (or by whom) is critical for merchants trying to diagnose fulfillment errors or exceptions. While order state transitions were already logged, we've standardized the format for their messages to make it explicit which transition button clicks resulted in which state changes.

Additionally, we now log the following events:

• Manual order creation by a store administrator
• When a customer completes checkout

Expect to see more activity logs in the near future, specifically around payment attempts and subsequent payment activities. If there are other types of events you'd like to see in the order activity stream, let us know in the comments!

Checkout complete event

Commerce Core 1.x for Drupal 7 included a specific "Completing the checkout process" event and hook, whose closest equivalents in 2.x were the commerce_order.place.* transitions. Since orders can also be placed programmatically or by an administrator, there was no easy way to distinguish when an order was specifically placed by a customer.

This is now possible thanks to a checkout completion event that is dispatched when the checkout "step" changes to the "complete" page. (For developers, the new event to subscribe to is CheckoutEvents::COMPLETION.)

Promotion improvements

The Commerce Core 2.x features related to promotions continue to pay dividends for merchant adoption. It accommodates the primary use cases for promotions and coupons, often with greater flexibility than even more established SaaS competitors like Shopify. Improvements in releases this year included new quality of life changes along with some bug fixing to ensure stacked promotions will no longer permit an order total to drop below zero.

Managing promotions

Enabled and disabled promotions are now listed in separate tables to help merchants more quickly identify which promotions are currently active:

Along with this change, we added operations links to support enabling / disabling promotions right from the promotions list rather than requiring merchants to do so through the full promotion edit form.

"Buy X, Get Y" offers

Until the Commerce 2.22 release, Buy X, Get Y promotions would only apply to an order when the necessary products were added to the cart. Through the sponsorship of Wpromote on behalf of a long-time Drupal merchant, we expanded this offer type to automatically add the offer product to the cart if it isn't in there already.

This improvement led us to introduce the concept of a "locked" order item to Commerce Core that we expect to build on in subsequent releases. Automatically added items cannot be removed or have their quantities adjusted by customers. They are instead "locked" in the UI and managed by the promotion's own logic.

Performance improvements

We've added several indexes to the various entity types defined by Commerce Core to improve overall database performance when querying orders, coupons, payments, etc. For more details, see https://www.drupal.org/node/2907367.