Search and Query blocks: Add support for Default queries via pre_get_posts filter
#67289
+532
−29
Conversation
This file contains 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
michalczaplinski
added
[Block] Search
michalczaplinski
changed the title
pre_get_posts filterpre_get_posts filter
michalczaplinski
force-pushed
the
feature/search-query-using-vars-filter
branch
from
e254cff to
5846998
Compare
michalczaplinski
force-pushed
the
feature/instant-search-default-query
branch
from
80eef6d to
d83ec89
Compare
|
Size Change: +109 B (+0.01%) Total Size: 1.84 MB
ℹ️ View Unchanged
|
40 tasks
michalczaplinski
force-pushed
the
feature/instant-search-default-query
branch
from
748e769 to
f4a6644
Compare
|
I've tried to get the canonical URL of the requested page by using This approach was discussed previously in #63147 (comment) Unfortunately, this approach does not work well:
|
|
Can't you pass the post ID manually? |
|
There is no post ID when the user is on an archive page (home, categories archive, etc.). This is when I don't currently have a good idea how to overcome this but I think there should be a way to retrieve the "canonical" URL of the page for a given URL. I see that there's some related logic in |
Yeah, I'm sure there has to be a way to do so too 😄 Maybe we need different strategies for different types of content. Inside terms, something more like this? (untested) $term = get_queried_object();
if ( isset( $term->term_id ) ) {
$url = get_term_link( $term->term_id );
} |
|
ok, I think I got it to work using: // Get the canonical URL without pagination, works for archive pages
$canonical_url_no_pagination = get_pagenum_link(1);
// If we're on a singular post/page, use its permalink instead
if (is_singular()) {
$canonical_url_no_pagination = get_permalink();
} |
|
Currently working on adding support for multiple Default (inherited) queries on a single page. We'll have to assign an ID to each query, even if they are inherited. The editor automatically adds a I'm trying something like this: function gutenberg_block_core_query_add_query_id_to_context( $context, $block ) {
global $wp_query;
if ( $block['blockName'] === 'core/query' && isset( $context['queryId'] ) ) {
$wp_query->query_vars['query_id'] = $context['queryId'];
}
return $context;
}
add_filter( 'render_block_context', 'gutenberg_block_core_query_add_query_id_to_context', 10, 2 );And then read that function gutenberg_block_core_query_add_search_query_filtering( $query ) {
// ...
$query_id = $query->query_vars['query_id'];
// ...
}
add_action(
'pre_get_posts',
'gutenberg_block_core_query_add_search_query_filtering'
);but I have some doubts as to whether it's a good idea to create side-effects like this inside of a function passed to |
|
Giving it further thought, I think we don't have to support multiple Instant Search blocks by giving them separate IDs if they use the inherited query. This is also consistent with how pagination currently works for inherited queries. If I put 2 Query Loop blocks in a template that uses a Default query, both blocks are paginated simultaneously. Thus, if a template contains multiple Query + Instant Search blocks, then the search should affect all of them equally. |
That makes sense. |
|
I've added support for multiple Default queries in d1483a2. As commented above, the Default queries cannot run independently of one another - they are all "in sync". I implemented it by using a setting the search value in the state if there is a Defalt (inherited) query and using a getter in the state: // search/index.php
if ( $is_inherited ) {
wp_interactivity_state( 'core/search', array( 'search' => $search ) );
}// search/view.js
get searchGetter() {
const { isInherited, search } = getContext();
return isInherited ? state.search : search;
},Then in the // search/view.js
*updateSearch( e ) {
//...
const ctx = getContext();
if ( ctx.isInherited ) {
state.search = value;
} else {
ctx.search = value;
}
//...
} |
michalczaplinski
force-pushed
the
feature/instant-search-default-query
branch
from
e6c243e to
aed9a78
Compare
michalczaplinski
requested review from
spacedmonkey,
kevin940726 and
ajitbohra
as code owners
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
michalczaplinski
force-pushed
the
feature/instant-search-default-query
branch
from
78c032d to
4b3b2b3
Compare
|
I see an e2e test failure. I think it's spurious and this failing line should not even be there: There's no reason why the |
|
The failing e2e test case should be fixed in #68059 |
…rt and updating interactivity configuration. This change allows the search block to utilize the canonical URL when performing instant searches.
We need this in case the `updateTemplate` function throws an error if the template is not found.
michalczaplinski
force-pushed
the
feature/instant-search-default-query
branch
from
4b3b2b3 to
3c3075b
Compare
…ctor Controls and List View
|
Flaky tests detected in 67789ff. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/12402481902
|
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.
What?
This adds support for Default queries via
pre_get_postsfilter.Why?
The PR implementing the Instant Search (#67181) does not handle the Default (inherited) queries.
How?
The Default queries use the
?instant-search=<search-term>URL search param.