-
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
Query and Search blocks: support for Instant Search #63147
Query and Search blocks: support for Instant Search #63147
Conversation
👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @r-chrzan! In case you missed it, we'd love to have you join us in our Slack community. If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information. |
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 Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @rchrzan@whitelabelcoders.com, @ktmn. Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases. 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. |
Great work!! 👏👏 Let's see what's next 🙂
|
…of post-template/index.php
I was trying to test the UI, but I'm getting a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't tested the UI yet (due to this problem), but here are a few suggestions/questions 🙂
if ( $enhanced_pagination && $instant_search_enabled && ! empty( $search_query_direct ) ) { | ||
$args = array_merge( | ||
build_query_vars_from_query_block( $block, $page ), | ||
array( 's' => $search_query_direct ) | ||
); | ||
$custom_query = new WP_Query( $args ); | ||
} else { | ||
$custom_query = new WP_Query( build_query_vars_from_query_block( $block, $page ) ); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the Pagination Next block needs this change, I understand that the Pagination Previous block will also need it, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's what I had had thought initially as well but actually it won't 🙂
The Query Pagination, Next
block has to create a new query to determine if it's on the last page of the results (if it is, then the block shouldn't show anything). We have to pass the search parameter to this new query.
In Query Pagination Previous
, no such new query is created, so it just works out of the box!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just noticed an edge case:
If you navigate to a page with ?instant-search
param AND a pagination parameter like http://gutenberg.local/?instant-search-18=qwponbfv&query-18-page=2
, then the Pagination Previous
block shows up although it should not.
I'll hold on with fixing this for now though until we make a decision on whether we should go ahead with this PR or the approach in #67181 or #67013.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This appears to be a general issue with the Query Loop block as discussed with @ntsekouras. I've opened an issue in #67748
$query_args['s'] = $search_query_direct; | ||
} | ||
|
||
$query = new WP_Query( $query_args ); | ||
} | ||
|
||
if ( $query->post_count > 0 ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can include the contents of this block but hide them when there are no posts. That way, the CSS and JS of the inner blocks will be correctly loaded and the blocks will work when the user navigates to a "no results" page in the client.
We can remove this workaround if we finally improve how client-side navigation works before WP 6.8.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, nice. That's a good idea 👍
Can we add this in a follow-up PR though? I feel that it's not essential for the first version of the experimental block.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure.
Regarding this, why don't we pass the root/canonical link from the server (using iAPI's |
Oh, apologies about this. It was the very last commit that broke it. I've reverted it now (in 3dcf20f). |
…arch-blocks-support-for-instant-search
For this we could use |
Are you sure? I don't think a WordPress server can function correctly without being configured with its final hostname. I haven't seen any WordPress installation that works well if the path or parameters are changed either. It seems like Let's try it, and if people report issues when using proxys, we will look for a solution. |
I'm not 100% sure 🙂 I see that it's possible to have a dynamic
It might still work though. I'll try the approach using |
I believe that the current feedback's been addressed 🙂. Thank you all! I will close this PR in favour of #67181 as agreed in #63053 (comment). As for the following issues:
|
Thank you, Michał, and thanks also to @r-chrzan for starting this work 🙂 |
What?
Initial implementation for Instant Search using the Search and Query Loop blocks. Added as a new experiment on the Gutenberg Experiments page.
Related to #63053
output_62afd8.mp4
How does it work?
Instant Search and Query Block
Gutenberg experiment.Force Page Reload
i.e. use "enhanced pagination" in that Query block.When the Search block is inside of the Query block using "enhanced pagination", it automatically gets "updated" to an Instant Search block.
Any search input in the Instant Search block gets passed as the
?instant-search-<queryId>=<search-term>
query search param in the URL.Multiple Query + Search blocks
It's possible to have multiple Instant Search blocks in a page/post/template. In such a case, ensuring their functionality is isolated is essential. For this to work, the
queryId
is part of the param syntax:instant-search-<queryId>=<search-term>
Search button
The search block can contain a search button (in some configurations). However, when using the Instant Search functionality, the button is redundant because the list of posts updates as you type. For this reason, in the editor, when the Search block is placed inside the Query Loop block with enhanced pagination ON, the Block Controls related to the Search button are removed. The displayed name of the block (via
label
) is changed toInstant Search (Search)
.On the frontend, the Search button is also always removed for each (Instant) Search block.
output_70b3a0.mp4
Pagination
The instant search functionality respects the pagination of the Query block, which uses the
query-<queryId>-page
syntax.Limitations
Custom
query types are supported in the current experiment. TheDefault
query types are currently not supported but will be in the future version. This is prototyped already in Search and Query blocks: Add support for Default queries viapre_get_posts
filter #67289.Alternatives
render_block_context
filter #67013 - using therender_block_context
filter.query_loop_block_query_vars
filter #67181 - using thequery_loop_block_query_vars
filter.Further work
This is an initial prototype and the following features is intentionally not yet implemented:
Default
queries, including multipleDefault
queries on a single page/post/template. Those have been prototyped already in Search and Query blocks: Add support for Default queries viapre_get_posts
filter #67289.