<p>This looks like a bug to me too. Here are the search terms and generated queries:</p>

<pre><code>'pølser OR pålegg' -
   SELECT * FROM `craft_searchindex` WHERE (MATCH(`keywords`) AGAINST('pølser palegg' IN BOOLEAN MODE)) AND `elementId` IN (3,18,21,22,23,24)

'"pølser" OR "pålegg"' -
   SELECT * FROM `craft_searchindex` WHERE (`keywords` LIKE '% pølser or %') AND MATCH(`keywords`) AGAINST('+palegg' IN BOOLEAN MODE) AND `elementId` IN (3,18,21,22,23,24)

'"egg" OR "spekemat"' -
   SELECT * FROM `craft_searchindex` WHERE ((`keywords` LIKE '% egg %') OR MATCH(`keywords`) AGAINST('spekemat' IN BOOLEAN MODE)) AND `elementId` IN (3,18,21,22,23,24)
</code></pre>

CC BY-SA 3.0
2014-07-03T21:52:14.823Z
Looks like a bug with multibyte strings in the search query parser. Thanks for posting that – I’ll look into it.
Brandon Kelly
CC BY-SA 3.0
2014-07-03T23:26:55.350Z
Yep… fixed for the next release!
Brandon Kelly
CC BY-SA 3.0
2014-07-04T05:14:39.240Z
Nice answer Marion!
Anna_MediaGirl
CC BY-SA 3.0
2014-07-03T21:39:28.817Z
2014-07-03T21:39:28.817Z
Marion Newlevant
<p>There seems to be a bug when I combine non-ascii characters, quotes and the OR operator when searching. </p>

<p>All of these queries work ok: </p>

<ul>
<li>"pølser"</li>
<li>"pålegg"</li>
<li>pølser OR pålegg</li>
<li>"egg" OR "spekemat"</li>
</ul>

<p>but</p>

<ul>
<li>"pølser" OR "pålegg" </li>
</ul>

<p>always returns no result. </p>

<p>The search form uses roughly this code: </p>

<pre><code>{% set searchTerm = craft.request.getParam('search') %}

{% set entries = craft.entries %}

... entries is optionally limited to a single section here, but it makes no difference here ... 

{% set entries = entries.search(searchTerm) %}
</code></pre>

<p>Any ideas? </p>

<p>Cheers!</p>

<p>(cross-posted from google+ group as I only just found out about the stack-exchange)</p>

<p>(edit to add code sample)</p>

CC BY-SA 3.0
2014-07-03T06:40:25.027Z
Does rebuilding the search indexes help?
Marion Newlevant
CC BY-SA 3.0
2014-06-18T14:56:47.410Z
You mean when searching entries with `ElementCriteriaModel`? Would you mind adding an example code snippet for context?
Matt Stein
<search>
Bug with non-ascii characters, quotes and OR operator in search?
# Bug with non-ascii characters, quotes and OR operator in search?

(Asked by: username_0 on 2014-06-18)

There seems to be a bug when I combine non-ascii characters, quotes and the OR operator when searching. 
All of these queries work ok: 

"pølser"
"pålegg"
pølser OR pålegg
"egg" OR "spekemat"

but

"pølser" OR "pålegg" 

always returns no result. 
The search form uses roughly this code: 
{% set searchTerm = craft.request.getParam('search') %}

{% set entries = craft.entries %}

... entries is optionally limited to a single section here, but it makes no difference here ... 

{% set entries = entries.search(searchTerm) %}

Any ideas? 
Cheers!
(cross-posted from google+ group as I only just found out about the stack-exchange)
(edit to add code sample)

**Tags:** search

> **Comments:**
> **username_2**: You mean when searching entries with `ElementCriteriaModel`? Would you mind adding an example code snippet for context?  
> **username_1**: Does rebuilding the search indexes help?  

---

## 1 answers

### Answer by username_1 on 2014-07-03. Score: 6 | Accepted answer

This looks like a bug to me too. Here are the search terms and generated queries:
'pølser OR pålegg' -
   SELECT * FROM `craft_searchindex` WHERE (MATCH(`keywords`) AGAINST('pølser palegg' IN BOOLEAN MODE)) AND `elementId` IN (3,18,21,22,23,24)

'"pølser" OR "pålegg"' -
   SELECT * FROM `craft_searchindex` WHERE (`keywords` LIKE '% pølser or %') AND MATCH(`keywords`) AGAINST('+palegg' IN BOOLEAN MODE) AND `elementId` IN (3,18,21,22,23,24)

'"egg" OR "spekemat"' -
   SELECT * FROM `craft_searchindex` WHERE ((`keywords` LIKE '% egg %') OR MATCH(`keywords`) AGAINST('spekemat' IN BOOLEAN MODE)) AND `elementId` IN (3,18,21,22,23,24)

> **Comments:**
> **username_3**: Looks like a bug with multibyte strings in the search query parser. Thanks for posting that – I’ll look into it.  
> **username_3**: Yep… fixed for the next release!  
> **username_4**: Nice answer Marion!  

---

