When a search query is aborted at some point in the code, SearchApiQuery::execute() currently uses error_displayable() to determine whether the associated error message should be displayed. However, this just depends on the global “Error messages to display” setting which really is not appropriate there, as a lot of abort messages are actually user-facing.
The big problem here is that currently such error (or exception) messages can be either internal or user-facing and we have no way of distinguishing between the two. While most sites will not want to display a raw error message coming from Solr to end users, messages like the Content Access processor’s “You have no access to any results in this search.” are definitely meant to be displayed to end users. Currently, in either case, most sites will just display an empty result set, leaving the visitor confused.

Potential solutions I see:

  1. Always display error messages that are TranslateMarkup, use error_displayable() to determine whether to also display strings.
  2. Add an option “Display error messages” to the Views query settings, maybe also with an additoinal field for making exceptions based on regular expressions. (So, you could display everything by default, but hide messages that contain the String Exception as a heuristic detection of internal messages.)
  3. Add a flag to abort() to specify whether the message is internal or external. Maybe also introduce a flag to SearchApiException for the same purpose. (This could be useful in other scenarios as well.)

I think all of these would in some way break backwards compatibility, or at least that would be hard to avoid, so we should deliberate carefully how to proceed.

Comments

drunken monkey created an issue.