This commit reverts the functionality introduced in PR #26260
(later refined by #27175, #27190, #27508) in which filtering by
attribute using the layered nav widget was improved to handle the
cases of variations out of stock. The revert is a response to the
numerous problems reported by users in Woo 4.4 and 4.5
Not all the code has been reverted, only the code that resulted in
visible functionality changes. Thus, the code that generates
term relationships for variations is still in place to keep database
consistency and to keep the reverting changes to the minimum needed.
- Fix a call to get_available_variations with incorrect optional arguments.
- Add code that has been removed in WC_Product_Variable::get_available_variations.
Now, if there are filters present the logic is as follows:
- For multiple filtering values of the same attribute:
the product is visible if there's at least one variation
that has one of the filtering values associated to the attribute,
or if there's at least one variation having the attribute
with a value of "Any".
- For filtering by more than one attribute:
the product is visible if there's at least one variation that
is visible for ALL the attributes according to the above rule.
Note that this is irrespective of the type of logic configured for
the filter (OR or AND).
The layered nav filtering doesn't work well with variable products
when some variations have stock and other don't. When a term is
selected in the widget, a variable product having no stock for
the variation corresponding to that term but having stock for
other variations will be displayed, but it shouldn't.
This commit fixes that by introducing two changes:
- A new override of "is_visible" for WC_Product_Variable that
looks at the supplied filters, compares them against the corresponding
available variations and calculates the visibility based on
the query type (OR or AND).
- A hook on the "found_posts" filter in WC_Query, that adjusts
the posts count based on the found products visibility
when there are filters available; this is needed to sync the
"displaying X posts" messages and the paging when variable
products are hidden due to stock status.
Additionally, the visibility calculated in "found_posts" is cached
as loop variables so that it isn't calculated again when actually
displaying the products.
When a product is saved its validate_props method is invoked,
and this recalculates the stock_status property based on whether
the product manages stock or not, the stock quantity, and the
value of the woocommerce_notify_no_stock_amount option.
In the case of variable products, and when stock is managed, the stock
was set to "instock" when the current stock was enough, but only
if the "stock_quantity" property was in the list of changed properties
for the object (the method in the base product class doen't check
for changed properties). This is a problem because the
wc_update_product_stock function updates stock_quantity but via direct
database modification, and thus stock_quantity isn't considered
modified. Therefore stock modifications via wc_update_product_stock
don't update stock_status on the product (e.g. when going from 0 to 1
after a refund the stock status will remain as "outofstock").
The fix consists of removing the check for changed properties since
it's not done anyway in the other cases (when stock is below the
woocommerce_notify_no_stock_amount threshold) nor in the base class.
Also, validate_props is refactored for readabiliyy, and an useless
set_stock_status() call placed right before save()
in wc_update_product_stock is removed.
If the child product doesn't have weight or dimensions, the value is not being cached correctly as a ```false``` value is being stored and it always recheck that on every page load.
### All Submissions:
* [x] Have you followed the [WooCommerce Contributing guideline](https://github.com/woocommerce/woocommerce/blob/master/.github/CONTRIBUTING.md)?
* [x] Does your code follow the [WordPress' coding standards](https://make.wordpress.org/core/handbook/best-practices/coding-standards/)?
* [x] Have you checked to ensure there aren't other open [Pull Requests](../../pulls) for the same update/change?
<!-- Mark completed items with an [x] -->
<!-- You can erase any parts of this template not applicable to your Pull Request. -->
### Changes proposed in this Pull Request:
Re-indexing `get_available_variations` method values.
Suppose you made changed with `woocommerce_available_variation` hook and skip returning some specific variation product with false value. There is `array_filter` function to filter empty values from `get_available_variations` but it keeps index which convert to js object rather then array on `single-product/add-to-cart/variable.php` template variation form `data-product_variations` attribute, and select box dropdown doesn't show. I just added `array_values` PHP function to reindex after `array_filter` function which convert to js array rather then js object before `get_available_variations` function return.
Closes # .
### How to test the changes in this Pull Request:
1. Before approving pull req just return false on a specific variation via `woocommerce_available_variation` filter.
2. Now check that variation product dropdown doesn't show. Because it needs to reindex array.
### Other information:
* [x] Have you added an explanation of what your changes do and why you'd like us to include them?
* [ ] Have you written new tests for your changes, as applicable?
* [x] Have you successfully ran tests with your changes locally?
<!-- Mark completed items with an [x] -->
### Changelog entry
> Enter a short summary of all changes on this Pull Request. This will appear in the changelog if accepted.
Nestor Soriano
Claudio Sanches
James Allan
Bogdan Arizancu
Mike Jolley
Manos Psychogyiopoulos
Ruben
Claudiu Lodromanean
Emran Ahmed
Joey
Amritansh_tact9
axelmm
Ville Viklund
Jaydeep Rami
Akeda Bagus
Brent Shepherd
Rasmus Bengtsson
Kathy Darling