3

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!

5

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, 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.

|improve this answer|||||
  • 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 Feb 26 '16 at 16:50
  • It seems search might be slower according to Brad's comment here – Rob Feb 26 '16 at 17:00
  • @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 Feb 26 '16 at 17:04
  • Cool, I'll do that. There's no tag.slug on the docs, I've changed to <option value="{{ tag.title|kebab }}"> but is tag.slug an available option? It seems to work too. – Rob Feb 26 '16 at 17:13
  • 2
    @Rob Yes, tags have slugs. Will update the docs. – Brandon Kelly Feb 26 '16 at 17:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.