SearchWP News

Category: General

SearchWP version 2.8.6 is now available for all active license holders. This is a bug fix and maintenance release and is recommended for all SearchWP customers. Version 2.8.6 was quickly released after version 2.8.5 to fix a bug with empty searches.

Full changelogs:


  • [Fix] Fixed an issue with imposed engine config implementation for empty searches


  • [New] Engine settings (e.g. exclusions/inclusions) are now imposed for empty searches
  • [New] New filter searchwp_disable_impose_engine_config to disable imposed engine settings for empty searches
  • [Fix] Fixed an issue that may have triggered unnecessary index update requests
  • [Improvement] Style updates to better match WordPress’ implementation of system font
  • [Improvement] Better handling of indexer requests
  • [Improvement] Better support when Admin/Dashboard searches are enabled
  • [Improvement] Better utilization of existing extracted document content when triggering an index rebuild
  • [Improvement] Better feedback when document parsing dependencies are not available
  • [Update] Added more file type limiters to engine settings
  • [Update] Updated translation sources
  • [Update] Updated updater

Version 2.8.4 primarily fixes an issue with admin-enabled searching. This update is available to all active license holders.

Full changelog:

  • [New] New filter searchwp_indexer_comment to filter comment arguments during indexing
  • [New] New filter searchwp_indexer_pre_get_comments to filter comment arguments during indexing
  • [New] New filter searchwp_indexer_comments_args to filter comment arguments during indexing
  • [Fix] Fixed an issue that prevented searching in the WordPress admin (when enabled)

SearchWP version 2.8.3 is now available to all active license holders. This a bugfix and maintenance release that is recommended for everyone. Here’s the full changelog:

  • [New] New filter searchwp_search_args to filter search arguments at runtime
  • [Improvement] Better handling of object caching
  • [Improvement] Better messaging when rebuilding index
  • [Improvement] Dequeue/deregister legacy versions of select2 that are imposed upon SearchWP’s settings screen
  • [Improvement] Better handling of regex matches
  • [Fix] Fixed an issue that sometimes prevented the indexer progress bar from displaying after rebuilding index
  • [Fix] Fixed an issue that may have prevented manually edited document content from being fully re-indexed
  • [Fix] Fixed PHP Warning during short circuit check
  • [Fix] Disabling the minimum character count reduces length to 1 instead of 2

SearchWP version 2.8.2 has just been released for all active license holders. This is a bug fix and maintenance release that’s recommended for everyone.

Full changelog:

  • [Fix] Fixed a mime type mismatch that prevented accurate Media limiting using All Documents file type
  • [Fix] Admin Bar and Advanced tab indexer pausing now use the same setting
  • [Fix] Fixed an issue when checking for utf8mb4 support
  • [Improvement] Improved regex pattern for hyphen-separated matches
  • [Improvement] Improved aggressiveness of search algorithm where necessary to prevent unexpected filtration during searches
  • [Update] Updated updater


SearchWP version 2.7.1 is now available to all active license holders. This is a maintenance release that includes a number of bug fixes that will benefit all installations of SearchWP.

Some underlying work has been done to the way stats are retrieved, it’s part of the groundwork being laid for an Advanced Metrics extension I’ve been thinking about. With this update comes a fix for inaccurate stats counts on the Dashboard Widget.

If you have any ideas for features you’d like to see in an Advanced Metrics extension, I’d love to hear!

Another fix has been put in place that resolves an issue with multiple SWP_Query‘s on a single page.

Full changelog:

  • [Fix] Cleaned up PHP Warning in SWP_Query
  • [Fix] Fixed positioning of Extensions dropdown, other minor style updates
  • [Fix] Fixed an issue with SWP_Query not resetting set hooks causing inaccurate results
  • [Fix] Fixed an issue where Alternate Indexer may report posts left to index when no post types are enabled
  • [Fix] Fixed an issue where AND logic pass was too restrictive in some circumstances
  • [Fix] Fixed an issue when limiting Media results to Images only throwing a PHP Warning
  • [Fix] Fixed an issue that caused some WP Admin notices to not display
  • [Improvement] Refactored some stats logic into SearchWP_Stats
  • [Update] Updated translation source

Long time SearchWP customers are familiar with the limitation that while SearchWP itself offers automatic updates, Extensions don’t. This is unfortunate for a number of reasons as Extensions (like SearchWP core) receive periodic updates that include bug fixes and new features. Extension updates are admittedly sporadic, extensions are designed to be ultra-small modifications to the way SearchWP operates. But unless you’re in the habit of manually checking the extension page on you wouldn’t know about the update being available.

