With PHP 8.0, non-strict comparisons between integers and strings containing
non-numeric characters are being tightened. This affects comparisons like:
0 < '0000-00-00 00:00:00'
PHP 8.0 that equates to true whereas prior to 8.0 it would be false.
More details of this change can be found at: https://wiki.php.net/rfc/string_to_number_comparison
There's a number of places in the WooCommerce codebase where the
built-in function 'round' is executed passing a non-numeric value
(not a number and not a string that can be parsed as a number),
for example round(''). In PHP 7 this yields a value of 0, but in
PHP 8 this throws an error.
This commit adds a 'NumberUtil' class with a static 'round' method,
this method checks if the passed value is numeric and if so it just
executes the built-in function, otherwise it returns 0. And all the
calls to 'round' in the codebase are replaced with 'NumberUtil::round'.
Modify the increment and decrement SQL query in
WC_Product_Data_Store_CPT::update_product_stock to be atomic. This fixes
a race condition in concurrent order placement.
When searched in a case sensitive manner, the conversion to lowercase causes uppercase matches that would have been found to be lost. This change increases the tolerance of the OR search format while also removing this unintended side-effect.
When creating an order, if manage inventory is enabled then add a `_held_for_checkout` record with a expiry timestamp embedded. This is added in an atomic manner along with making a check whether we have current stock or not.
This record is removed when order status goes to either `processing` or `completed`.
Fix variation query to prevent the order by being ignored in some mysql
and mariadb versions. The order by has been moved outside and a left
join was added.
NOWAIT is not supported on MySQL server 5.5,
SELECT ... FOR UPDATE can leave lingering locks on InnoDB ("When InnoDB performs a complete rollback of a transaction, all locks set by the transaction are released. However, if just a single SQL statement is rolled back as a result of an error, some of the locks set by the statement may be preserved. This happens because InnoDB stores row locks in a format such that it cannot know afterward which lock was set by which statement.", via https://dev.mysql.com/doc/refman/5.5/en/innodb-deadlock-detection.html)
E.g. if manage_stock property has been changed in the object/local copy of the product while updating it, but the product has not been saved to the db yet, the lookup table update would ignore stock quantity update.
James Allan
Nestor Soriano
Ramon
Christopher Allford
Claudio Sanches
Vedanshu Jain
Mike Jolley
Gennady Kovshenin
Rodrigo Primo
Peter Fabian
Gerhard
rspublishing
oscargare
Ionut Calara