Just spotted that if you have a Drupal search block on eg a Contribution page, and try to use it, it will either take you back in to CiviCRM with a qf key (back to the last thing i modified i think), and for logged out (non permissioned) users they get a long message ending with "Error type: Could not find a valid session key". How does a Drupal search trigger this outcome?

  • I have seen this due to an http vs. https conflict. Don't recall how it was resolved though... Jul 8, 2015 at 19:07
  • thx - will check if the issue is only happening on https sites
    – petednz - fuzion
    Jul 9, 2015 at 0:38
  • seeing this on sites without https too.
    – petednz - fuzion
    Jul 10, 2015 at 2:28
  • It's reproducible on CiviCRM.org, which suggests that it's not a misconfiguration. Sep 7, 2015 at 0:52
  • I know it is not explicitly related to https but when I recently enabled it on a site, this started happening again. I tried changing everything to https AND base_url in drupal+civicrm and have not seen it since (but not holding my breath ) Sep 9, 2015 at 19:21

1 Answer 1


This can be reproduced on CiviCRM.org, which has both a search block and contribute pages.

  1. Go to https://civicrm.org/civicrm/contribute/transact?reset=1&id=1&action=preview
  2. Type "ponies" in the Drupal search box (top right)
  3. Hit ENTER and see fairly misleading error messages.

civicrm search error

I haven't looked into it in depth, but I'd guess something like this:

  1. Drupal's Block Search form uses the current page callback to submit its form to.
  2. CiviCRM intercepts form submissions to /civicrm/*, but can't handle form submissions in unexpected formats, so doesn't know what to do.
  3. Yellow Page of Malaise. (A play on WSoD here.)

My suggested dodgy workarounds are:

  • Add a form alter hook in CiviCRM, which identifies forms you use throughout the site and direct the form submit URLs elsewhere if the path contains /civicrm, OR
  • Do not show those blocks on those paths at all.

My wild clever idea solution is:

  • Make CiviCRM return Fatal errors using Drupal page callback rather than bombing out to the YPoM. This might permit Drupal to then do whatever redirect happens as part of the normal flow for Drupal forms.

My fantasy perfect solution is:

  • Destroy all HTML QuickForm.

This last is happening, albeit slowly. Please donate to CiviCRM, avoid implementing new functionality in QuickForm, and support any efforts to remove QuickForm or improve the codebase which you are able to.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.