Search Block - ability to specify additional search query vars

[tomasztunik]

What?

Add ability to control search query vars of the core/search block.

Fixes #40583

Why?

This will enable creating core/search block variations that can limit their search results based on query vars provided. Ie. searching only among post_type=product for WooCommerce or searching only through a particular category of posts, or a particular author on a WordPress page.

How?

Adds query attribute to core/search block and renders hidden inputs in the search block with provided query vars and values.

Testing Instructions

1. register new core/search block variation with query attributes

ie. to search only for pages specify post_type: 'page' if WooCommerce is available one could use post_type: 'product' - it is possible to use all public query vars and also custom taxonomies where custom taxonomy name slug is query key and value will be a slug representing custom taxonomy entry.

registerBlockVariation( 'core/search', {
   name: 'test/custom-search',
   title: 'Test Search Block',
   category: 'test',
   attributes: {
      query: {
         post_type: 'page'
      }
   }
} );

2. Add Test Search Block with inserter
3. Test search and confirm that post_type query parameter is included in browser address bar and that results are limited to given query.

Screenshots or screencast

[tomasztunik]

Some questions/ideas I have here.

• Should we allow providing raw query param names as query object keys or should we enter them as camelCase and convert them to snake_case when creating inputs? Thinking if this could possibly be problematic with custom taxonomies or some custom slug names.
• Should we provide any defaults? we could provide null values for empty to expose suggested values for query vars and then don't render inputs if there is no value provided. Thinking if this wouldn't pollute the comment strings for block instances on pages/posts/templates.

[tomasztunik]

Just FYI - opened PR to @types/wordpress__blocks to include variations registration API which is required to make the best out of this feature before we introduce the UI (DefinitelyTyped/DefinitelyTyped#60059)

[Mamaduka]

Hi, @tomasztunik

Sorry if I'm missing something, but what's the reason for outputting hidden inputs in the editor?

[tomasztunik]

Added for consistency in the DOM between the editor/front-end but can be easily removed if we don't see a reason for them to be here.

[Mamaduka]

Thanks for the explanation, @tomasztunik 🙇

The hidden inputs shouldn't affect anything visually; they also serve no purpose in the editor besides consistency. So it's probably safe to remove.

[tomasztunik]

I had something ringing the bell but double checked and they are completely ignored in rendering, for CSS selectors etc. Will remove them 👍

[adamziel]

In a follow-up PR it could be worth exploring editor controls for this.

[tomasztunik]

Agreed, in the issue I've shared my findings that there already is query-controls component but as mentioned there:

it's not really that generic or doesn't provide freedom as to which options we want to expose nor a simple way to provide autocomplete for custom taxonomies etc.

Having this first would enable us to create variations already and allow more time for the interface to mature at its own pace

[Mamaduka]

Having this first would enable us to create variations already and allow more time for the interface to mature at its own pace.

Good point 👍

[Mamaduka]

This looks good to me 👍 Thanks, @tomasztunik!

[tomasztunik]

@Mamaduka and @adamziel - thanks for the quick review 🙇

[mburridge]

Added Needs Dev Note label in case this needs a dev note for 6.1 release.