The times have changed!

Over the past month or so all Extensions have been inheriting an improvement that was made to the licensing platform powering SearchWP’s licenses. Long story short: all of your extensions can now receive automatic updates!

NOTE: Extensions simply utilize your SearchWP license, there is no need (and nowhere) to enter in an additional license key!

With this change comes an improvement to the extensions pages themselves. In addition to the download link, docs, and other information, the current version and changelog are displayed as well. This should help you determine whether you need to update to an auto-updating update of your extension (haha!)

So be sure to check out the new Extensions pages and update any that need updating!

Version 2.6 of SearchWP is now available for all active license holders. You will see an update notification in your WordPress admin area, and the latest version is always available as a direct download from your Account. On to the wonderful release details!

Settings interface improvements

SearchWP got a bit of a facelift in the settings department. I’ve always liked the engine configuration, but the rest needed some work. Everything under the hood that powers the settings was reworked to better accommodate everything as well.


These interface updates were influenced by CalderaWP projects and FacetWP because they’re awesome. The update affords more attention to the Advanced settings area which is becoming more of a utility as SearchWP and the user base matures. The Advanced settings area was also reworked to optimize actions most commonly taken on this screen. It also provides some very high level stats for the indexer that will help provide you details about the status as well as shed more insight should a support ticket need to be opened.


The license management workflow has been completely reworked. When you have an inactive license (as in the screenshot above) the link will be called out in blue, with an active license it takes a step back and looks like the other tabs. The License management itself was redone to better call out the status of your license:


When your license is active, this page now indicates how long the license will remain active as well:


The ‘Support’ button has been reworked as a Help tab, allowing for a more streamlined ticket creation process with an easily accessible viewing of your System Information:


The last interface update was the integration of Extensions that require a settings UI. When one of those extensions is activated a new tab will be added and essentially replicate the dropdown that was present in versions prior to 2.6. Everything else extension-wise works the same on the surface, but an entirely new Settings API was built for extensions to integrate themselves into the settings. If you’d like to find out more about that, please see the Settings API documentation.

Introducing SWP_Query!

Perhaps the thing I am most excited about in SearchWP 2.6 is the introduction of a new class: SWP_Query. This class is something that will be most useful to developers, it aims to recreate as much as it can from WP_Query. WP_Query is essential for development, and many WordPress developers are very familiar with it. SearchWP can work in much the same way as WP_Query, so why not make a class that eases that process for developers? While SWP_Query will never fully replicate WP_Query, the aim is to have it be a utility that WordPress developers can use with as little friction as possible. As of SearchWP 2.6, SWP_Query supports the following arguments:

  • s — the search query
  • engine — the SearchWP engine to use (default: default)
  • posts_per_page — how many posts to return per page (default is the global posts per page defined in Settings > Reading in the WordPress admin)
  • nopaging — disable pagination and return all posts (default: false)
  • load_posts — whether to return post objects (default: true)
  • page — which page of results to return (default: 1)
  • post__in — array of post IDs to limit results to (default: empty array)
  • post__not_in — array of post IDs to exclude from results (default: empty array)
  • tax_query — see WP_Query‘s tax_query documentation
  • meta_query — see WP_Query‘s meta_query documentation
  • date_query — see WP_Query‘s date_query documentation

The introduction of SWP_Query should make the lives of many developers much better. SearchWP tightly integrates with WordPress’ posts table which makes something like this possible. I’m most excited about the tax_query, meta_query, and date_query arguments which will reduce the complexity of making those operations possible. Working with SWP_Query is very similar to using WP_Query:

