Commerce v1 Upgrades v1.3

Most upgrades are automatically applied, but sometimes you may need to update custom templates, or configuration, to take advantage of new features or improvements. Those changes are discussed here.

Commerce v1.3 brings along a variety of new features as we move closer towards :magic-emoji: subscriptions :magic-emoji:

This document is a preview for 1.3; it is still in active development and has not yet been released. Expect 1.3 to land in pre-release this fall.

PHP 7.2+

Commerce now requires PHP 7.2.5 or up. If you're not yet on 7.2, the package will not allow you to update.

Guzzle 6 replaced with Guzzle 7

We've removed guzzle 6 from Commerce, and are now automatically installing the guzzle7 package instead. This helps avoid dependency conflicts which have gotten increasingly common.

While the core seamlessly updated from Guzzle 6 to 7, it is possible custom extensions or third-party packages are affected by this major upgrade. Those will need to be updated to the Guzzle 7 syntax. Learn more about upgrading Guzzle 6 to 7

New: Scheduler

Commerce now comes with a built-in scheduler for background or asynchronous processing. This can be used for both one-off tasks that need to happen as soon as possible or at a certain time, as well as recurring tasks such as nightly imports or cleanup.

To start using the scheduler, you need to create a cron job per these instructions.

Asynchronous processing has initially been implemented in the following:

  • Sending emails as part of the status workflow. To enable, go to Configuration > Statuses and click on the status change action you'd like to process asynchronously (e.g. the 2 emails sent when payment is completed) and tick "Send asynchronously" at the bottom. This speeds up the initial order processing at the cost of slightly delaying when emails are processed.
  • Nightly generation of future dates according to a schedule in the TimeSlots module.

As 1.3 is still in development, we'll likely add more asynchronous options closer to release.

Templates: email and phone in emails

For some inexplicable reason, we never added the customers' email or phone number in the default email templates. That has now been rectified.

To incorporate them in your own templates, you may use the following examples:

<!-- For shipping address: -->
{% if shipping_address.email %}{{ shipping_address.email }}{% endif %}
{% if shipping_address.phone %}<br>{{ shipping_address.phone }}{% endif %}

<!-- For billing address: -->
{% if billing_address.email %}{{ billing_address.email }}{% endif %}
{% if billing_address.phone %}<br>{{ billing_address.phone }}{% endif %}

These can go in all email templates: emails/message.twig, emails/order-received.twig, and emails/order-to-merchant.twig have been updated in the core.

Regular price now available in cart

Using sale prices and want to show what the price used to be? Now you can.

In your frontend/checkout/cart/items.twig template find where you're rendering the price ({{ item.price_formatted }}, in the default it's around line 40), and add the following to it:

{% if item.regular_price > 0 and item.regular_price != item.price %}
    <del class="product-price__old">
        {{- item.regular_price_formatted -}}
    </del>
{% endif %}

Do note that different types of discounts are applied differently. Sale price types are applied to the item price, while coupon and other discounts are applied to the subtotal (price * quantity). Order item adjustments are, depending on their options, usually applied to the price as well.

This can lead to somewhat confusing cart summaries in certain combinations. Depending on what you use, it's worthwhile looking at how you want to render those. Commerce by default will show a fairly basic view suitable for most shops.

Developer: simpler shipment >< shipping method integration

We've added a new comOrderShipment::getFieldsForShippingMethod method which allows a custom Shipment to add additional fields to the shipping method form in the dashboard. This may make some integrations easier, reducing the need for a matching set of Shipment/Shipping Method when you just need an extra configuration option.

This does not impact existing shipment/shipping method types but may be worth revisiting custom integrations for.