Autocomplete for custom search pages

I remade the patch, because it uses relative path. But otherwise it works as supposed. Thanks stijn.blomme, I was wondering about this problem.

Just what I needed, thanks!

See #1577842: custom search page integration with custom search filters

suppose you have two custom search pages ("Search texts" and "Search commentaries"), one with custom filter bundle:text and the other with custom filter bundle:commentary. at the moment, apachesolr_autocomplete will pull up the same values for each. so it will say "20 results" for "analysis" even if 17 occur in the commentaries and 3 in the texts. if autocomplete isn't sensitive to the custom search filters, then it doesn't do much good to have autocomplete on the custom search pages.

This patch adds the autocomplete to the custom search pages, but it does not perform a different search based on the custom search page's configuration.

Yes. I believe the form_alter has to somehow write additional parameters based on what the context is... so each autocomplete request would have to pass that context along to modify the Solr query to build the autocomplete results.

See also #1474176: let query alter know which autocomplete it was called from, from liquidcms:

we have multiple solr custom searches on our site; these are all driven from separate search paths. so when the search is run we do an _apachesolr_modify_query() and based on the url of that path, modify the search query (for example, remove node types from the search results).

the issue is that we use autocomplete on all of these and the results that are returned are always from the full site index because, even though autcomplete is nice enough to run the
_apachesolr_modify_query hook, there is no way to know which form element is calling the autocomplete function.

i would guess it would not be too tricky to add in the form id to the json parameters and pass this along with the autocomplete request so that we could match the specific query alters.

This patch builds on the earlier ones and adds the custom search page id to the autocomplete path. The result is autocomplete behavior that appears properly on custom search pages, and suggests autocomplete results that are correctly scoped for that search.

I have tested this on the Drupal core autocomplete widget, but I wasn't able to get the Custom autocomplete widget working quickly, so it's not tested for that widget.

Please try this out on both widgets and let's get this added :)

Thank you, well done!

m

This is patch for D6 6.x-1.x. Needs testing for compatibility with 6.x-3.x branch of ApacheSolr Search... I think it might work out of the box due to some extra logic I put in there.

TODO: coming soon: patch for 7.x-1.x

Patch for D7.

After applying the above patch in dev branch I got following warnings

Notice: Trying to get property of non-object in apachesolr_autocomplete_do_alter() (line 68 of /var/www/drupal/sites/all/modules/apachesolr_autocomplete/apachesolr_autocomplete.module).

Warning: Missing argument 2 for apachesolr_autocomplete_do_alter(), called in /home/wiki/rajivk/sites/all/modules/apachesolr_autocomplete/apachesolr_autocomplete.module on line 41 and defined in apachesolr_autocomplete_do_alter() (line 62 of /var/www/drupal/sites/all/modules/apachesolr_autocomplete/apachesolr_autocomplete.module).

Following new patch corrects it.

When I tried applying the D7 version of the patch to one of our dev servers here, apache solr would not index. Has anyone else who tried this patch have similar problems? I am currently working on a project with two separate search filters and could really use this feature.

Thanks,
Connie

I am facing similar problem but I noticed that I can't do batch job (drupal/batch?op=start&id=) . Currently for doing a batch job, I have to disable autocomplete module.

Interestingly the very first patch,

function apachesolr_autocomplete_form_apachesolr_search_custom_page_search_form_alter(&$form, $form_state) {
  $element = &$form['basic']['keys'];
 apachesolr_autocomplete_do_alter($element);
}

Solved the problem and even respects the domain access module. It only pulls up the content available on my subdomains. Just letting know to anyone else using domain access and the autocomplete modules

I tried to apply the patch in #9 but it wouldn't apply, so I had to do it manually.
Anyways, this patch does most of what I'm looking for, but it doesn't have support for different solr environments.
I added this functionality based on the patch in #9. The only other change I made was removing backwards compatibility for d6, that has no place in a d7 module as far as I see?

Found a bug in above patch, tried to load the search page twice. Fix in included patch.

