SearchWP News

Category: General

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.

Existing licenses will be grandfathered

SearchWP debuted in August 2013 and since then has grown quite a bit. Customer feedback has been terrific and contributed in a significant way to the refinements put in place and features added over the past year. The plugin itself has matured a ton and I’m quite happy with the progress as well. Now that SearchWP as (more-or-less) proven itself as something that will continue to undergo additional refinement, iteration, and improvement, it’s time to shift gears slightly.

SearchWP as a ‘platform’ has grown to a place I’m happy with. I will continue to make adjustments to the indexer and search algorithm but I also have had some feature requests that have piqued my interest but at the same time will require significant effort to make a reality. I want to continue putting effort into the code itself, but do not want that to adversely affect customer support. SearchWP is new enough that recruiting additional help for customer support would be a lengthy process with a steep learning curve. With the code only being available for about a year it’s tough to expect that someone other than me has the necessary knowledge to effectively provide support, so until that time comes I will continue with the existing level of customer support being an extremely high priority.

Pricing update as of October 1, 2014

Effective October 1, 2014 there will be a pricing update for SearchWP licenses. This update will not affect existing customer licenses, only licenses purchased October 1, 2014 forward. Renewal costs for licenses purchased before October 1, 2014 have been grandfathered to their original cost as outlined during purchase at that time. The new pricing structure is as follows:

[av_table purpose=’tabular’ caption=’Pricing chart as of October 1, 2014′ responsive_styling=’avia_responsive_table’] [av_row row_style=’avia-heading-row’][av_cell col_style=’avia-desc-col’][/av_cell][av_cell col_style=”]Single[/av_cell][av_cell col_style=”]Business[/av_cell][av_cell col_style=”]Developer[/av_cell][/av_row] [av_row row_style=”][av_cell col_style=’avia-desc-col’]Supported installations[/av_cell][av_cell col_style=”]1[/av_cell][av_cell col_style=”]5[/av_cell][av_cell col_style=”]Unlimited[/av_cell][/av_row] [av_row row_style=”][av_cell col_style=’avia-desc-col’]Renewal discount[/av_cell][av_cell col_style=”]40%[/av_cell][av_cell col_style=”]40%[/av_cell][av_cell col_style=”]40%[/av_cell][/av_row] [av_row row_style=”][av_cell col_style=’avia-desc-col’]Support duration[/av_cell][av_cell col_style=”]1 year[/av_cell][av_cell col_style=”]1 year[/av_cell][av_cell col_style=”]1 year[/av_cell][/av_row] [av_row row_style=”][av_cell col_style=’avia-desc-col’]Automatic Updates[/av_cell][av_cell col_style=”]1 year[/av_cell][av_cell col_style=”]1 year[/av_cell][av_cell col_style=”]1 year[/av_cell][/av_row] [av_row row_style=”][av_cell col_style=’avia-desc-col’]Extensions[/av_cell][av_cell col_style=”]All[/av_cell][av_cell col_style=”]All[/av_cell][av_cell col_style=”]All[/av_cell][/av_row] [av_row row_style=’avia-pricing-row’][av_cell col_style=’avia-desc-col’]Price[/av_cell][av_cell col_style=”]$49[/av_cell][av_cell col_style=”]$129[/av_cell][av_cell col_style=”]$249[/av_cell][/av_row] [/av_table]

Things to note:

  • Existing license costs will be grandfathered (e.g. renewal discounts based on the original price)
  • The Single Site license price will increase from $29 to $49
  • The Business license price will increase from $99 to $129
  • The Developer license price will remain the same at $249, but the 20 site limit has been lifted
  • License renewal discounts will increase to 40% off
  • All licenses will continue to be active for 1 calendar year from the purchase date
  • All extensions will continue to be available to all active license holders at no additional cost

I hope the details of this update have been made clear, but if anyone has any questions please feel free to contact me.

Thank you all to all of the existing SearchWP customers, I appreciate every bit of feedback I’ve received, and the improvements made to the plugin over the past 12 months are thanks to all of you. I’m really excited to see where SearchWP is after another year!

Result attribution threw me for a loop but the dust has settled and 2.4.3 fixes an issue that prevented PDF content from properly attributing it’s parent post when that option was enabled.

Version 2.4.2 fixes an issue of search query latency (when using post attribution in searches) introduced by a regression fix in 2.4.1 it is a recommended update for all active license holders.

Quick bug fix for certain parent attribution configurations, changelog:

  • [Fix] Fixed an issue that prevented parent attribution from working properly in certain cases

Version 2.4 is now available to all active license holders and brings a number of improvements! SearchWP will now check for HTTP Basic Authentication and provide instructions on how to integrate the two:

SearchWP HTTP Basic Auth detection

A Dashboard Widget has also been added to provide a quick overview of recent search patterns:

SearchWP Dashboard Widget

A System Information panel has been added to the Advanced settings screen (link at the bottom right of the main settings screen) which will help me a lot with support requests:

SearchWP System Information panel

There are also a few other small fixes and improvements in this version, full changelog:

  • [New] SearchWP will now detect whether you’re using HTTP Basic Authentication
  • [New] New Filter: searchwp_basic_auth_creds allowing developers to define HTTP Basic Authentication credentials
  • [New] New Filter: searchwp_query_select_inject allowing developers the ability to inject their own statements into the main search query, allowing for extensive customization of results display beyond keyword weights
  • [New] Search Statistics Dashboard Widget
  • [New] New Filter: searchwp_dashboard_widget allowing developers to disable the Search Statistics Dashboard Widget
  • [New] System Information panel (on the Advanced settings screen) to ease support
  • [Improvement] Better handling of searchwp_indexer_enabled when used at the same time as searchwp_indexer_paused
  • [Improvement] Better handling of accented characters
  • [Fix] Force transient deletion
  • [Fix] Fixed an issue where keyword stemming may have not been appropriately applied
  • [Change] Conflict notices are now only displayed when debugging is enabled

This small update brings an improvement and a bugfix you may or may not notice depending on how you’ve configured SearchWP.

  • [Improvement] Admin Bar entry now elaborates on why a post is not indexed (e.g. draft status if not filtered)
  • [Improvement] Admin Bar entry now more accurately calls out when a post is in the process of being indexed
  • [Fix] Fixed an issue that may have prevented strings of only digits from being properly indexed

A couple of quick fixes for active license holders:

  • [Improvement] Better capture of SQL_BIG_SELECTS errors by including a link to the fix in the Admin Bar
  • [Improvement] Better handling of character encoding when parsing PDFs
  • [Fix] Fixed an issue where posts excluded from the index were not properly listed on the exclusions page

This small update adds three new filters to make Term Highlight more adaptive:

searchwp_th_query — Term Highlight attempts to automagically retrieve the search query to use, but this filter lets you specify what to use

The other issue tackled with this release is how to handle Shortcodes when generating ‘global’ excerpts. Term Highlight is also in part an excerpt generation engine which will generate content from your Custom Fields when your native excerpt doesn’t contain search matches. Trouble arose when these fields contained Shortcodes which were in turn echoed (undesirable) or cut off (arguably worse). Term Highlight now takes that into account.

By default Term Highlight will strip your Shortcodes prior to finding a global excerpt. You can disable that using the following hook:

add_filter( 'searchwp_th_strip_shortcodes', '__return_false' );

If you choose to utilize that hook, Term Highlight will fall back to doing Shortcodes. If you don’t want that to happen either (thus ending up in the same boat as prior to 1.8.3) you can also prevent that from happening using this hook:

add_filter( 'searchwp_th_do_shortcode', '__return_false' );

As always, Extension downloads are available on their respective documentation pages:


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