-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Search and Query blocks: Add support for Default queries via pre_get_posts
filter
#67289
base: feature/search-query-using-vars-filter
Are you sure you want to change the base?
Search and Query blocks: Add support for Default queries via pre_get_posts
filter
#67289
Conversation
pre_get_posts
filterpre_get_posts
filter
e254cff
to
5846998
Compare
80eef6d
to
d83ec89
Compare
Size Change: +109 B (+0.01%) Total Size: 1.84 MB
ℹ️ View Unchanged
|
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;
}
//...
} |
e6c243e
to
aed9a78
Compare
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. |
…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.
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 |
What?
This adds support for Default queries via
pre_get_posts
filter.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.