The order is optional and must be passed as an "order" key in "$args".
If present, the order customer will be passed to "WC_Tax::get_rates"
in order to calculate the taxes to substract (provided that
"$product->is_taxable() && wc_prices_include_tax()")
Also "WC_Abstract_Order->add_product" and "WC_AJAX::maybe_add_order_item"
are modified to pass the order being processed so that ultimately
"wc_get_price_excluding_tax" uses it.
This prevents the base tax location to be wrongly used instead of the
customer location when the "woocommerce_adjust_non_base_location_prices"
hook is set to return false.
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.
This method will prioritize getting rates from billing/shipping address instead of `WC()->customer` which in irrevelant in context of editing order from admin screen.
We were not passing tax location while computing discount in orders, hence it was defaulting to shop's base address resulting in incorrect tax calculation.
This commit refactors `get_rates` method into another method that allows getting rates from location directly.
Primary reason for dropping the cache hydration is that seems like we can acheive the same results without it, so no need to add this additional complexity to our code.
This commit breaks down `read_meta_data` so that individual methods for cache key and setting raw meta data can be reused.
Also adds set_meta_data_from_raw_data to initialize metadata from manual cache.
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'.
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.
We round in `get_subtotal` because its a front-end method. If more precision is required then `get_cart_subtotal_for_order` needs to be called. Also use same `get_cart_subtotal_for_order` method here as well for consistency.
Nestor Soriano
Michael P. Pfeiffer
Claudio Sanches
James Allan
Saggre
Mário Valney
roykho
Gregory Karpinsky
Viktor Szépe
vedanshujain
Nestor Soriano
Kathy Daring
Daniel Morell
Peter Fabian
Rodrigo Primo