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?
This can be reproduced on CiviCRM.org, which has both a search block and contribute pages.
- Go to https://civicrm.org/civicrm/contribute/transact?reset=1&id=1&action=preview
- Type "ponies" in the Drupal search box (top right)
ENTERand see fairly misleading error messages.
I haven't looked into it in depth, but I'd guess something like this:
- Drupal's Block Search form uses the current page callback to submit its form to.
- CiviCRM intercepts form submissions to
/civicrm/*, but can't handle form submissions in unexpected formats, so doesn't know what to do.
- 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
- 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.