The WC_REST_Terms_Controller and WC_REST_Product_Attributes_V1_Controller
classes have a get_taxonomy method that gets the name of the taxonomy
to process from a taxonomy id passed in the request, but once the
taxonomy name has been obtained it's cached and sbsequently reused.
The problem is that these controller instances are reused if more than
one request is processed programmatically, and thus the taxonomy that
was cached once is always used even if the new request specifies a
different taxonomy id.
The fix consists of using a dictionary of taxonomy id - taxonomy name
instead of one single taxonomy for caching.
In the case of WC_REST_Terms_Controller there's a protected $taxonomy
property that needs to be kept for compatibility, it's now set to
the last taxonomy name that has been introduced in the dictionary.
- Allow the list of line items to be a non-associative array
where each item is identified by an "id" field
- Same for taxes inside line items, specify amount to refund in
a "refund_total" key as in the case of line items
- Allow "quantity" keys as synonyms of "qty"
Also calculate "amount" automatically if missing and when all the
line items and taxes have a valid "refund_total" key.
This commit revert some of the changes added in #27735 because wc_get_products and wc_get_orders is not fully compitable with API controller queries. Since we are close to release 4.9, its better to revert and fix them properly then rush a fix. This undones some the performance improvements we acheived in 27735, in favor of more stability, hopefully we will be able to restore this soon.
When called from V3, controller calls V2s get_product_data method, where stock_status was did not existed and was renamed. In V3 controller, we compute it based on V2 in_stock field.
We are using func_get_arg method to receive argument in a backward compatible way since we cannot modify function signature to add more params even with default params. Earlier I was hoping to use DI to create another child class with modified signature and load it depending upon where we are executing from, however since we had to revert DI, we add this workaround to unblock #27735.
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.
Vedanshu Jain
Claudio Sanches
barryhughes
Nestor Soriano
budzanowski
jonathansadowski
roykho
Shiki
Ron Rennick