+++ b/apachesolr_autocomplete.moduleundefined
@@ -40,18 +38,40 @@ function apachesolr_autocomplete_form_search_form_alter(&$form, $form_state) {
+  if (isset($form['#search_page'])) {
+    $search_page_id = $form['#search_page']->page_id;

To get it working, this should be replaced by:
$search_page_id = $form['#search_page']['page_id'];

Other than that, everything is working as it should.

Patch attached.

There's still a problem with the patch.
When editing mini-panels, I don't have the possibility to add content because there is a javascript error:
Uncaught TypeError: Cannot read property 'path' of undefined

Adding
drupal_add_js(array('apachesolr_autocomplete' => array('path' => '')), 'setting');

in the hook_init() solve the problem but maybe there's a cleaner solution. Anyone ?

I checked if the variable was set in javascript. I don't know if this is cleaner, but it works.
I based the patch on comment #15.

Ok, thanks all for chiming in.

Let's first try to gt this working on 7.x, then we can backport.

It's great a lot of the above patches work, but there's one thing that's missing (and is actually on the patches) :

  // TODO: Note this only supports one widget per page.

I'm working on a patch that's able to handle different environments, see below.
Some notes:
* This would mean that, for consistency, we would have to altogether drop the option to use the Core autocomplete widget. That would, however, open up the way to also fix the "Retain current filters" option consistently. This patch still has not removed the " Autocomplete widget to use" option nor logic, but will only work if you set the widget to be the Custom one on the module settings.
* This adds a data-apachesolr-autocomplete-idattribute to the form to know what environment we're talking about. Not sure if this will work cross-browser or not... need a Javascript/jQuery sanity check =)
* This also raises the question if we will want/need per-environment settings instead of global ones. For instance: enable spellcheck suggestions for just one of the environments.
* Have not tested this yet with panels, testers welcome.

If you're testing this, note:
* You need to switch the autocomplete widget to the "Custom" one on the settings page.
* this might cache clear is needed if you're working with aggregated JS.

So, TODO:
* Panels testing
* Remove logic/code for Drupal core widget, the custom widget would be the only option available.

Tested and it retrieves the following error:

warning: apachesolr_autocomplete.module has type 100644, expected 100755
error: while searching for:
* learn student, learn school, learn mathematics.
* The suggested terms are returned in order of frequency (most frequent first).
*/
function apachesolr_autocomplete_suggest_additional_term($keys, $suggestions_to_return = 5) {
$keys = trim($keys);
$keys = check_plain($keys);
if ($keys == '') {
return array();
}

error: patch failed: apachesolr_autocomplete.module:232
error: apachesolr_autocomplete.module: patch does not apply

Tested patch above in #19 https://drupal.org/node/1444038#comment-6993306

Got 1 hunk out of 13 failed

patching file apachesolr_autocomplete.js
patching file apachesolr_autocomplete.module
Hunk #11 FAILED at 284.
1 out of 13 hunks FAILED -- saving rejects to file apachesolr_autocomplete.module.rej
$ cat apachesolr_autocomplete.module.rej
--- apachesolr_autocomplete.module
+++ apachesolr_autocomplete.module
@@ -284,9 +336,9 @@
  *    learn student, learn school, learn mathematics.
  * The suggested terms are returned in order of frequency (most frequent first).
  */
-function apachesolr_autocomplete_suggest_additional_term($keys, $suggestions_to_return = 5) {
+function apachesolr_autocomplete_suggest_additional_term($keys, $suggestions_to_return = 5, $search_page = NULL) {
   $keys = trim($keys);
-  $keys = check_plain($keys);
+  $keys = check_plain($keys);
   if ($keys == '') {
     return array();
}

Re-rolling patch against the latest dev release.

Counts on custom pages still were not showing correctly for me. Found it was due to $search_page not being passed to apachesolr_autocomplete_basic_params() in one instance.

Have added this fix.

#23 works perfectly, thanks !

The previous patches didn't work on panelized search pages, this updated patch add an additional form alter so the search widget pane is included.

Argh. I got the search input key incorrect in the previous patch. This one fixes it.

Crosslinking #1061260: Apache Solr Panels Integration which is around Panels integration... we probably want the patch from #27 above without the panels integration (for now!) and when this is committed then we can work on the panels integration full-on.

The code does look good at first glance. I hope I can finally test this soon.

Just to keep this somewhere... attached is a small improvement to the patch for D6 in #8. Still waay behind the latest D7 one, but putting here to catch up after the D7 one is committed.

It looks like a proper review still hasn't been done on #27, so moving back to needs review.

I reviewed the patch in #27, it wasn't working as expected due to some JS errors (apachesolr_autocomplete was wrongly replaced with "autocomplete", other jQuery selectors wasn't working properly).

I removed the Panels integration as for #28

@todo: remove some 6.x back compatibility checks?

Please review my patch here

Last patch with latest -dev works correcly for me.

Thank you.

A small edit:
in function apachesolr_autocomplete_do_alter(&$element, $form) {
the first lines should be

// The unique element ID for this form's keyword search element.
$autocomplete_element_id = $form['#form_id'];

This allow the autocomplete to work even if multiple search forms are placed in a same page (required for new module I'm implementing to allow pages to also provide separated search-blocks).

Regards

I am using patch #23 in one of our website running with module Apache Solr autocomplete version 7.x-1.3
I am now updating my website and I tried to update the module to version 7.x-1.4 and apply this patch. Unfortunately this didn't worked.

Has someone of you a solution?

@mstv287: did you try patch in #31?

@thePanz I tried to apply patch in #31 and it got applied with the exception of this part:

@@ -290,7 +343,14 @@
   $keys_array = array_filter($keys_array);
 
   // Query Solr for $keys so that suggestions will always return results.
-  $query = apachesolr_drupal_query($keys);
+  // Check for apachesolr module version & issue correct call.
+  if (function_exists('apachesolr_search_page_load')) {
+    $query = apachesolr_drupal_query('apachesolr_autocomplete', $params);
+  }
+  else {
+    // Version for 6.x-1.x branch of ApacheSolr.
+    $query = apachesolr_drupal_query($keys);
+  }
 
   // This hook allows modules to modify the query and params objects.
   drupal_alter('apachesolr_query', $query);
-- 

I didn't understood why this can't be applied but I did the change manually and the autocomplete function is working!

Many thanks for your help.

Best regards,
Michel (mstv297)

@mstb297: the patch is meant for -dev release of the module :)
I am moving this to Tested by community since 2 devs confirmed it is working :)

Patch applied partially, not all the patch on the latest dev.

The patch in #31 has a serious bug:

jQuery(".apachesolr-autocomplete.[data-apachesolr-autocomplete-id='"+ key +"']", context) should be replaced with:
jQuery(".apachesolr-autocomplete[data-apachesolr-autocomplete-id='"+ key +"']", context)

Looks committed. I download latest dev and see all the code of the latest #31 patch is there applied. So fixed.

No, obviously not fixed. See my comment #39.

Updated the patch with the suggestion in #39

Uploading the updated patch below.

Patch in #42 appears to be backwards. (IE it removes the changes...) Just needs a re-roll with the branch names reversed, I suspect.

Yes, seems to be committed. Still the autocomplete doesn't work on my custom search pages.

N20, do you see javascript errors in your console? I also implemented the patch and it's working for me

No errors at all. I now have the core search block (search_block_form) working in my panel. Problem is that this form is redirecting to cores search page 'search/site'. But i have a custom search page setup.

If i use the Apache Solr search form, which has the option to override the path doesn't have autocomplete at all.

In my case i need to get either the core search to redirect to somewhere else or the Apache Solr form to play nicely with autocomplete.

New patch, against fresh checkout of master.

Includes #2596777: The current search page ID is not passed as a context, like a normal apache solr search

New patch, since a lot of changes made it into 7.x-1.x yesterday.

Please test!

(Note: 'master' branch is being deprecated to now use 7.x-1.x)

New patch. I will commit this soon.

Committed! Thanks all!