<p>In your working example, you’re mapping <code>request.tags</code> to the <code>search</code> param, but in the non-working example, you’re mapping it to the <code>slug</code> param.</p>

<p>Those two params are handled in very different ways. <code>search</code> will do some normalization routines on the value, and perform a very loose search for those keywords (see <a href="https://craftcms.com/docs/searching">https://craftcms.com/docs/searching</a> for more details). But the <code>slug</code> param will actually look for an exact match.</p>

<p>So if <code>request.tags</code> is set to <code>"low confidence"</code> and you pass that value into a <code>slug</code> param, I have <em>complete</em> confidence that it will return zero results, since <code>"low confidence"</code> isn’t actually a valid slug (see what I did there?).</p>

<p>You would have slightly better luck passing <code>request.tags</code> through the <a href="https://craftcms.com/docs/templating/filters#kebab">kebab filter</a>, which will make the value look a little more like a valid slug. But the <code>search</code> param is probably a better bet unless you know for sure that <code>request.tags</code> is actually going to be a slug.</p>

CC BY-SA 3.0
2016-02-26T16:50:36.003Z
Ah that makes sense, I could add the kebab filter to the `{{ option.value }}` ... I guess there's a chance users could add odd characters as tags, but they'll be managed anyway. Performance wise, is `relatedTo` quicker than `search`? It's more specific using `relatedTo` but there are a few `and` conditions. Thanks Brandon!
Rob
CC BY-SA 3.0
2016-02-26T17:00:43.023Z
It seems `search` might be slower according to [Brad's comment here](http://craftcms.stackexchange.com/questions/1387/using-search-vs-relatedto-in-a-template#comment2230_1390)
Rob
CC BY-SA 3.0
2016-02-26T17:04:30.453Z
@Rob Yeah search will be a bit slower due to the added complexity. If you can be sure you've got the right slug value to begin with, the relatedTo+slug route is better.
Brandon Kelly
CC BY-SA 3.0
2016-02-26T17:13:11.560Z
Cool, I'll do that. There's no [`tag.slug` on the docs](https://craftcms.com/docs/templating/craft.tags), I've changed to `<option value="{{ tag.title|kebab }}">` but is `tag.slug` an available option? It seems to work too.
Rob
CC BY-SA 3.0
2016-02-26T17:15:58.507Z
@Rob Yes, tags have slugs. Will update the docs.
Brandon Kelly
CC BY-SA 3.0
2016-02-25T22:06:16.403Z
2016-02-25T22:06:16.403Z
Brandon Kelly
<p>I think I'm seeing a bug while using advanced search with <code>relatedTo()</code>. If I use a simple search, like this:</p>

<pre><code>{% set param = {
   order: 'RAND()',
   limit: null,
   search: "#{request.tags}"
} %}
</code></pre>

<p>It finds a tag like <code>low confidence</code> without any issue. However, using the code I have below throws no errors, but returns no results:</p>

<pre><code>{% set request = craft.request.getQuery() %}

{% set param = {
  order: 'RAND()',
  limit: null,
} %}

{% set param = craft.config.devMode or craft.config.staging
             ? param|merge({ group: 'testing' })
             : param|merge({ group: 'verified' }) %}

{% set relatedToParam = ['and'] %}

{% if request.tags %}
  {% set tagId = craft.tags.group('specialism').slug(request.tags).ids() %}
  {% set relatedToParam = relatedToParam|merge([{
    targetElement: tagId,
    field: 'tagsSpecialism',
  }]) %}
{% endif %}

{% if relatedToParam|length &gt; 1 %}
    {% set param = param|merge({ relatedTo: relatedToParam }) %}
{% endif %}

{% set users = craft.users(param) %}
</code></pre>

<p><s>I'm fairly confident it's not an issue with my code, as every other search combination is working.</s></p>

<h3>Update</h3>

<p>This is expected behaviour and requires proper hyphenated <code>slug-path</code> to work properly with <code>.slug()</code> in my code sample. See answer below!</p>

<relations><search><tags><slug><whitespace>
.relatedTo() not returning tags with spaces
# .relatedTo() not returning tags with spaces

(Asked by: username_0 on 2016-02-25)

I think I'm seeing a bug while using advanced search with relatedTo(). If I use a simple search, like this:
{% set param = {
   order: 'RAND()',
   limit: null,
   search: "#{request.tags}"
} %}

It finds a tag like low confidence without any issue. However, using the code I have below throws no errors, but returns no results:
{% set request = craft.request.getQuery() %}

{% set param = {
  order: 'RAND()',
  limit: null,
} %}

{% set param = craft.config.devMode or craft.config.staging
             ? param|merge({ group: 'testing' })
             : param|merge({ group: 'verified' }) %}

{% set relatedToParam = ['and'] %}

{% if request.tags %}
  {% set tagId = craft.tags.group('specialism').slug(request.tags).ids() %}
  {% set relatedToParam = relatedToParam|merge([{
    targetElement: tagId,
    field: 'tagsSpecialism',
  }]) %}
{% endif %}

{% if relatedToParam|length > 1 %}
    {% set param = param|merge({ relatedTo: relatedToParam }) %}
{% endif %}

{% set users = craft.users(param) %}

I'm fairly confident it's not an issue with my code, as every other search combination is working.
Update
This is expected behaviour and requires proper hyphenated slug-path to work properly with .slug() in my code sample. See answer below!

**Tags:** relations, search, tags, slug, whitespace


---

## 1 answers

### Answer by username_1 on 2016-02-25. Score: 5 | Accepted answer

In your working example, you’re mapping `request.tags` to the `search` param, but in the non-working example, you’re mapping it to the `slug` param.

Those two params are handled in very different ways. `search` will do some normalization routines on the value, and perform a very loose search for those keywords (see <https://craftcms.com/docs/searching> for more details). But the `slug` param will actually look for an exact match.

So if `request.tags` is set to `"low confidence"` and you pass that value into a `slug` param, I have *complete* confidence that it will return zero results, since `"low confidence"` isn’t actually a valid slug (see what I did there?).

You would have slightly better luck passing `request.tags` through the [kebab filter](https://craftcms.com/docs/templating/filters#kebab), which will make the value look a little more like a valid slug. But the `search` param is probably a better bet unless you know for sure that `request.tags` is actually going to be a slug.

> **Comments:**
> **username_0**: Ah that makes sense, I could add the kebab filter to the `{{ option.value }}` ... I guess there's a chance users could add odd characters as tags, but they'll be managed anyway. Performance wise, is `relatedTo` quicker than `search`? It's more specific using `relatedTo` but there are a few `and` conditions. Thanks Brandon!  
> **username_0**: It seems `search` might be slower according to [Brad's comment here](http://craftcms.stackexchange.com/questions/1387/using-search-vs-relatedto-in-a-template#comment2230_1390)  
> **username_1**: @username_0 Yeah search will be a bit slower due to the added complexity. If you can be sure you've got the right slug value to begin with, the relatedTo+slug route is better.  
> **username_0**: Cool, I'll do that. There's no [`tag.slug` on the docs](https://craftcms.com/docs/templating/craft.tags), I've changed to `<option value="{{ tag.title|kebab }}">` but is `tag.slug` an available option? It seems to work too.  
> **username_1**: @username_0 Yes, tags have slugs. Will update the docs.  

---

