Install

Works with Drupal: 7.x

Using Composer to manage Drupal site dependencies

Downloads

Download commerce-7.x-1.14.tar.gztar.gz 381.08 KB
MD5: 72fd95dc0ea93f1a754018398a4f4b31
SHA-1: 222fb5240efe7e0262a1dba2e0ba6f9149620a5e
SHA-256: 00fa0a84954bee33e2defe455a9c74d4656433dfa3fcb7c300c3c3b256450a6f
Download commerce-7.x-1.14.zipzip 521.54 KB
MD5: 077d21b96f92422c35976a6654f17053
SHA-1: 097b92b6da2a0e6584e97ec5337c9e2b00005e46
SHA-256: add7423593bbb4dda936fd7527355d7fd006e43ce1369fb2cfe53b108c155045

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;

See https://www.drupal.org/node/2697017#comment-12336086 for more information.

Changes since 7.x-1.13 (52 commits):

Created by: rszrama
Created on: 16 Nov 2017 at 22:06 UTC
Last updated: 28 May 2019 at 02:08 UTC
Bug fixes
New features

Other releases