Release info

Release notes

This release includes a variety of improvements related to performance and scalability, PHP 7 support, and more. We've also satisfied a long time feature request by allowing developers to change their product pricing strategy to use code to directly manipulate product prices. (Previously you could only manipulate prices via Rules.) New features also include a "placed" timestamp, cart provider plugins (allowing for sessionless shopping carts), and currency formatting / credit card validation updates all backported from Commerce 2.x.

Please pay attention to the following changes before updating:

We've backported the "placed" timestamp from Commerce 2.x.

Previously, Commerce 1.x only included a created and a changed timestamp on orders. Since Commerce 1.9 we've included a default checkout completion rule that updates the value of the created timestamp to capture the point the order was considered "placed". Unfortunately, this wasn't sufficient for all scenarios, so we've backported the placed timestamp from 2.x to 1.x in this release.

Adding a column to a table is a costly database operation that takes longer the more records you have in the table. If you have a large number of orders in your Drupal Commerce site, we strongly recommend using drush to perform the update.

Additionally, we do not automatically populate this placed timestamp. We do include a drush command, drush coupt, that you can use to copy your orders' created timestamps to the placed timestamp. (This assumes your site has actually been using the default rule.)

Product matching no longer uses EntityFieldQuery by default.

In Commerce 1.10, we changed our SKU based product matching (as used in the autocompletion for product reference fields) to use Drupal's EntityFieldQuery query builder instead of building the query directly using db_select(). This introduced a scalability issue that we resolved in Commerce 1.12, but that change in turn introduced a data loss regression.

As a result, we've reverted this change back to the Commerce 1.9 method, defaulting to using db_select(). For most sites, this is completely fine. However, sites that depended on the EntityFieldQuery (for example, to source product data from a remote or non-SQL database) can still make use of it by setting the following variables in their settings.php files:

// Set to TRUE to make use of EntityFieldQuery for product matching.
$conf['commerce_product_match_products_efq'] = TRUE;
// By default, the options list callback for product matching has no
// limit, but using EntiyFieldQuery also forces a dependency on
// entity_load_multiple() for all potential matches. This can lead to
// memory errors for fields whose default limit hasn't been set,
// though in other cases setting a limit can lead to data loss. Adjust
// this value optionally to achieve the beset performance on your site.
$conf['commerce_product_reference_default_options_list_limit'] = 100;

Issue #2779467 by jsacksick, nicoloye, rszrama: only perform product field injection when the referencing entity's view mode has one or more product fields visible.

Issue #2922595 by mglaman: do not create a metadata wrapper in commerce_line_items_quantity() if a line item object is passed in.

Issue #2697017 by rszrama: revert product matching and the options list limit to the Commerce 1.9 implementation and provide a setting to opt-in to the EntityFieldQuery based version introduced in Commerce 1.10.

Issue #979740 by rszrama, das-peter: disable autocompletion on the Add to Cart form by default to avoid inappropriate products being added to the cart when users go back from a redirect after submitting the form.