This creates a tradeoff in optimizing repeated queries vs on off queries.
Another tradeoff is making more cache get calls as opposed to more SQL calls.
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.
A potential fix for #26851
This does change the get_next functionality slightly but if the hook is
already running then the next state should trigger a new one anyway.
Removing the potential undesired retrieval of hundreds or thousands of unreadable WC_Product objects into memory just to filter them out immediately.
This change prevented some out-of-memory situations in our site.
With PHP 8.0, non-strict comparisons between integers and strings containing
non-numeric characters are being tightened. This affects comparisons like:
0 < '0000-00-00 00:00:00'
PHP 8.0 that equates to true whereas prior to 8.0 it would be false.
More details of this change can be found at: https://wiki.php.net/rfc/string_to_number_comparison
`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).
Using the WPCS native whitelist comments is deprecated. So this PR just replaces all instances of `// WPCS: XSS ok.` found in `includes/wc-cart-functions.php` with the PHPCS native "// phpcs:ignore WordPress.Security.EscapeOutput.OutputNotEscaped". I found this while working on another issue in the same file.
This commit improves the i18n of a string displayed during checkout showing the total amount of the order when the store is configured to display prices inclusive of taxes.
Before string concatenation was used to build the final string which is almost always a bad practice from i18n point of view (https://codex.wordpress.org/I18n_for_WordPress_Developers#Best_Practices). This commit uses sprintf() and two separate strings to make translation easier.
This commit replaces a call to the now deprecated jQuery.fn.toggle(handler, handler...) (https://api.jquery.com/toggle-event/) with a jQuery.click(). The deprecated call was used in the page where admins can edit e-mail templates (example: wp-admin/admin.php?page=wc-settings&tab=email§ion=wc_email_customer_on_hold_order) to show or hide the contents of the template and at the same time change the label of the button. We are now using jQuery.click() with a if statement inside to decide which label to use.
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.
- 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 will introduce two new filters:
woocommerce_from_product_type_changed
woocommerce_to_product_type_changed
to filter the $from and $to variables respectively.
This will be useful in WCS pr_3732!
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.
Implements the following expected behaviour:
1. Switch from variable subscription to non-variable one will delete variations.
2. Switch from variable subscription to variable product and vice-versa will NOT delete any variations.
This shall have no side-effects in WooCommerce Core.
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.
When "Create variations from all attributes" is used to create
variations it generates term relationship entries for all the generated
variations, however that doesn't happen when the term can be interpreted
as a numeric value. This is because in that case product->get_attributes
returns the attribute values as numbers, but the code that generates
the term relationships expect those to always be strings.
When manually adding a given variation this doesn't happen.
The fix is to simply strval-ize the value before using it, but it might
be worth investigating why this is happening.
The previous commit fixes a bug that causes the "attribute_" metadata
with an empty value to not be created when a new variation attribute
is added to the product (so that all variations have the attribute
with a value of "Any..."). This commit adds a data migration to
backfill the missing metadata for existing variations.
When a new variation attribute is added, the corresponding 'attribute_'
meta entries are added for all variations with an empty value;
and when an existing variation attribute is removed, the existing
'attribute_' meta entries are deleted for all variations.
This is necessary for the filter by attribute widget to work properly
when variations exist with a value of "Any..." for attributes.
When a variation product has an attribute with a value of "Any...",
and there's a filter by attribute widget for that attribute, then
that product won't be included in the counts displayed in the widget
(and if the count ends up being zero, the attribute won't be shown
in the widget).
This happens before since Woo 4.4, this widget works by looking at
entries in the term relationships table for varitions too
(used to do so for simple products and for "main" variable products
only), see PR #26260; but there are no such entries for
"Any..." attributes.
This commit fixes that by extending the SQL query used by the widget
to look for variations that have empty attribute values in the meta
table too.
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
This bug was introduced in #26260. The sequence is:
1. WC_Query::adjust_posts_count runs, to handle found_posts filter,
this indirectly executes wc_setup_loop.
2. At this point $GLOBALS['wp_query']->max_num_pages hasn't been set
yet, and has a value of 0. Thus the loop variable total_pages
is set to 0.
3. Later wc_setup_loop runs again and this time
$GLOBALS['wp_query']->max_num_pages is already set, but since
the loop variable total_pages already exists, it keeps its
value of 0.
4. The pagination controls never show if total_pages is less than 2.
The fix consists of hooking into the_posts to set the value of
total_pages again, at that point $GLOBALS['wp_query']->max_num_pages
is already set.
PR #26260 introduced a handler for 'found_posts' filter in WC_Query
class in order to adjust the count depending on the visibility
of variation products. However the handler incorrectly assumed
that the filter was triggered only when listing products, when
actually it's also triggered for any post type e.g. pages.
In these cases the post count was set to zero, which caused bugs.
Now the handler starts with the originally supplied posts count,
and only decrements it when a post is a product AND is not visible.
- Fix a call to get_available_variations with incorrect optional arguments.
- Add code that has been removed in WC_Product_Variable::get_available_variations.
Now, if there are filters present the logic is as follows:
- For multiple filtering values of the same attribute:
the product is visible if there's at least one variation
that has one of the filtering values associated to the attribute,
or if there's at least one variation having the attribute
with a value of "Any".
- For filtering by more than one attribute:
the product is visible if there's at least one variation that
is visible for ALL the attributes according to the above rule.
Note that this is irrespective of the type of logic configured for
the filter (OR or AND).
Two adjustments were needed:
- Adjust the count even when there's no nav filtering in the query.
This is necessary to present the proper products count.
even when the woocommerce_product_is_visible filter is used.
- Account for the case where $GLOBALS['wp_query']->posts
returns objects instead of ids (for example when viewing
a product page).
After the change that registers variation attributes as terms
(in addition to reigstering them as post meta) it is now time
to modify the get_filtered_term_product_counts methods in
WC_Widget_Layered_Nav so that it works consistently for both
variable and non-variable products. The logic for the counters
is now as follows:
with OR operator:
- Simple products: count the attributes of all visible products
(unchanged behavior).
- Variable products: count attributes corresponding to
visible variations.
with AND operator:
- Simple products: count the attributes of visible products but only
for products that have all the selected (unchanged behavior).
- Variable products: find all the products for which all the variations
corresponding to the selected attributes exist and are visible,
then count the attributes corresponding to the visible variations
of those products.
A product is "visible" if it's published, not excluded for catalog,
and has stock. Additionally, a variable product will not be considered
visible if the parent product is not.
Product attributes are currently recorded as terms in
wp_term_relationships (product attributes are actually taxonomies).
In the case of variable products this is true for the main product,
but not for the variations. The attributes used to define variations
are stored as post meta, but nothing is recorded in the term
relationships table.
This is a problem when using the layered nav filtering plugin,
since the attribute counters displayed are calculated based solely
on the contents of the term relationships table. Adding meta queries
would be really messy (especially when the widget is configured
with AND operator) and would probably also hurt performance.
This commit adds a change to store the attributes for variations
as term relationships, additionally to storing them as post meta.
Terms are stored on variation creation, and updated/deleted together
with the variation as appropriate. "Any" variations (stored in meta
as empty values) are not stored as terms.
Additionally, a database upgrade is included in order to backfill
terms for already existing products.
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.
Using WooCommerce on a multisite network using the hyperdb drop-in, the foreign key check fails although there is a foreign key.
32037e37dd/includes/class-wc-install.php (L745-L763)
The first problem is that hyperdb wasn't designed to route `information_schema` queries. After patching hyperdb, the query is routed to the correct database.
The second problem is that the query still finds zero foreign keys because `$wpdb->dbname` is blank when the query is generated. Hyperdb only has a dbname in the context of a query being executed; hyperdb extracts the table name, then maps that to the correct database.
Although we could find a way to support such `information_schema` queries, they are also not preferred because they are notoriously slow. On WordPress.com they take 300ms, versus 3ms for a `SHOW CREATE TABLE` which similarly reveals the existence of the foreign key.
The proposed changes simplify the check, make it faster, and make it work with hyperdb.
This makes match with WP sanitization for post_title.
WP sanitize post_title using kses_init_filters() when
the current user can't use unfiltered HTML.
It is possible for a later duplicate webhook to be fired too early if
the same webhook triggers in one request more than once with the updated
changes from the second one missing if it happens too quickly.
This queues all webhook to be register on shutdown instead of just
syncronous ones to make sure all data from the request is updated first
before the webhook gets queued.
`wc_round_tax_total` is for when prices are inclusive of taxes, however, shipping taxes can never include taxes so they should always use `round( $price, wc_price_get_decimals() )` instead.
When rounding at subtotal is enabled, line items are already rounded where they need to, so we only should do any further rounding when displaying values and no where else.
This is part of our larger attempt to remove individual rounding as much as possible.
- src/README.md largely expanded
- tests/README.md expanded
- includes/README.md added
- src/Internal/REAMDE.md added
src/README.md and includes/README.md have TODO placeholders to add
guidelines regarding to actions and filters.
The following methods are added and can be invoked using `WC()`,
they just redirect to the same methods in LegacyProxy:
call_function
call_static
get_instance_of
- Method and class renames.
- Removed unnecessary autoloader registration.
- Add a unit test for classes with non-object type hints
in constructor arguments.
- The `Container` class now implements `Psr\Container\ContainerInterface`
(and registers itself as such), holding a private instance of the
real container. This way it's a read-only container from the point
of view of plugins (which should use their own containers, but
can still use this to get WooCommerce classes).
- All registrations are now done in the `Container` constructor via
service providers.
- The container instance is now held in a global variable, set in
`woocommerce.php`
- Added the `wc_get_container` function for old code.
- Added the `AbstractServiceProvider` class, which inherits with the
corresponding League's class and adds some utility methods,
most notably `add/shareWithAutoArguments`.
- Added the `ActionsProxy` and `LegacyProxy` classes, they are
registered via a dedicated service provider.
- `WC_Queue_Interface` is no longer resolvable via the container
(which is for classes inside `src` only).
- All the method names in the new classes have the format `fooBarFizz`
to be PSR4 compliant, so the MethodNameInvalid error has been
disabled in phpcs.xml for the `src` directory.
- Introduced the `@public` annotation for public API classes
(classes that plugins can use and whose backwards compatibility
we guarantee), applied to `ActionsProxy` and to `LegacyProxy` for now.
- Removed the hack for the autoloader as now it doesn't work anyway.
For the changes in this branch to work, now WP_DEBUG must be false.
- Renamed from `ObjectContainer` to `Container`.
- It now inherits from PHP League's `Container`.
- It has now a `defineAsSharedAutowired` method.
- Initialization moved to the `WooCommerce::init_container` method.
- The static method for object resolution is now `WooCommerce::get_instance_of`.
- Add PHP League's Container package via Composer.
- Add an ObjectContainer class that encapsulates all the configuration
and insulates the codebase from the concrete DI engine used.
- Add an improved ReflectionContainer class that will allow to
register individual classes as singletons while autowiring.
- Use ObjectContainer to resolve the WooCommerce class, everything
instantiated with "new" inside it, and all singletons that are
usually obtained via WC() function.
- Introduce the CustomerProvider class.
- Introduce a service provider to resolve WC_Queue_Interface,
this replaces the WC_Queue class.
- Mark as obsolete all the replaced "instance()" methods,
and the entire WC_Queue class.
Tom Hopcraft
Gerhard Potgieter
Roy Ho
vedanshujain
Christopher Allford
Néstor Soriano
Matt Harrison
David Marín
James Allan
jozeflambrecht
Rodrigo Primo
Shiki
Claudio Sanches
pjv
Peter Fabian
Shahlin Ibrahim
Nicholas Macedo
Ron Rennick
Rua Haszard
sudoshreyansh
Jon Campbell
James Collins
Dominic Vermeulen-Smith
Knyazevich
rowayda_khayri
Jonathan Sadowski
Joshua Flowers
Mateusz Gbiorczyk
Milana Cap
Alex Stewart
Dion Hulse
Konstantin Kovshenin
And Finally
mahmoudsaeed
Grzegorz Rola
Anton Timmermans
Omkar Bhagat
jonathansadowski
Martin Adamko
KoolPal
Julià Mestieri
Kathy Daring
Romario
Brent Shepherd
Arkadiy Asuratov
Hayden Whiteman
Daniel Morell
Ramon
George Jipa
Filipe Correa
GREYS
Andy Skelton
Albert Juhé Lluveras
xristos3490
Joel Rowley
budzanowski
Damir Ha
Mike Dent
Brian