We made many important improvements to Drupal Commerce over the summer, including an improved promotions UI, BOGO offers, and product category conditions in the 2.8 release and full list price support with the 2.9 release. After a long sprint to the finish, we’ve now finally released 2.10, one of our largest releases to date that resolves 39 issues and feature requests.

Product administration improvements

Six years ago we released the first stable version of Commerce Kickstart 2.x and the new (at the time) Inline Entity Form module, which allowed us to manage multiple product variations from a single product page form for the first time. Since then, Inline Entity Form has become a popular Drupal module and a recommended way to manage products in Drupal 7. When we started developing Commerce 2.x for Drupal 8, we ported over Inline Entity Form and the previous approach to managing products, but now we’re ready to take another step forward to advance the usability and performance of product management.

As of the 2.10 release, product variations are managed on their own tab of the product page form. This follows the same UI pattern we established for coupons within the promotions UI.

Moving variations to their own tab allows us to extend the UI in future releases, specifically to add bulk operations for tasks such as price updates, image replacement, and even the creation of a full set of variations. We foresee other modules adding their own elements to the tab, like the Commerce Pricelist module adding a “Prices” dropbutton item to provide quick access to every price for a variation on multiple price lists.

Having variations on a separate tab would be a bit much for products that always only have a single variation, so we’ve made sure to accommodate that use case in the new version. Each product type’s settings form includes an “Allow each product to have multiple variations.” option that when disabled reverts to the inline editing experience for products of that type.

Query access filtering

If you create a new role for your merchant and only give it the “Book: View products” permission, you’d expect users with that role to be able to book products but no others. In Drupal 7, our solution for this was a generic query access API in Drupal Commerce itself that filtered entity loading queries based on user permissions.

To achieve this same result in Drupal 8, we’ve rebuilt this API and added it to the recent 8.x-1.0-rc1 release of the Entity API module. Commerce is now using it for administrative listings of products, orders, and stores. The API adds a QueryAccessEvent to allow modules to alter the access conditions, making it possible to apply further filtering (e.g. only show the user’s own store). Next we will extend the filtering to Search API to filter customer facing listings.

User-driven API improvements

Over 4,000 websites have launched on Commerce 2.x in the past year, pushing us up over 6,000 in total. As developers launch their projects, we keep our lines of communication open to hear about all the things that annoyed or hindered them, and we work to improve our APIs as a result. Several examples that made it into this release include:

• #2856586: Add an “order paid” event
• #2959336: Add a “path” field to stores
• #2804227: Add getTotalPaid() and getBalance() methods to orders
• #3005796: Improve the DX of overriding the PaymentInformation / PaymentProcess panes
• #3003832: PaymentProcess needs to take the order balance into account

(Note that as a result of the last two, if you have overridden the PaymentInformation or PaymentProcess panes on your site, you will need to update them for the new release.)

We love to hear stories of the great things you’re doing with Drupal Commerce, and we’d also love to improve the core APIs and data model to better support you, too. Feel free to join us and hundreds of other developers in the #commerce channel on Drupal Slack for real-time discussion or post your proposals directly to the issue queue for discussion.