After upgrading from Chaos Tools 1.7 to 1.8, Solr facet searches no longer work, i.e. this url:

http://vm/search/apachesolr_search?filters=tid:118%20tid:260

brings up a found set in any version of CT <= 1.7, but no results are returned using CT 1.8.

Very curious!

Comments

butterfi’s picture

butterfi commented
Status: Active » Closed (fixed)

installing latest dev version fixes issue

butterfi’s picture

butterfi commented
Status: Closed (fixed) » Active

had some version/cache issue, because on a clean test bed the latest dev version also fails to return result.

merlinofchaos’s picture

merlinofchaos commented
Status: Active » Closed (won't fix)

I know nothing about solr search, so am unable to address issues. You should file this against the solr module. I don't even know how ctools would be involved.

butterfi’s picture

butterfi commented

It's a mystery to me as well, I can't think of any reason why ctools should be involved. I did discover that my issue starts with version 1.1, not 1.8 as I previously thought. (we had rc-1 installed), but I can reproduce the issue by swapping out the various iterations. I'm going to start going over the patches to see if I can isolate where the conflict begins. It may very well be a solr issue, but at least I have an idea of where the pain point starts...

butterfi’s picture

butterfi commented
Title: Solr facet handling breaks updating to CT 1.8 » Solr facet handling breaks updating to CT 1.1
Version: 6.x-1.8 » 6.x-1.1

Before I move this to solr. I believe I found the cause of my issue:

Ctools
Hash: 2f08778ab7894aeb73e123e7af344d7f85e65909
subject: #578410: Search path override, plus search form and search result content types.

This is the pain point thats breaking my facet searches.

butterfi’s picture

butterfi commented
Status: Closed (won't fix) » Active

Earl -- sorry to re-open, was hoping to get your insight on comment #5. I have also created a ticket in the solr queue, but I'm uncertain where this problem should be addressed.

jgraham’s picture

jgraham commented

Related ticket in solr queue: http://drupal.org/node/1162874

Related issue prompting for the functionality: http://drupal.org/node/578410

pwolanin’s picture

pwolanin commented

Likely both apachesolr search and ctools are doing a menu_alter on the same router item.

In that particular commit there was a bug that prevents you from using a variable_set to suppress the menu_alter:

+function page_manager_search_menu_alter(&$items, $task) {
+  foreach (module_implements('search') as $name) {
+    if (variable_get('page_manager_search_disabled_' . $name, TRUE)) {

...

+    }
+    else {
+      // automatically disable this task if it cannot be enabled.
+      variable_set('page_manager_search_disabled_' . $name, TRUE);
+      if (!empty($GLOBALS['page_manager_enabling_search'])) {
+        drupal_set_message(t('Page manager module is unable to enable search/@name/%menu_tail because some other module already has overridden wit
+      }
+    }

The current code that check is moved, but I still think

 if (variable_get('page_manager_search_disabled_' . $name, TRUE)

should be

 if (!variable_get('page_manager_search_disabled_' . $name, FALSE)

However, the current code also has this note:

 * Note to module authors: This tends to work a lot better with modules
 * that override their own search pages if their _alter runs *before*
 * this one.

so, according to the note Earl already left you in the code, you should try setting apachesolr to have a module weight lower than ctools.

merlinofchaos’s picture

merlinofchaos commented

The search tasks overrides *even* if a particular search task is disabled because of the wonky way the overall 'search' is written.

The one big improvement I think of is that it could do a sweep and if *no* search tasks are enabled, it could exit and do nothing. But if even one search task is enabled, it has to rewrite the *(&)*ing urls all over in order to make the menu structure sane.

pwolanin’s picture

pwolanin commented

@merlinofchaos - I'm not able to follow the logic without a deeper dive into the code, so I'll take your word that it's not a bug.

Anyhow - I think the answer to the problem being faced is to tweak the module weights if necessary.

Ashlar’s picture

Ashlar commented
Status: Active » Closed (won't fix)

This bug report has not been active for over six months. In an effort to clean-up the issue queue this item has been closed. If your modules are current and the report is still relevant please feel free to change the Status back to active.