After the change that registers variation attributes as terms
(in addition to reigstering them as post meta) it is now time
to modify the get_filtered_term_product_counts methods in
WC_Widget_Layered_Nav so that it works consistently for both
variable and non-variable products. The logic for the counters
is now as follows:
with OR operator:
- Simple products: count the attributes of all visible products
(unchanged behavior).
- Variable products: count attributes corresponding to
visible variations.
with AND operator:
- Simple products: count the attributes of visible products but only
for products that have all the selected (unchanged behavior).
- Variable products: find all the products for which all the variations
corresponding to the selected attributes exist and are visible,
then count the attributes corresponding to the visible variations
of those products.
A product is "visible" if it's published, not excluded for catalog,
and has stock. Additionally, a variable product will not be considered
visible if the parent product is not.
Product attributes are currently recorded as terms in
wp_term_relationships (product attributes are actually taxonomies).
In the case of variable products this is true for the main product,
but not for the variations. The attributes used to define variations
are stored as post meta, but nothing is recorded in the term
relationships table.
This is a problem when using the layered nav filtering plugin,
since the attribute counters displayed are calculated based solely
on the contents of the term relationships table. Adding meta queries
would be really messy (especially when the widget is configured
with AND operator) and would probably also hurt performance.
This commit adds a change to store the attributes for variations
as term relationships, additionally to storing them as post meta.
Terms are stored on variation creation, and updated/deleted together
with the variation as appropriate. "Any" variations (stored in meta
as empty values) are not stored as terms.
Additionally, a database upgrade is included in order to backfill
terms for already existing products.
At some point the 'change_stock' key is assumed to be present
in the request data, but it might not. Fixed to test for existence
before using the value.
The test added checks that stock status of variations when saving
a variable product is changed or not appropriately depending on
the request data supplied.
* Merge wc api authorization headers with given headers
* Add put method to WC_Helper_API
* Add unit test coverage around WC_Helper_API request methods
* Add tests for WC_Helper_API url method
Initially it was made more precise to avoid calculating estimates for incomplete addresses. Due to some bad working in template files though, as well as historical precedent, we need to change it back.
Instead of comparing all tables that exist with all tables that are registered with `WC_Install::get_tables()` (which was only introduced a few versions ago in #19436), rewrite the test to verify that all of the tables *registered* actually exist within the database.
This will prevent tests from failing when, for example, they're run against databases that may or may not have additional plugins installed/activated. This also prevents tests from failing when running WooCommerce 4.x (e.g. with WooCommerce Admin) on WordPress < 5.3, since the tables are created but the callback to register the custom tables is never hooked.
Claudio Sanches
Nestor Soriano
Christopher Allford
Joshua T Flowers
Vedanshu Jain
Nestor Soriano
Mike Jolley
Steve Grunwell
Peter Fabian
Ron Rennick