Commerce 1.1 available as pre-release

We started working Commerce v1.1 shortly after the release of Commerce v1.0 in May. This release is once again massive, with many new features and improvements for you to enjoy.

Today's release is available in the pre-releases channel and recommended only for use on development and staging environments. The stable release will follow in a couple of weeks.

This release includes some minor breaking changes and requires PHP 7.1. If you have custom-built modules that were built for v0.12 or older, you should make sure you're not relying on functionality that was already deprecated. First upgrade to v1.0.3, and check your MODX error log for any deprecation notices. We've already released updates for our official extensions where needed. If you upgrade directly to 1.1, and a module causes an error in initialisation, you will see a warning icon in the modules list.

One notable change in particular is that the \Commerce::EVENT_ORDER_PAYMENT_RECEIVED event will no longer be executed in 1.1. This event was commonly used, but not implemented consistently (e.g. for Adyen it could not fire on webhook-based confirmation). While the significance of a received payment cannot be understated, this event did not necessarily mean an order was ready for processing - which is what most implementations assume. Any module implementing this event will need to be updated to use \Commerce::EVENT_STATE_CART_TO_PROCESSING or similar event. Let us know if you need some help.

Please check the v1.1 upgrade notes when upgrading - it includes manual/notable changes and a full list of all removed/deprecated functions. See the full changelog here.

What's new?

So, disclaimers out of the way, what are the exciting new features awaiting you in v1.1?

Let's discuss some highlights.

Updated Payment Gateways

We rebuilt the way payment gateways are integrated, making it more flexible and no longer exclusively reliant on Omnipay. We've also fixed an issue where webhook-confirmed payments were using the wrong context.

With this new system in place we've updated the Mollie, Braintree, and Stripe payment gateways to their latest integrations, and updated their default styling. The other gateways still function they way they did before.

Shipping & Shipments

Shipping methods learned some new tricks in v1.1, with the ability to generate a form to embed on the shipping step and an update to the comOrderShipment->setShippingMethod() method to take in additional data.

Shipments can generate a tracking URL and provide shipment type-specific information. We'll update the documentation for custom shipping methods soon, and will also showcase exactly what these new features can do in an amazing new extension for the Dutch/Belgian market, which is almost ready for release.

For shops selling internationally, you'll be pleased to know you can now restrict shipping/payment methods by excluding countries, too. Prefix with a dash or use the new EU short-hand to finetune when they are available more easily.

To make sure your shipping methods are set up correctly, the configuration checklist will now warn you if delivery types are missing shipping methods.

Custom Order Fields

Custom order fields were introduced in v0.12, and now you can use the Basic Custom Fields module to accept user-submitted values without having to write a module.

Products & Pricing

Products can now have infinite stock, making it easier to combine digital and physical products in the same store.

Product prices now also support user and usergroup price types. Great for discounting products only for VIPs, resellers, or B2B pricing. If you have a custom price type implementation, there has been a small change in the getFields() signature that you will need to add, and you can also use a select and text field type now.

Dashboard improvements

We've made some tweaks to the dashboard to allow execution of inline JavaScript, to allow more dynamic fields or views.

When clicking a link or button that opens in a modal, the modal will now immediately show up with a loading spinner to make the interface more responsive, especially for views that take a little longer to load. URLs in the browser are now updated when clicking a link, rather than when the response comes back.

Templates and snippets

The default invoice/web.twig template has been updated to only add the img tag when a logo is configured and fix a wrong date being set for the order date.

A new locale-aware strftime filter has been added to Twig templates.

The get_products snippet now supports wrapping by getPage/pdoPage, a &wrapperTpl, and &where for extra filtering. The get_orders snippet also supports &where now.

In the template used by the get_matrix snippet, you can now use any {{ resource.FIELD }} placeholder.

Developer features

If you're using $commerce->twig in a module, that's currently hard-coupling your code to Twig. To reduce the coupling we've added a new $commerce->view() that provides a cleaner, less-coupled interface.

The DescriptionField now supports a raw option for when you need to render HTML in a form.

And more..

These were the highlights of Commerce v1.1, but we've fixed more bugs and made more improvements. For more, see the full changelog and the v1.1 upgrade notes.