Lookup entries for a product or a variation are created whenever
the product is created, including untrashing and duplication
(not yet when an existing product is modified).
The 'save' method in WC_Product_Variable was almost identical
to the parent method in WC_Product, only adding a few bits
of extra processing before and after the actual datastore save.
This commit adds a couple of protected methods,
before_data_store_save_or_update and after_data_store_save_or_update,
and implements them in WC_Product_Variable so that the extra
'save' method in WC_Product_Variable can be removed.
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.
Right now, when a product having a parent (e.g. a variation having a
parent variable product) is saved, wc_deferred_product_sync is
executed so that product sync is performed at the end of the request.
This commit implements the same when the product is deleted.
When displaying a list of images you often want a specific class to be
attached to each image, therefore you pass through a custom class using
the attr parameter. Unfortunately this doesn't get passed through to a
placeholder image should one be needed. This means that, for example, if
you're custom class center an image or something, it won't be honoured
for placeholders, which can lead to some wonky image listings.
You can work around this currently by leverging the
`woocommerce_product_get_image` filter, but it's a bit gnarly as you
need to do some regexing or string splitting or something and checking
class names and what not. This provides a much easier way, by
supporting custom attrs on placeholder images as is the case for non
placehodler images.
The reason to remove this is that this function uses get_post() under
the hood which always assumes the attachment is on the same site, where
as if you're using a plugin such as
https://github.com/humanmade/network-media-library it might not be.
I'm not sure if there's any adverse affects of not doing this filtering,
from my testing, it still seems to work in the same way.
This commit fixes a issue that was introduced when WC_Product::get_image() was refactored in 64b589f032 that was making this method ignore what was passed in the $attr parameter.