- The woocommerce_custom_orders_table_enabled option can now be manually
altered even if there are orders out of sync
- Saving settings will always restart the sync process, even if one
is already in progress
- Add the woocommerce_orders_cot_and_posts_sync_step_size filter
The cached theme data has some properties that depend on WooCommerce.
This could also extend to extensions. Since we don't have a reliable way
to know if a given plugin is a WooCommerce extension, any plugin update
should flush the cache.
If someone updates their theme outside of the WordPress update process
(by manipulating files directly) the cache won't be invalidated. To deal
with that, we're setting the TTL here to 1hr.
Using _fields, we can specify a sub-property like environment.version.
In that case, we need to extract the top-level property so we known
which function to run.
Generating theme info involves reading the theme files from disk and
parsing them.
In testing, caching this data in a transient improves performance by
600ms. Since themes changes relatively infrequently, the cache hit rate
should be quite high.
We're registering the cache clean function in Server.php because
rest_api_init is too late.
The system status endpoint supports the global `_fields` query parameter
for limiting which fields are returned. That is, if you send a request
with a query string of `?_fields=environment`, only the environment
property will be returned. However, we still calculate every property.
This change ensure that we only gather the data that is necessary for
the response. Since some of this data can be somewhat slow (like reading
from the disk in the case of get_theme_info), this could have a pretty
nice performance benefit in some cases.
PNPM does not run "pre" and "post" scripts
for user-defined scripts. This commit
removed the "preuglify" script from the
beta tester plugin so that it builds correctly.
Adds the following fields to the order response object for both v2 and v3 of the WC REST API:
* is_editable
* needs_payment
* needs_processing
Some order states (different than statuses) are determined by complex logic involving other order properties, and/or they are filterable by extensions. These states are difficult to calculate in a client app whose only data source is the REST API, and thus they are best calculated on the server and added as separate properties to the API response object.
When the "products/batch" endpoint is used to create or update products,
the product attributes lookup table wasn't being updated as it's the
case of the single product endpoints.
When WooCommerce was updated from an version older than 6.2,
and before the user hit the "Update database" button, the product
attributes lookup table usage was activated but it was still empty.
This caused the search to not work, and the product filtering widget
to not appear.
roykho
Moon
jonathansadowski
Josh Betz
Alejandro López Ariza
Alex López
RJChow
Chi-Hsuan Huang
louwie17
Vedanshu Jain
Nestor Soriano
Christopher Allford
Corey McKrill
Barry Hughes