I have the same trouble with WordPress 3.5.
Thread Starter
gavinr
(@gavinr)
Copoli,
I contacted this plugin’s maintainer, and he said he’s going to update the plugin soon.
In the meantime, I replaced the jQueryUI files in the plugin with the latest jQuery UI files, and that fixes the issues (jQuery conflict).
Gavin
Gavinr,
is file “jquery-ui-1.8.9.custom.min” to be replaced or there are some other files?
What is the link to the latest file(s)? Couldn’t find files on the jQuery site..
Gavinr,
I replaced the jquery-ui-1.8.9.custom.min.js with jquery-ui-1.9.2.custom.min.js and it’s ok. Thank you.
Artildo : this file (1.9.2 stable version) can be download from this link : http://jqueryui.com/
Olivier.
Copoli,
had 5 minutes to test – downloaded, and renamed 1.9.2. into 1.8.9. Seems to work, needs customization.
Thanks
The best way to go forward is to use the version of jQuery UI that is provided with WP core since 3.3: http://codex.wordpress.org/Function_Reference/wp_enqueue_script#Default_scripts_included_with_WordPress
This way should have the benefits of being most forward-compatible, avoiding double loading of same scripts and being compatible with Use Google Libraries.
To do this, open searchautocomplete.php, locate lines 14-15:
wp_register_script('autocompletejquery', WP_PLUGIN_URL.'/search-autocomplete/includes/jquery-ui-1.8.9.custom.min.js', array('jquery'), '1.0.0');
wp_enqueue_script('autocompletejquery');
and replace them with
wp_enqueue_script('jquery-ui-core');
To improve code maintainability add an empty line before and after that one.
Daedalon,
it didn’t work in my case. Not only it didn’t provide expanding list below the search bar when typing, but also ruined jQuery Vertical Mega menu.
That’s interesting, since all that line does is make sure that jQuery UI core is loaded. I have Search Autocomplete on two sites and the above worked for both. For one it wasn’t strictly necessary, since another plugin already made sure that jquery-ui-core was already enqueued, but for the other it was needed.
The enqueued script is http://ajax.googleapis.com/ajax/libs/jqueryui/1.9.2/jquery-ui.min.js (or the one in your WP install directory), which is a standard script. The error you experience might be caused by an error in another JavaScript file that your site loads. This can be detected via the screen console > errors in Firebug.
I was actually expecting that the script jquery-ui-autocomplete should also be enqueued, but neither one of our sites required that. You might try adding a line for that too as a possible fix for the issues you encountered.
Daedalon,
thank you for going in details. I stil have it renamed (the new 1.9.2 to 1.8.9) and it works.
But if i cannot overcome a couple of issues, I’ll have to give up the plugin
The most interesting. I need to mark up whether its a category or tag in the list. Like:
category: Blue birds
tag: Blue sparrows
A great example is here: http://jqueryui.com/autocomplete/#categories
Actually, it’s a great lack for the plugin that it stacks all the autocomplete words in one solid list. Users don’t know what they choose.
I’ve made such a customization to the plugin on one of the sites we run it on. If the thread http://wordpress.org/support/topic/plugin-searchautocomplete-patch-support-custom-post-types doesn’t have that patch, I’d be interested in hearing from the plugin author to collaborate on releasing an updated version of the plugin to support this and a few other features. I could email him the copy I’m running so he could check if it’s ready for release.
I’d still hope that enqueuing the jquery-ui-core would work for everyone, that’d solve the compatibility errors this thread is about once and for all.
A new version of the plugin has been released that utilizes the WordPress AJAX methods and works in 3.5. Please let me know if you are still experiencing these issues.
I have no more problem with the new release 2.0.1. Thank you and happy new year.
hereswhatidid,
A couple of questions:
1) It is impossible now to uncheck post links and “post” post types in the Settings. Simply, when you uncheck and save settings, checkmarks reappear. I really need them to be out of the autocomplete scope, as my posts can not be viewed in a single manner
2) Is it possible to mark autocomplete tips whether it is a post name, category or tag? Looks really messy, as user cannot see what kind of search will be performed.
More feedback on 2.0.1. First on what Artildo wrote above:
2) I’ve implemented that patch for 1.0.9. Should be easy to implement for the 2.0 line as well. It’s very useful for the users.
2.1) It could even be expanded further to give more information on custom post types of common plugins. I have Events Manager at mind: showing the date of Events and the city of Locations for starters. I might submit an incremental patch for this later if Gabe welcomes the idea of plugin-specific support.
My own notes:
3) Great improvements: Works with both 3.4.2 and 3.5. An option to limit how many results are displayed. It’s now possible to select every post and taxonomy to be or not be included in the search results. The order of types can be specified to be either posts or types first. Thanks!
4) It would be good to be able to specify the order within taxonomies and post types as well. I’d want to be able to specify whether Events Manager‘s Locations would be shown before Events.
A possible way of implementing this is a drag-and-drop reorder interface á la plugins like http://wordpress.org/extend/plugins/simple-page-ordering/screenshots/ or http://wordpress.org/extend/plugins/my-link-order/.
5) When updating from the latest 1.0.9 version, the settings were lost.
6) The dropdown menu to select a Theme Stylesheet is empty. None of the styles included in 1.0.9 appeared here and neither does the custom style we made for 1.0.9 (which was simply the default ui-darkness with images run through PNGout and OptiPNG to decrease file sizes). Now all the search results are shown as black on white. Would be good to have the selection of dropdown styles back.
7) Using Events Manager I’ve needed an option to further customize the ordering of the search results. It’d be very useful to have option fields for extra SQL options. With these it’d be possible to add for example the following customizations in an update-safe way:
7.1) Select also event_start_date, event_end_date, location_event_count and location_town
7.2) Require that either the event_start_date or event_end_date are today or in the future
7.3) Order Events by event_start_date first, event_end_date second
7.4) Order Locations by location_event_count
