`WC_Admin_Dashboard::recent_reviews()` was calling `get_avatar()` passing `$comment->comment_author` which is not one of the list of parameters that the function accepts to get the avatar. As a result, the widget that displays the recent reviews in the admin dashboard was never displaying the avatar of the user that left the review. This commit fixes this issue by passing `$comment->comment_email` instead. I opted to use `$comment->comment_author` as it should be available for reviews left both by authenticated and anonymous users and because getting the comment object wouldn't be so simple (either we need to perform an extra query for each review or deprecate the `woocommerce_report_recent_reviews_query_from` filter).
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.
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 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.
Previously 'dirname( __FILE__ )' was used to import files, however, the directory separator was missing.
This commit replaces 'dirname( __FILE__ )' that was introduced in 5370d02484 with __DIR__ and added DIRECTORY_SEPARATOR
Relative include paths in PHP can break whenever the server is running opcache. As such, WordPress.com deploy system refuses to include WooCommerce because of that issue.
This commit changes the relative include paths to absolute include paths.
Relates to #27269
At some point the 'change_stock' key is assumed to be present
in the request data, but it might not. Fixed to test for existence
before using the value.
Create a new `request_data` method in WC_Admin_Post_Types that
just returns $_REQUEST. This is intended to ease unit testing,
as this method can be easily mocked to return test data.
For bulk edit: even if stock status was left as "No change", the
status of all variations was being changed to whatever the status
of the product was before it was converted to variable. Now
no change is performed when "No change" is selected, and all
variations change to whatever is selected otherwise.
For quick edit: a new "No change" option is added that will be
preselected when the product is variable. Previously, whatever
status the product had before being converted to variable was being
shown, and that's the status that would be set when saving.
Also, a "This will change the stock status of all variations"
message is displayed before the selector.
Two methods have been created:
- update_stock_status, replaces code that was duplicated in the
quick_edit_save and bulk_edit_save methods.
- set_new_price, replaces code that was duplicated-ish in the
bulk_edit_save for setting the new regular and sales prices
(code was not identical but very similar).
Also, `round` is now used on sale price calculations that involve
multiplying by a percent, the same was as it was done already
to calculate the regular price.
With the increased cadence of releases it becomes necessary that we address the `WC tested up to` header's usefulness. It isn't practical to require everyone to update their extensions every month, especially given that we are only doing backwards compatible minor releases. The only case I can think of where we might want to check the minor version is if the Stable tag on Core is downgraded, but due to the naming of the header, this doesn't make any sense.
I considered making this a wildcard of some kind but I think most would bind to a full major version anyway and so this isn't worth the time to add it. As an aside, the tests in `plugin-updates.php` seem to indicate that a header of `WC tested up to: 4` would apply to the entire major version cycle, so wildcards already exist!
Optionally, also adds a notice in case all db tables are not present. Returns list of tables.
Note that we only check missing tables and don't care about exact table structure because many time tables are modified by merchants to better suit their needs (indexes, collations etc).
Since we were converting the field to lowercase we ended up inserting meta in all lowercase, regardless of what it was in the CSV file. We should only be using the normalized field name when looking at the default columns, and should instead rely on a case-insensitive regex for the special columns.
One thing to note is that we're still defaulting the $headers array to the normalized field, as we don't want to change what is being passed to the filter for unmapped columns.
* Merge wc api authorization headers with given headers
* Add put method to WC_Helper_API
* Add unit test coverage around WC_Helper_API request methods
* Add tests for WC_Helper_API url method
WC headers are added in filter `extra_plugin_headers`, however, in case when WooCommerce is activated/updated, `get_plugins` will be called and cache will be set before this filter can be cached.
Also, `get_plugins` call is expensive even with update cache present, so we should clear it very conservatively.
This commit changes the string that is displayed to the users in the system status report page when an old version of a WC extension is installed and it doesn't declare support for the current WC core version.
The original message was:
"WooCommerce Min/Max Quantities - by WooCommerce - 2.4.11 - 2.4.12 is available - Not tested with the active version of WooCommerce"
The new message is:
"WooCommerce Min/Max Quantities - by WooCommerce - 2.4.11 - This version is not tested with the active version of WooCommerce (update is available)"
The problem with the original message is that it gives users the impression that even the newest version (2.4.12 in the example above) is not tested with the active version of WooCommerce.
The documentation of the method
WC_Plugin_Updates::get_untested_plugins() said that it only considers
active plugins when getting the list of untested plugins, but it
actually considers all installed plugins. This commit simply updates the
documentation to reflect the method behavior.
This commit creates a new method called
WC_Admin_Status::output_plugins_info() that is used to display the
plugins that are installed on the site in the system status report page.
It is used to display both the active and inactive plugins sections and
it was created to remove code duplication.
I don't think that adding this code as a method to WC_Admin_Status is
an ideal solution but it is the best that I could think and it is better
than duplicating code. Suggestions of other places are welcome.
Kudos to @kadimi who is the original author of this change (see #24623).
I'm doing this commit as we were not able to merge their PR due to a
conflict and we were also not able to cherry-pick their commit as GitHub
is reporting that the PR was created from a unknown repository.
The check now also tests whether wc admin is active to prevent notice about undefined constant when running on WP 5.2 and older, or with inactive WC Admin.
We still had an education tab there, but we have no active agreements with any of the recommended resources. I think we can just delete thme from core.
The Help & Support tab didn't correspond in terminology to what we're using on WooCommerce.com. Notable changes:
* "Helpdesk" --> "WooCommerce.com Support"
* URL for getting help on WooCommerce.com updated
* More active voice in instructions