• Hot
  • Top
  • New

You have ... votes left in this category for this week!

Add delay and/or wait for space for search results while typing

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:
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)


You have ... votes left in this category for this week!

Text switcher for the search bar text

like this

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


You have ... votes left in this category for this week!

Add conditional prefix or pattern match check on search string to determine in postmeta should be searched

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!


You have ... votes left in this category for this week!

Allow searching of multiple post types at once

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.


You have ... votes left in this category for this week!


Search for attributes

Search for categories as an attribute of the product
if I search for “shirts”, it will return zero results, because there is no product with that name or description. But there are many products that are part of the category “shirts”, so I would like the results to be returned also considering the category name


You have ... votes left in this category for this week!


Allow searching of tags, categories and everything else in wp_terms

I’ve had a request to allow Super Speedy Search to search wp_terms and wp_termmeta.

This would be to search Product categories, subcategories, tags and attributes – the plugin would still be searching for ‘posts/products’ (whatever custom post type) but would bring back more items that match these tags, attributes and categories.

Some work is required in order to integrate these properly into the search results. i.e. currently, search results have a ‘relevancy score’ which is v useful to show most relevant items at the top.

What I’m proposing to add is to merge any products which have tags, attributes, categories that fuzzy match the search string – if these are new products, add them in with a score of 0.5, if they already exist, add 0.5 to their current score. This will need to be tweaked until it’s working well.



You have ... votes left in this category for this week!


Add ability to search wp_postmeta and other fields

Currently Super Speedy Search can search any custom post type, but it only searches the wp_posts title and description.

I’ve had a few requests from clients to add the ability to search wp_postmeta too. Rather than searching ALL of wp_postmeta, probably there will be a list of meta_keys provided to search against?

Because this is a search of wp_postmeta, it will require a SECOND search to occur (full text indexes cannot span multiple tables). This will mean the search speed will be slightly slower.

There are two key issues to be wary of:

  1. wp_postmeta typically has 20 – 100 times more rows than wp_posts
  2. free-text indexes do not work well against short text – i.e. if wp_postmeta contains a LARGE chunk of text then this search will behave well, but if wp_postmeta is 20 characters or so then it would not work well and a different solution would be required.