This is related to a compatibility issue between the search404 module and apachesolr_search. Please see http://drupal.org/node/1353188#comment-5524886 for details on that issue.

When attempting to patch search404, I ran across this issue. When encountering a 404 error, the search404 module invokes search_data($keys, 'apachesolr_search'). Note that the third argument, $conditions, is not specified. When invoking search_data in this manner, an error message appears stating "The Apache Solr search engine is not available", but search results are still returned.

Expected behavior: there should be no error message if $conditions is not specified.

Comments

nick_vh’s picture

Status: Active » Needs work
function apachesolr_search_search_results($keys = NULL, $conditions = NULL, $search_page = NULL) {
  if (empty($search_page)) {
    $search_page = apachesolr_search_page_load('core_search');
  }
  // Check our parameters
  if (empty($conditions) || empty($search_page)) {
    apachesolr_failure(t('Solr search'), $keys);
  }

What is your suggestion then? Supply some default conditions anyhow when search_data is executed or change this if to not include the enpty($conditions) check?

paulmckibben’s picture

Hi Nick, thanks for the response. I didn't offer a suggestion or patch because I don't know enough about the architecture of this module, or search in general, to know the proper way to address this.

Either of the options you suggest seems reasonable to me. For a default set of conditions, it looks like there is a function on line 819, apachesolr_search_conditions_default(), that could fit the bill.

function apachesolr_search_search_results($keys = NULL, $conditions = NULL, $search_page = NULL) {
  if (empty($search_page)) {
    $search_page = apachesolr_search_page_load('core_search');
  }
  if (empty($conditions)) {
    $conditions = apachesolr_search_conditions_default($search_page);
  }
  // Check our parameters
  if (empty($conditions) || empty($search_page)) {
    apachesolr_failure(t('Solr search'), $keys);
  }

Do you think this would work and not break anything else?

If you'd like me to roll a patch with this change, I'll be glad to do so. Let me know.

Thanks,
Paul

nick_vh’s picture

Please roll a patch, let the testbot do it's work and I'll try to do some additional testing when you post it.

paulmckibben’s picture

Status: Needs work » Needs review
StatusFileSize
new591 bytes

Thank you, Nick. Patch attached.

nick_vh’s picture

StatusFileSize
new1.15 KB

Made a patch that is a bit more logical. No need to run checks twice. Can you verify this one is working also?

Status: Needs review » Needs work

The last submitted patch, 1419290-5.patch, failed testing.

nick_vh’s picture

Status: Needs work » Needs review
StatusFileSize
new1.38 KB

Testbot? Why u no love me no more

Status: Needs review » Needs work

The last submitted patch, 1419290-7.patch, failed testing.

paulmckibben’s picture

Status: Needs work » Needs review

Nick, thank you! This patch applies cleanly for me, the code makes sense, and it works fine. I don't know why the testbot is choking on it. I can only assume there's something wrong with the testbot.

I'll click the re-test link and see if it passes this time.

paulmckibben’s picture

#7: 1419290-7.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, 1419290-7.patch, failed testing.

nick_vh’s picture

Status: Needs work » Patch (to be ported)

Committed

nick_vh’s picture

Version: 7.x-1.0-beta15 » 6.x-3.x-dev
Sabareesh’s picture

1419290-7.patch worked fine for me. Thanks nick_vh.

nick_vh’s picture

Status: Patch (to be ported) » Fixed

Committed to 6.x-3.x, thanks!

nick_vh’s picture

Status: Fixed » Closed (fixed)