Jacob Peattie

Instant Results is currently launched by submitting any form that contains an `input[name="s"]` and on submission of that form it takes the value of that input and triggers a search...

On discovery I think we can break this down and handle this task in two parts, and move decoupling Instant Results from the modal into a separate issue. The two...

Created #2978 for #2 above.

Created #2979 for decoupling Instant Results from the modal.

As discussed we probably don't want these to be consistent, since the block has uses outside of `is_single()`, so instead we can use a check for `in_the_loop() || is_singular()` so...

I went to make this change but ran into an issue. `in_the_loop()` does not return `true` inside the Query Loop block, so checking `in_the_loop()` would stop the block from appearing...

There's an open issue regarding `in_the_loop()` in the Gutenberg repo: https://github.com/WordPress/gutenberg/issues/32896 I've added a comment to hopefully revive it.

So I've done some discovery on this using the [`@wordpress/hooks`](https://github.com/WordPress/gutenberg/blob/767081132e1f2be43fd660e946c776e1dd2eea80/packages/hooks/README.md) package and it looks promising. The hooks package itself is only a 5kb dependency, loaded in the footer, and its...

Hi @JiveDig, the reason Instant Results can be so Instant is that it bypasses WordPress and PHP altogether, so unfortunately the components used by Instant Results will only be modifiable...

The specific use case of limiting autosuggest results to a particular post type is addressed by #1689