- this prevents the password reset process earlier (before the redirect)
- also now shows a notice informing the user that they need to log out
of (other) account
- in the checkout signup use case, the user may be setting their
password in a logged-in browser session; they need to be able to set an
initial account password
- add @since (original since based on git blame)
- document all params
- add @since for newly-added params
- add docs for woocommerce_endpoint_{$endpoint}_title
- get_endpoint_title now takes an extra `action` param
- this also is passed to the relevant hook (as an additional arg)
- woocommerce_endpoint_{$endpoint}_title
- for `lost-password?action=rp`, use `Set password`
- pass action query param through when using get_endpoint_title
After the League's Container package has been reintroduced, all the
code that implements the dependency injection mechanism in woocommerce
can be brought back as well.
In PHP 8 required parameters after optional parameters in
function/method signatures trigger a deprecation notice. These type
of parameters are pointless since a value needs to always be
provided for them anyway, so they are actually de-facto required.
This commit converts all these not-so-optional parameters into
truly required parameters by removing their default values.
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'.
In #26642 we removed adding reduced_stock meta when adding new order item to prevent ghost entries, but in inadvertently exposed an underlying bug where _reduced_stock meta was getting set to 0 if its emtpy.
We were then checking the presence of this meta, but also not reducing the stock in case it was not set.
After the code that creates term relationships for variations has been
removed, a data migration is required to remove all the no longer needed
term relationships.
Also, the original migration that backfilled those relationships has
been removed (the migration function is kept but with an empty body).
A mechanism for improved filtering by attribute for variations was
introduced some time ago. This mechanism implied maintaining term
relationships for variations, where the terms were the attributes
that defined the variation.
The mechanism was reverted because it was complex and presented many
issues, but the code that created those term relationships was kept.
This pull request removes that code and the associated unit tests.
The setup wizard is going to be deprecated in WC 4.6.0 which should be
released soon. Some functions were marked as if they were deprecated in
WC 4.5.0 which is not the case.
In an environment with persistent object caching, concurrent calls
to delete_option() + add_option() can result in the option value
leaking out of the alloptions cache key, and into its own cache
item under the options group, while deleting the value from the
database.
This causes future function calls to add_option() to fail, since
the value already exists in cache (under the wrong key). It also
causes calls to delete_option() to fail, since the value is not
in the database.
This commit forces update_option() instead of the delete + add
combination, as well as removes multiple unnecessary calls to
update the woocommerce_db_version from admin notes and notices.
This commit reverts the functionality introduced in PR #26260
(later refined by #27175, #27190, #27508) in which filtering by
attribute using the layered nav widget was improved to handle the
cases of variations out of stock. The revert is a response to the
numerous problems reported by users in Woo 4.4 and 4.5
Not all the code has been reverted, only the code that resulted in
visible functionality changes. Thus, the code that generates
term relationships for variations is still in place to keep database
consistency and to keep the reverting changes to the minimum needed.
We were doing state and postcode even for countries where its not required, but unfortunately as an unintended effect we were ending up not checking shipping requirements if this was not met.
This commit changes the order of the error handling check to protect the code against a possible fatal error if wp_safe_remote_post() returns an instance of WP_Error().
This commit fixes a bug that made it impossible to assign to a product a tax class that contained non-ASCII characters that are URL encoded by sanitize_title().
WooCommerce uses sanitize_title() to generate a slug when creating a tax class (d48f1d4e2e/includes/class-wc-tax.php (L808)). sanitize_title() converts some non-ASCII to ASCII equivalents (those handled by remove_accents()) and URL encodes others (like some Greek characters, for example).
The code was using wc_clean() to sanitize the tax class when the user edited a product. The problem is that wc_clean() removes URL encoded characters, changing the slug of some tax class, causing WooCommerce to use the standard tax class instead without any errors. To fix this issue, this commit replaces wc_clean() with sanitize_title(). This should be enough for security purposes and should not cause any issues with non-ASCII characters.
By changing to auto invoking call the `c` variable will be encapsulated in its scope therefore not polluting the global scope and will continue to function as previously.
Fixes conflict and reassigning of already used variables when using other minified scripts. In my case the problem occurred with the Speed Booster Pack plugin.
The previous query was counting variable products twice when they
had a variation with a concrete value for the attribute and also
a variation with "Any..." value for the same attribute.
The new query fixes a bug where variations were being counted twice:
if a product was included in both the queries then it would be counted
differently and added; e.g. when a product had two variations,
one with "Any" attribute and other with a attribute that has a value.
The new query also optimizes performance, so that filter conditions
can be improved and better indexes can be used.
For performance reasons the query is split in two: one for simple
products and variations with a concrete attribute value, and another
one for variations having "Any..." as the attribute value.
Previously, we were using the `$formatted_meta_data` to build the final array.
However, this does not consider the fact that
`WC_Order_Item->get_formatted_meta_data` can exclude `meta_data` from the
result. There would be less `meta_data` objects return than the previous
implementation.
This fixes the issue by using the `$data['meta_data']` value as the main list of
meta data and only using `$formatted_meta_data` to optionally apply the
`display_key` and `display_value` properties.
The new query doesn't need empty attribute entries in the meta table,
therefore the code that generates them and the migration to backfill
the missing existing ones have been removed.
When set_attributes is used on WC_Product to remove existing attributes
the wc_product_attribute_uasort_comparison ends up being called
with a null argument, and this breaks tests in PHP 7.4 since
null is used as an array. This commit modifies the function so that
if null is passed no array access is attempted.
Right now the filter by attributes widget counts available variations
(for variation products). This is confusing since the counter shows
numbers that are higher than the actual count of products displayed.
This commit changes the query used by the widget so that instead
of counting variations it returns the parent product ids, and then
counts the distinct values. This also covers the case of products
where some of the variations have concrete values and some have
"Any..." values.