I’ve Built a Live Search Plugin for WordPress

Posted: May 05, 2014 Comments(7)

Search continues to be (in my opinion) a very much underutilized aspect of many websites. It’s not that websites are universally lacking on-site search, it’s that it usually stinks. I did what I could to improve that for WordPress sites by building SearchWP. It’s what I’ve always wanted but never found in a search solution for WordPress, and I hope it is for others as well. This isn’t an ad for SearchWP though (but if you’re interested to find out more definitely check out the site because it’s awesome </humblebrag?>).

Yet another WordPress live search plugin?

One of the most common questions I get about SearchWP is whether it supports live (AJAX) search. Given the way SearchWP was built, it can be easily set up to pair with any number of the existing live search solutions freely available for WordPress. Unfortunately the existing solutions aren’t able to fully utilize SearchWP for a few reasons. Primarily because they often have WordPress’ reserved GET variable s hardcoded, understandably so. SearchWP picks up on that and bases it’s entire hijacking of search results on that taking place. SearchWP, however, allows you to set up any number of search engines, but with hard coded variables you aren’t able to easily utilize them in these plugins.

That basic need had me convinced I need to (at the very least) provide a live search solution for users of SearchWP. I don’t love reinventing the wheel, and I had spent time researching the existing solutions out there, and thought that it made sense to toss my hat in the ring with my own live search plugin freely available to everyone, regardless of whether they used SearchWP. I saw a lot of awesome, creative implementations of live search in the existing plugins, but I also saw some things I’d do a bit differently if I built my own. Things I thought other WordPress users would find useful in a live search plugin. All that to say:

I thought it’d be awesome to build a live search plugin for SearchWP that fell back to native WordPress search if you don’t use SearchWP. Best of both worlds, right? I began by inventorying what my ideal live search plugin would look like.

Great things in existing plugins

There’s a lot to enjoy about the existing plugins out there, and I took note of a few things I really liked.

Automagic: Many of these plugins automatically work with forms generated by get_search_form() right out of the box. Unfortunately many piggyback an input name="s" which was a blocker for full SearchWP integration.

Fast enough: This isn’t meant as a backhanded compliment, but I’ll be honest in saying that many times making a WordPress-faciliated AJAX request may not be the most performant given the plugins and/or theme you’re running. People want the absolute fastest results possible when it comes to live search. When making an AJAX request in WordPress, the entire environment loads regardless of whether you’re utilizing it or not which can result in unwanted latency. Some solutions out there take advantage of WordPress’ SHORTINIT constant, but for me that’s not an option given the custom hooks available in SearchWP that must be available to developers, even with live search.

Areas of improvement

As I worked out how to best integrate SearchWP with existing plugins in hopes of not building one myself, I noticed some other things (that are likely personal bias, but) I would like to utilize differently.

Results template(s): Many existing plugins have their own established results template, one that very often has options you can customize and tweak to your liking, but they’re always based on some sort of established foundation. I’d prefer something that took advantage of a template loader, so developers could literally build their results template from the ground up as they would any other theme template.

Configuration: I really try to avoid options screens as much as possible. Many existing plugins implement an options screen with any number of settings you can use to customize the implementation of your live search. I wish there was an easy way to do this on a code level. Making everything work with hooks allows for bolt-on settings screens should they prove necessary down the line, without completely coupling your code to settings values.

Adaptability: This is likely a use case solely for SearchWP, but I wanted to make it easier for developers to manually enable live search on forms. I thought a nice way to do that would be to utilize a single HTML5 data attribute (which worked out awesome, by the way).

Ready to go

I spent some time building out what I hope to be a really adaptable live search for WordPress. You can grab it here. I have a list of what I feel are potentially good ideas, but I don’t want to cloud it up with too much personal use case bias quite yet. Exposing it to the wild will shine light on existing areas of improvement in preparation for future enhancements.

Documentation is available on the SearchWP Extension page and there is also info/screenshots in the readme on .org. The GitHub repo is more than welcoming of pull requests. Enjoy!

Get my newsletter

Receive periodic updates right in the mail!
  • This field is for validation purposes and should be left unchanged.

Comments

  1. Hey Christopher, this is a very interesting plugin. Another big plus would be including a Typeahead autocomplete or even a search as you type feature ( like google search ).

    Cheers!

  2. Definitely on the backlog — predictive searching is definitely more resource intensive, and since I had to take an admin-ajax approach to this one (to accommodate SearchWP hooks) it will take some creative implementation to get that to be performant.

    Absolutely makes terrific sense though, thank you for confirming!

  3. Thanks for this; I’m looking forward to giving both SearchWP and the new live search a try 🙂

    (Tiny typo in the article: SHORTINT for SHORTINIT. I hadn’t heard of SHORTINIT so it took me a while to figure that out!)

  4. Hi there Jonathan,

    Nice plugin. I’m trying it out right now.

    I don’t get any results back from the ajax request. It only display the “no results found” message. (even while there are results)

    After investigating on this a bit, i discovered that the query_posts() function must have a post_type defined, otherwise post__in won’t retrieve any results (that are a CPT I think).

    So replacing the $args in class-client.php:43 with:

    $args = array(
    ‘post_type’ => ‘any’,
    ‘post__in’ => $posts,
    ‘orderby’ => ‘post__in’,
    );

    Gives me the results i wanted. Just letting you know!

Leave a Reply

Your email address will not be published. Required fields are marked *