$swp_query = new SWP_Query(
's' => 'coffee', // search query
'engine' => 'default', // engine to use
'post_type' => array(), // override enabled post types in engine config (SearchWP 2.7+)
'posts_per_page' => 10, // posts per page
'nopaging' => false, // disable paging?
'fields' => 'all', // set to 'ids' to return only post IDs (SearchWP 2.7+)
'page' => 1, // which page of results
'post__in' => array(), // limit potential results pool to array of IDs
'post__not_in' => array(), // explicity exclude IDs from search results
'tax_query' => array( // tax_query support
'taxonomy' => 'people',
'field' => 'slug',
'terms' => 'bob',
'meta_query' => array( // meta_query support
'key' => 'age',
'value' => array( 3, 4 ),
'compare' => 'IN',
'date_query' => array( // date_query support
'year' => 2015,
'month' => 6,
'day' => 1,
view raw gistfile1.php hosted with ❤ by GitHub

In the sample above, $swp_query will have a posts property (just like WP_Query) containing all of the search results. There are some other useful properties returned as well! For more information on SWP_Query please see the documentation.

Index improvements, new hooks, and bugfixes, enjoy!

Version 2.6 brings a reduction in overhead for the index which should improve performance both when indexing and searching. Another bug was fixed that in some cases prevented the indexer from completing when the remaining post(s) had no content to index after the content was tokenized. With all of the updates to the settings, a number of new hooks were added in version 2.6 as well. If you’d like to find out more, they are all documented.

I hope you enjoy SearchWP!

Full changelog:


  • [New] New class: SWP_Query which aims to mirror WP_Query in many ways, but with a SearchWP twist
  • [New] Settings UI has been revamped
  • [New] New filter: searchwp_swp_query_args to filter SWP_Query args at runtime
  • [New] New action: searchwp_settings_init fires when the settings utility has been initialized
  • [New] New action: searchwp_load fires when SearchWP has loaded
  • [New] New action: searchwp_settings_before_header fires before the settings header is output
  • [New] New action: searchwp_settings_nav_tab to implement settings tabs
  • [New] New action: searchwp_settings_after_header fires after the settings header is output
  • [New] New action: searchwp_settings_before\my_view where my_view is the name of the settings view for that tab
  • [New] New action: searchwp_settings_view\my_view where my_view is the name of the settings view for that tab
  • [New] New action: searchwp_settings_after\my_view where my_view is the name of the settings view for that tab
  • [New] New action: searchwp_settings_footer fires after each settings view has been displayed
  • [New] Results weights are included in HTML comment block when debugging is enabled
  • [New] New filter: searchwp_debug_append_weights_to_titles whether weights should be included in HTML comment block debug information
  • [New] New filter: searchwp_show_filter_conflict_notices whether filter conflicts should be shown when debugging is enabled (defaults to false)
  • [Improvement] Better license activation UX
  • [Improvement] Reduction of index overhead by way of pairing to engine settings
  • [Improvement] Refined list of default common (stop) words
  • [Fix] Clear out delta ceiling update check when waking up the indexer
  • [Fix] Fixed an issue that may have caused the indexer to loop when a post has no content to index after tokenizing/processing
  • [Fix] Fixed an issue where the settings screen spinner would not display
  • [Fix] Fixed an issue that prevented loading of some assets if the plugin directory was renamed
  • [Update] Updated translation files

Version 2.5 is now available to all active license holders. It includes a number of optimizations, bug fixes, and other enhancements that improve SearchWP in a number of ways. The two big additions in version 2.5 are an alternate indexer and some better feedback when search strings have been manipulated by SearchWP’s algorithm.

Alternate Indexer

A small percentage of SearchWP customers have had trouble getting the indexer to work. This is usually due to a custom hosts file (or other DNS issue) that prevented the background process from working correctly. To be more specific the HTTP calls that keep the background indexer working were not being properly received. There have also been a couple of cases where a misconfigured caching layer prevented the indexer requests from being properly received as well. As a solution to both issues, an alternate indexer has been added. Unlike background processing by default, when the alternate indexer is enabled you will need to keep a browser window open while the indexing process runs. This is not ideal, so the default remains the background indexing process, but if a server configuration issue is preventing that from working properly, the alternate indexer should resolve the issue.

To enable the alternate indexer, you can use the searchwp_alternate_indexer hook which will enable the new trigger on the main SearchWP settings screen:

Screen Shot 2015-03-18 at 9.03.32 AM

Better search string manipulation feedback

SearchWP’s algorithm includes some optimizations that aren’t immediately apparent:

  • Minimum word length
  • Common words (stopwords)
  • Maximum search terms

There have been reasonable defaults set for each of the above but if you’re new to SearchWP you may for example search for something, not get an expected result, and feel that SearchWP was behaving improperly. In most cases it’s due to a term that doesn’t meet the minimum word length requirement not being met, or a common word being excluded that you don’t want excluded.


SearchWP will now check for circumstances like these. When found, SearchWP will include an Admin Bar entry letting you know just how the search was modified based on default settings. Each entry links directly to the hook you can use to modify SearchWP’s behavior should you want to do that.


The overall intention of this feature is to help you better understand the inner workings of SearchWP and also answer questions about why an expected search result may have not shown up.

There were a number of smaller updates/tweaks introduced in 2.5 — here’s a full changelog:

  • [New] Alternate, browser based indexer for cases where background indexing doesn’t work
  • [New] Front end Admin Bar entry that calls out any search modifications put in place (e.g. minimum word length, common words, maximum search length)
  • [New] New filter: searchwp_alternate_indexer to trigger the new browser-based indexer
  • [New] New filter: searchwp_log_search to allow prevention of search logging on a per-case basis
  • [New] New filter: searchwp_init to allow for dynamic initialization of SearchWP
  • [New] New filter: searchwp_max_delta_attempts to catch edge cases causing repeated delta updates
  • [New] New filter: searchwp_indexer_taxonomies allows developers to customize which taxonomies are indexed
  • [New] New filter: searchwp_indexer_unindexed_args to customize WP_Query arguments used to locate unindexed posts
  • [New] New filter: searchwp_indexer_unindexed_media_args to customize WP_Query arguments used to locate unindexed Media
  • [New] New filter: searchwp_failed_index_notice to customize who can see the notice about unindexed posts
  • [New] New filter: searchwp_remove_pre_get_posts to define whether all hooks to pre_get_posts are removed during indexing (a very common conflict)
  • [New] New filter: searchwp_indexer_pre_process_content allows developers to customize the content being indexed before it is processed and indexed
  • [New] Set default array of excluded IDs to the main search query’s post__not_in
  • [New] Set default array of included IDs to the main search query’s post__in
  • [New] PDF metadata is now indexed
  • [Change] Use get_query_var() instead of directly grabbing $wp_query attributes
  • [Change] Add index.php to default loopback endpoint to avoid false positives with WAFs
  • [Change] Use debug.txt instead of debug.log
  • [Change] PDF text extraction abstracted to it’s own method SWP()->extract_pdf_text( $post_id )
  • [Fix] Fixed an issue that prevented limiting Media results for an engine to more than one MIME type group
  • [Fix] Fixed an off-by-one issue that prevented single terms from being indexed when using the searchwp_process_term_limit filter
  • [Fix] Fixed an issue that interfered with pagination in the WP admin when searchwp_in_admin was set to true
  • [Fix] PHP Warning cleanup in Dashboard Widget
  • [Fix] Only output Dashboard Widget assets on the Dashboard
  • [Fix] Fixed an overflow issue in Dashboard Widget when collapsed on load
  • [Fix] Fixed an issue where Dashboard Widget stats transients were not cleared when stats were reset
  • [Improvement] Better minimum height for statistics graph
  • [Improvement] Better width restriction on settings screen for post type tabs
  • [Improvement] Better detection of database environment change that may interfere with indexing
  • [Improvement] Weights of less than 0 are now called out to ensure intention of excluding results
  • [Improvement] Better checks against searchwp_indexed_post_types when displaying settings screen
  • [Improvement] Main search algorithm optimizations
  • [Improvement] Indexer now checks for excluded posts before reindexing them after a purge
  • [Improvement] Optimizations to search algorithm when weights of zero are used
  • [Improvement] UI improvements on the settings screen
  • [Update] Updated translation files
  • [Update] Updated updater

As per the notice from a few months ago, the (old) support forums have been fully decommissioned. While they served a purpose for a while, the data rot was excessive and often provided more confusion than it did help. It also asked a lot of SearchWP customers such that in order to find an answer for your question you needed to follow the forum thread (which was sometimes a rabbit trail) to find the answer. I don’t feel that was doing customers the best service possible, so the forums have been removed and the support system moved to the in-plugin ticket system you see today.

Requests to removed URLs are being recorded and every effort will be made to create Knowledge Base articles for often-requested support threads with comprehensive, up-to-date information.

Thank you!

For the first year of it’s life SearchWP’s support process was based on a customer-only forum powered by bbPress. I really like bbPress as a support platform, and since it fits in with WordPress so well, it wasn’t difficult to ensure that only active SearchWP license holders (powered by Easy Digital Downloads’ Software Licensing) were able to post. However this process will be changing:

Support will no longer be forum based and is moving inside SearchWP itself, within your WordPress install

As of today with the release of SearchWP version 2.4.5, the support forum is officially deprecated in favor of in-plugin support tickets. The forum will be left online through the end of 2014 after which it will be removed completely. The existing Forums, Topics, and Replies will be left in a read-only state until the new year. This will allow existing customers to retrieve any information from existing threads before removal.

Why the change?

In my opinion one of the best byproducts of using a forum for support is that it creates a living documentation system. As I’ve found over the past year this is also for my laziness; it gave me an excuse to neglect updating my documentation. Documentation is supremely important to me and while forum posts can be helpful they will never beat purpose-written documentation.

The other main issue I took with using a forum to power support also correlates to it being public: information rot. SearchWP is over a year old now and the bulk of the forum threads revolve around issues that have long since been closed and/or improved upon. Knowing customers had to sift through this old data was a problem, and I don’t have the bandwidth to curate thousands of posts in perpetuity.

These two reasons have been building over the past few months, so starting with version 2.4.5 support will no longer be offered via public forum. There was always another bit that I had on my mind sine day one: some customers simply aren’t comfortable posting their questions in a publicly visible way. Sure you can obscure your identity by changing your display name and only making private posts, but a few customers over the past year have expressed their concern about that.

How will customers receive support?

The support process is now baked right into SearchWP and available in your WordPress administration area. When viewing the SearchWP settings, you’ll see a new Support button.

2014-09-28 at 8.43 PM

Clicking Support will invoke the support process. As was established in the forum, receiving support begins by searching SearchWP’s existing documentation. Begin by describing your issue using effective keywords:


After searching you will be shown links to relevant documentation:


If none of the documentation helps you can easily open a new support ticket:


Once you have described the issue you’re having, your support ticket will be created and all correspondence will occur via email.

What powers the new system?

If you’re interested in the technical details behind the new support system, I’m right there with you. I love reading about implementations like these and would be happy to share more details.

The backbone of the new system is email, and it’s made awesome by HelpScout. Email has a super low barrier to entry which is important to me. A few SearchWP customers were confused by the support process when using a forum, and I feel I had a blind eye toward that simply because I was familiar with bbPress and really like using it. Email gets around ‘another system to use’ for many customers.

SearchWP’s site platform is powered by Easy Digital Downloads and licenses are powered by EDD’s Software Licensing. Integrating this data with HelpScout was made easy thanks to Danny van Kooten‘s edd-helpscout. This pulls license information in with each HelpScout ticket; awesome.

This update to support was to lower the barrier to entry for customers needing support. I based this implementation off the idea of wanting to initiate the support process right within the WordPress administration area. There are a few ways to go about implementing such a feature, but I wanted to make sure I avoided as much of the initial back-and-forth that sometimes comes up when providing support. My goals were:

  1. Validate the submission against an active license
  2. Make sure customers are able to help themselves by easily searching existing documentation prior to needing a support ticket
  3. Pass along helpful information that might help me answer the support question

Since the ticket creation process starts in the customer’s WordPress install, I have direct access to the status of the SearchWP license. Primary goal accomplished. The next thing to think about was actually integrating the ticket creation process, which involved forms and data processing. I didn’t want to increase the complexity of SearchWP’s code base for the sake of support tickets, so I decided to facilitate everything via Gravity Forms through an IFRAME. Brady Vercher‘s gravity-forms-iframe made this painless. With that plugin I can simply set up the entire ticket workflow outside the WordPress install, and Gravity Forms can do all of the heavy lifting.

It wasn’t as straightforward as that though. Although I give a very high priority to customer support, I want to do as little of it as possible. That’s why I want to continue iterating and improving upon SearchWP’s documentation. Searching the documentation prefaces support ticket creation as it did when support ran through bbPress, but it’s even more straightforward now. Since ticket creation is happening in an IFRAME I have complete control over it and was able to quickly set up a workflow that first guides customers through searching the documentation, and if no existing information proves to be useful a ticket can be created right there. gravity-forms-iframe works in such a way that I was able to integrate this workflow very easily and make the process quite seamless.

The final benefit to baking in support ensures that the support request is originating from a site with an active license. Further it allows me to pass along pertinent information about common support issues such as problematic hosting environments or improperly built themes that interfere with SearchWP’s functionality. When customers need to create tickets in a support forum the only way for me to get this information was to ask which not only takes time it also requires a close look at their server environment, their theme files, or both. That friction is all but removed using this new system.

Questions or concerns?

If you have any questions at all about the new system by all means feel free to send an email or ping on Twitter. I feel that this change in handling support is going to improve things across the board in many ways. Help Scout is a terrific platform, the way they’ve implemented the process of handling support over email is really impressive to me. Compound that usefulness by being able to fall back to my email client both on my computer and my phone and the extra friction of needing to be logged in to a forum is going to be a welcome change. More importantly, I hope that customers appreciate the change. I think they will.

Fix keyword search on your site. No coding required!

Now you can utilize all of the content that's gone unrecognized by native WordPress keyword search instantly with SearchWP

Get SearchWP