Commerce v1.0.3

Commerce v1.0.3 is now available with some bug fixes and new deprecation notices. Most notably, an issue where an automatic change in selected shipping method (due to cart or address changes) no longer needs a second refresh for the order total to show up properly.

We’re getting close to releasing a release candidate for v1.1, which will remove some deprecated code and event constants. Most of those features have been deprecated since v0.10, v0.8, and some even longer than that. To help you upgrade to 1.1 when it comes out, we’re now logging an error to the MODX log when you use deprecated events in a module, so you can make sure the upgrade to 1.1 wont break the shop.

We’ve also newly deprecated the Commerce::EVENT_ORDER_PAYMENT_RECEIVED event. That has to do with the new payment gateways architecture in 1.1 which is no longer tied to Omnipay. It’s simply not possible to support this event consistently with its current parameters. In most cases, modules using this event should be refactored to use Commerce::EVENT_STATE_CART_TO_PROCESSING, but get in touch with support if you need help.

Full changelog for 1.0.3:

  • [core] Fix shipping method change due to cart/address changes not updating the order total until a second refresh [S20379]
  • [core] To prepare for Commerce 1.1, you’ll now see log entries for modules that rely on deprecated events and usage of deprecated methods that have been cleaned up in 1.1
  • [core] Make sure comOrderAddress is loaded into memory
  • [modules] Commerce::EVENT_ORDER_PAYMENT_RECEIVED has been deprecated and will no longer work in Commerce 1.1. For modules that should fire when an order is paid, use Commerce::EVENT_STATE_CART_TO_PROCESSING instead.
  • [dashboard] Fix JS error on MODX3 [#410]

Dependencies:

  • commerceguys/addressing updated from v1.0.3 to v1.0.4
  • twig/twig updated from v1.41.0 to v1.42.0