Properly handle product filtering query vars when front page is ‘shop’ #36224
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
the
plugin: woocommerce
Contributor
Test Results SummaryCommit SHA: a5a2743
To view the full API test report, click here. To view the full E2E test report, click here. To view all test reports, visit the WooCommerce Test Reports Dashboard. |
Member
Author
|
Something I wanted to add is that due to this weird WP behavior, any query var might break things on the front page, so it's not exclusive of product filters. For example, activating the following snippet on a site breaks the front page if you pass add_filter( 'query_vars', function( $vars ) {
$vars[] = 'mysuperarg';
return $vars;
} ); |
vedanshujain
approved these changes
Dec 30, 2022
5 tasks
Member
Author
|
Hey @vedanshujain! Per our discussion, could we merge this soon-ish? There have been other reports of this. Even if this fix isn't 100% future-proof, it should cover what the filter blocks support now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
All Submissions:
Changes proposed in this Pull Request:
Since 7.1, the version of
woocommerce-blocksbundled with WC, is registering query vars associated to product filters (sayfilter_colororfilter_size) as proper WP query vars for their filters.When a product filter is in use, those
$_GETparams become query vars in the main query, which isn't a problem most of the time, but it is when the "shop" page is also the home page. That's because WP assumes the home page can only have certain query vars active. Otherwise, the request is not considered a 'page' request and it's instead marked withis_home = true(which is incorrect in this case). This in turn breaks our code inWC_Querywhich handles this scenario. The result is that the filters don't work and you get a weird posts page instead of products.This PR permits
WC_Queryto "correct" the main query (by correctly settingis_home,is_page,page_id, etc.) when product filter query vars are in use.Closes #35983.
For discussion
The PR assumes we only want a few variables to be considered 'valid' variables on the front page, following what WP does. That said, this approach isn't flexible, as exemplified by breakage resulting from WC Blocks adding a few query vars. An alternative would be to just allow any query vars on this page (which would be even easier at the code level), but then this could possibly break other code too.
How to test the changes in this Pull Request:
trunk, filtering doesn't work.