Our Plone (5.0.7) site returns search results successfully, but when you search for anything using "and" or "or", it shows no results at all (please see attached screenshots.) This is an out-of-the-box site, with the exception of the addition of PloneFormGen and WebServerAuth.
. Updating to 5.0.8
..to no avail. Thanks for any insight you might have.
That's true. Thank you for pointing that out as well as suggesting some ways we could get this functionality.
I wonder though whether this is still a bug. Adding "and" to my example search still ought to return a number of documents, even if it's being interpreted as just another search term and not an operator, I'd think?
and and or are likely stop words (i.e. they are not indexed). If the search engine (ZCTextIndex in this case) does not treat stop words specially during searching, then using any of them in a search may give 0 hits.
Note that ZCTextIndex supports search operators AND, OR and NOT (and others), but you must spell them all uppercase. For details, see the docstring of Products.ZCTextIndex.QueryParser.
Guess: and and or might now be considered so called "stop word"s, i.e. not indexed. This would not be built into Plone but would be the responsibity of a "lexicon", the language authority used by a text index.
@dieter I think I expressed myself poorly. I wasn't trying to find documents with the word "or". I was trying to use it as a binary operator. For example, in Plone 4.3, when I type yellow or house in the search field, it returns documents that contain the word yellow or documents that contain the word house. In Plone 5.2, it returns nothing.
Plone implements its searches (by default) via ZCatalog. ZCatalog delegates search syntax to the respective indexes. For a full text index, this is likely a ZCTextIndex. For it, Products.ZCTextIndex.QueryParser defines the recognized syntax and its interpretation.
Following your message, I have reread this specification -- and, indeed, or should be recognized in any case, not just OR (as I wrote earlier). Thus, there may indeed by a bug.
Formerly, ZCTextIndex has had an independent distribution (Products.ZCTextIndex); nowadays, it is part of Products.ZCatalog. I have verified that in the current version, or should still be recognized case insensitively and that the implementation (in QueryParser.parseQuery) appears to implement it correctly. Thus, the error might be elsewhere.
At your place, I would check where the problem may have been introduced:
verify that your portal_catalog (indirectly) derives from ZCatalog
verify that the index used for full text searches (usually SearchableText or similarly spelled) is a ZCTextIndex