Changelog

This is the second release candidate for WooCommerce 6.3. Our final release is on track for March 8 release date.

Changes

Since the rc 1 release, the following change has been made:

• WooCommerce Admin has been updated from 3.2.0 to 3.2.1. The changelog is available here.
• Fixed permission check for reviews in v1 & v2 REST API.
• Fixed Path Traversal in Importers.

Testing

If you’d like to dive in and help test this new release, our handy WooCommerce Beta Tester plugin allows you to switch between beta versions and release candidates. You can also download the release from WordPress.org.

A set of testing instructions has been published on our Wiki page in GitHub. We’ve also posted a helpful writeup on beta testing to help get you started.

If you discover any bugs during the testing process, please let us know by logging a report in GitHub.

We’re excited to announce that the first release candidate for WooCommerce 6.3 is now available. We are currently on track for our planned March 8 release date.

Changes

Since the beta release, the following change has been made:

• WooCommerce Admin has been updated from 3.2.0-RC to 3.2.0. The changelog is available here.
• Create and fill the product attributes lookup table during a clean install of WooCommerce (#31911).
• Add extra UI for aborting/resuming the product attributes lookup table filling (#31889).
• Reverted #31593 that caused the returned line item price to be a string instead of a float. (#31935)

Testing

If you’d like to dive in and help test this new release, our handy WooCommerce Beta Tester plugin allows you to switch between beta versions and release candidates. You can also download the release from WordPress.org.

A set of testing instructions has been published on our Wiki page in GitHub. We’ve also posted a helpful writeup on beta testing to help get you started.

If you discover any bugs during the testing process, please let us know by logging a report in GitHub.

Beta 1 for the March 2022 release of WooCommerce is now available for testing! You can either download it directly from WordPress.org or install our WooCommerce Beta Tester Plugin.

Highlights

• WooCommerce Blocks: We’ve updated to the 6.9.0 version of the feature plugin. See the release posts for 6.8.0 and 6.9.0 to see what’s new.
• WooCommerce Admin: We’ve updated to the 3.2.0-rc version of the feature plugin. See the changelog to find out what’s new.

Filters and Actions

This release adds new filters:

Filter	Description
woocommerce_set_cookie_enabled	Add cookie consent filter.
woocommerce_cart_item_removed_because_modified_message	Filters on the cart item removed message.

Database Changes

• Product attributes lookup table – Add two database indices to the product attributes lookup table, these are intended to improve the performance of the table querying when there’s a lot of products and attributes. This will bump the corresponding internal database version to 6.3.0.

Template Changes

There are no template changes in this release.

Deprecations

There are no deprecations in this release.

Release Schedule

Version	Release
Beta	February 15, 2022
Release Candidate	February 22, 2022
Final Release	March 8, 2022

Testing

If you’d like to dive in and help test this new release, our handy WooCommerce Beta Tester plugin allows you to switch between beta versions and release candidates. You can also download the release from WordPress.org.

A set of testing instructions has been published on our Wiki page in GitHub. We’ve also posted a helpful writeup on beta testing to help get you started.

If you discover any bugs during the testing process, please let us know by logging a report in GitHub.

Finally! After having been an opt-in feature for some time, the new product filtering mechanism we announced a few months ago is rolling out for everybody in WooCommerce 6.3. Here’s what you need to know as a shop administrator.

What’s going to happen after I upgrade to/install WooCommerce 6.3?

A database migration will kick in. This will create the new product attributes lookup table and will trigger a recursive scheduled action that will fill it; you can verify that this is the case by opening the WooCommerce tools page (WooCommerce – Status – Tools), you should see a new entry titled “Regenerate the product attributes lookup table” with a disabled button that displays a number:

The number indicates how many products have been processed so far (10 products are processed in each batch by default, more on that later). Note that “processed” in this context means that the appropriate entries will have been created in the new lookup table. From the point of view of the products themselves, this is a read-only process and no modifications will happen whatsoever for any product.

Once the process has finished the button will appear as enabled and its label will be “Regenerate”. But more interestingly, a new settings section will become available as well.

The new settings

Once the initial database migration has finished a new “Advanced” section will appear in the product settings tab (WooCommerce – Settings – Products – Advanced) with a couple of options related to this new feature:

“Use the product attributes lookup table for catalog filtering” instructs WooCommerce to effectively use the new lookup table for the shop catalog display and filtering, it will have been enabled automatically after the database migration finishes but you can enable and disable it at will (when disabled, the posts table will be used instead, as it was the case when the lookup table wasn’t available).

“Update the table directly upon product changes, instead of scheduling a deferred update” determines how the lookup table will be updated whenever a product is created or updated: when enabled, the update will happen immediately; otherwise, the action scheduler will do the update job some (short) time after the product is created or updated.

Important: WooCommerce will always create or update the appropriate entry in the lookup table whenever a product is created or updated, even when the “Enable table usage” setting is off. This is necessary to guarantee data consistency in all cases, regardless of whether the table usage is set on or off.

Regenerating the lookup table data

As mentioned before, once the initial database migration is completed the “Regenerate the product attributes lookup table” tool will be available. You’ll see that there’s a product selector next to it, thus you can use this tool in two ways:

• Select a product: the tool will regenerate the lookup data for only that product, immediately.
• Don’t select a product: the tool will start over the initial data migration, by first emptying the table and then fillin in within a recursive scheduled action.

Worth noting that while the full table regeneration is in progress the table usage will of course be disabled and you won’t be able to enable it via settings.

This tool is intended as an emergency mechanism only, in case there’s something wrong with the implementation of the feature and the table ends up having missing or wrong data. As a general rule, we don’t recommend using this tool unless you are instructed to do so by a WooCommerce support person.

Customizing the table (re)generation batch size

By default, when the lookup table is being filled (during the initial database migration, or when you trigger a full table regeneration via the dedicated tool) 10 products will be processed in each run of the action scheduler. This number is slow on purpose, in order to keep the performance penalty of the ongoing migration to a minimum; but it can cause the entire process to take too much time in shops with a large number of products.

This value can be customized by using the woocommerce_attribute_lookup_regeneration_step_size filter like this:

add_filter('woocommerce_attribute_lookup_regeneration_step_size', function() {
    return 100;
});

You can use the WordPress code snippets plugin to add this piece of code.

It’s worth noting that this filter can be added (or the returned value can be modified) even when the initial database migration or the manually triggered table regeneration is already running: the next action scheduler run will pick the new value and use it on all subsequent runs.