Gabe Shackle

These should be cleared up in the latest version (2.1.12)

I’m also getting this error in WP 4.0.

Here’s an example showing how to disable all scripts and styles for this plugin on the Front Page of your site:

function sa_disable_on_home() {
	if ( is_front_page() ) {
		return true; // disable scripts
	} else {
		return false; // enable scripts
	}
}

add_filter( 'search_autocomplete_disable_frontscripts', 'sa_disable_on_home' );

This code would go in either your theme’s functions.php file or a plugin file if you’re loading things that way.

Does this happen when Search Autocomplete is disabled and Relevanssi is enabled?

I’d like to see how that theme is handling the ajax but it’s a premium purchased item and the source isn’t available for review. Also, does that autocomplete run as fast on your installation as it does on the demo server?

Can you give me any more details about your setup? I’m not able to recreate this issue on my testing environments.

Please see: https://www.ads-software.com/support/topic/add-post-and-taxonomy-as-title-without-links?replies=3

I’m still not quite sure what it is that you’re trying to do. If you want to have this plugin affect another field by what you’ve selected in the Autocomplete drop down that would need to be handled via JavaScript and you’d have to essentially hijack the default jQueryUI Autocomplete functionality. That would be beyond what I could support through these free forums.

For whatever reason the WP.org svn isn’t showing the last version yet. Once that version shows up it should clear up the taxonomies issue. As far as pointing to a different service for the data that would essentially be rewriting most of how this plugin works and isn’t something I’m interested in doing at this point.

I just pushed an update that will fix the field typo and the taxonomies selector.

As far as performance, I’m limited by how fast WordPress can generate the page and return the result. The example you linked is quite fast but doesn’t appear to be WordPress. If it were safe to use a custom ajax source I would definitely go that route for the performance improvement but that would essentially break the plugin in any site that isn’t configured exactly as I’m expecting in the plugin setup.

Marking closed due to inactivity.

Marking closed due to inactivity.

Currently this plugin does not support multiple, unique configurations within the site. It can be used on multiple fields but the search targets would all be the same.

One way to disable the form submission using jQuery would be something like this:

$( "form" ).submit(function( event ) {
  event.preventDefault();
});

Currently this plugin does not support having multiple search boxes with unique autocomplete configurations for each field, if that’s what you’re describing. You can have more than one field on the page that uses the autocomplete functionality but they all share the same configuration.