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.
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.
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).
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.
WordPress Coding Standard 2.0 removed the sniff
WordPress.Security.NonceVerification.NoNonceVerification:
```
The WordPress.Security.NonceVerification sniff used the same error code for both an error as well as a warning.
The old error code NoNonceVerification is no longer used.
The error now uses the Missing error code, while the warning now uses the Recommended error code.
```
(from
d45f5e5cf3/CHANGELOG.md (200-rc1---2018-12-31))
This commit updates WooCommerce code and replaces all instances where WordPress.Security.NonceVerification.NoNonceVerification verification was used with either WordPress.Security.NonceVerification.Missing or
WordPress.Security.NonceVerification.Recommended. In a few cases WordPress.Security.NonceVerification.NoNonceVerification was used but was not needed, so instead of replacing the sniff, the line was removed. In two other cases, I removed other unrelated sniffs that were not needed.
Filter woocommerce_get_catalog_ordering_args has only one single argument $args, anyone filter this needs to detect the $orderby and $order value again which is already coded in the method where this filter returns. I hope adding two extra param $orderby and $order will make developer's life easier to hook this filter.
The algorithm to add a list of product categories to the query that order products of a given category by price was including only first level sub-categories since PR #20391. This was happening because `get_terms()` when called with the argument `parent` will only return direct children. To fix this and get all children for a given product category, it was necessary to replace `parent` with the argument `child_of`. See #20554 for a more detailed description of the issue that this commit fixes.
This commits improves the performance of the method WC_Query::get_layered_nav_chosen_attributes() when a site has a significant number of product attributes. Instead of looping over all existent product attributes to find which have been passed in the request, the new code loops over all the request parameters and checks which are valid product attributes.
On a test site with 2000 product attributes, the old version of WC_Query::get_layered_nav_chosen_attributes() was responsible for 25% of the shop page generation time. With the new version, the amount that this method contributes to the page generation time is negligible.
Related #20262
Nestor Soriano
Rodrigo Primo
vedanshujain
xristos3490
Ron Rennick
Kevin Ruscoe
Nathan Dawson
Claudio Sanches
Mike Jolley
Sabuj Kundu
David Garcia Watkins
Stanislav Mazur