* Fix - #17413
Update the `json_search_products` function to use the
`wc_products_array_filter_visible` filter rather then the
`wc_products_array_filter_editable` filter
Added an additional if condition to the `is_visible` function to check
if the product had a parent and it's post status
* remove additional comment from code to keep it clean
* Reverted filter
* Updated the is_visable to check parent product post status using WooCommerce class methods
* Updated the `if empty` check to make it is compatible with older versions of php
* Removed the empty check infavor of just testing on the returned value
Updated the way we are retrieving the partent product object
* Moved the `$parent_product` variable assigment out of the if statement.
Commit d9f9e74bd added a check to `WC_Product::set_tax_class()` to only accept valid tax classes, but this created a bug for product variations as this type of product has an extra tax class called 'parent'.
This commit fixes this problem by adding a new method to `WC_Product` that returns a list of valid tax classes. `WC_Product_Variation` then override this method, returning another list including the tax class 'parent'.
Fixes#17024
The WC_Product::set_default_attributes function uses an array_filter (using the default callback for filtration)
to remove null and false values from the defaults array for a given product. The issue here is that, in the above use case,
the array_filter will evaluate '0' as 0 and therefore as false. Ultimately, array_filter then prevents the value from being
recorded, moving forward.
I've added a new filter callback to includes/wc-attribute-functions which will disregard all FALSE PHP equivalents except for
'0' (as a a string). Also, I've updated the filter_array call in WC_Product::set_default_attributes so that it uses this new callback,
instead of the PHP default. Finally, I've added a phpunit test to assert that, when storing default variations / attributes on a product,
the false/true PHP synonyms are evaluating and storing like one would normally expect, with the exception that (string) '0'
evaluates as true in this special case.
This solution could potentially be broadened to facililate similar rules elsewhere, but the need raised in the bug is specific and
this is a specific solution.