WordPress makes use of search results templates, for example – product searches return results in a grid whereas posts typically get returned in a list.

This feature request is to provide the ability to search multiple post types at once.

Two features will be developed to achieve this:

1. Allow user to choose search results template for specific search widget and that one template will be used for all combined search results. This may look a little odd if you have posts being returned using the product search results as posts don’t have a price etc.

2. Or return search results with each template on a single page. e.g. if posts and products are selected to be searched in a widget then on results page:

150 articles found matching search string
(then show top X articles using posts template)

120 products found matching search string
(then show top X products using products template)

I still have questions in my mind about how pagination would then work – probably if they hit show more, or use pagination in the articles template then it would move to a page just showing page 2 of articles (and no products any longer). Similarly, if they clicked page 2 on the products template, it would then move to page 2 only using the products template and only showing products.

The browser back button would return the user back to the combined search results page, but if they’re on page 2 of the articles and they use the pagination button to view page 1, it would still just view page 1 of articles only (not combined).

Looking for feedback from users on this so I get it right.

Super Speedy Search latest updates have made postmeta search even faster than before, about 3 seconds against a million products.

But – 3 seconds is still quite slow, and if you remove the meta search then the SQL query is blindingly fast – negligible load on your server.

It seems in the majority of cases, users are enabling the _SKU meta item to be searched and not really using meta search for anything else. Because of this, I think there may be a sort of cheat I can implement to speed search up further.

What I’m thinking is that many stores will have a prefix or a pattern of some kind for their SKUs –

* Maybe SKUs are always a minimum length?
* Presumably SKUs are always 1 word?
* Maybe SKUs have some kind of pattern – like they always start with WPI or something similar for your store?

What I’m thinking is that I could add a pattern test to the search string to check if postmeta should be searched at all, and if the pattern test fails then skip searching postmeta.

For example, you could configure: WPI* as the pattern for your metadata searches to be activated and then if a user searches for “Dell Monitor” it would skip checking postmeta. If a user searches for WPIX1023 then it *would* search postmeta.

The idea being that this would speed up product search massively for your users who are probably mostly not entering SKUs – I’m presuming again that this addition of SKU search is actually mostly for the benefit of your site admins?

Please provide as much info as possible to help here so I can make Super Speedy Search *even* faster than it already is!

like this
https://codepen.io/csdev/pen/XbLLed

Is good for:
Mobile views, get attention, more space for informations.

Example phrases inside the search bar that the user can customize:
Search for…
… Merch
… Games
… Shirts
… the answer to life the universe and everything

The user is able to add as many words he likes.
Optional: Add formatting please

Simply a dice button to search and find random articles and/or products (depends on the settings.

Is good for:
A user can find new stuff while doom scrolling through the website.
He may find a new product to buy or interesting articles.

While typing in the search box, the ajax suggestion/search function gets fired a lot.
Own example:
Searching for a product by typing 2 words resulted in 22 requests to the following endpoint:
action=inlinesss&post_type=&searchstring=….
severely impacting the servers resources.

Possible suggestions for options:
– Add delay to await and evaluate if user stopped typing before searching
– Limit searches to A: When user stopped typing, and/or B: When a space is entered while typing (so we still get results while typing)