Methods `wc_maybe_increase_stock_levels` and `wc_maybe_reduce_stock_levels` already reduce/increase stock levels when statuses are changed, so no need to do this here.
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.
One of the problems with synchronous webhooks is that they are executed as soon as the related action is. Since we may call an action multiple times in the process of updating something, this causes only the first action to trigger the hook. This differs from asynchronous execution because in that case, the web hook will be executed after the entire request has completed.
1. Use '0000-00-00 00:00:00' instead of CURRENT_TIMESTAMP as default value to support MySQL 5.6
2. Return early if DB version is less than 430 because then it would mean that required wc_reserved_stock table might not be present.
With the increased cadence of releases it becomes necessary that we address the `WC tested up to` header's usefulness. It isn't practical to require everyone to update their extensions every month, especially given that we are only doing backwards compatible minor releases. The only case I can think of where we might want to check the minor version is if the Stable tag on Core is downgraded, but due to the naming of the header, this doesn't make any sense.
I considered making this a wildcard of some kind but I think most would bind to a full major version anyway and so this isn't worth the time to add it. As an aside, the tests in `plugin-updates.php` seem to indicate that a header of `WC tested up to: 4` would apply to the entire major version cycle, so wildcards already exist!
vedanshujain
Claudio Sanches
Peter Fabian
Néstor Soriano
Christopher Allford
Ron Rennick
Paul Sealock
jonathansadowski
Jonathan Sadowski
Julia Amosova
Dor Elidan