I've been looking through the forum, it seems there's a few methods to retrieve a tags page but I'm looking for the most efficient method (both speed- and template-wise).

  1. Using tag.name with tag token (routes), which utilises the original article template for rendering.
  2. Using tag.slug
  3. Using tag.title and search()

I think #2 is the simplest and prettiest solution, but it's relatively undocumented as far as I can tell. Also, I'm using two tag groups and, although I've mentioned to my client to not add duplicate tags (e.g. { 'group 1': 'stress' } { 'group 2': 'Stress' } I'm interested to know the following:

  • Is #2 the most optimised solution?
  • Can it be used with a tag token route?
  • Will duplicate tags accross tag groups cause conflicts?

In my tests using #1 (the urls are ugly in my opinion), Depression seems to return no results, perhaps because there is already a depression tag in another tag group.

Ideally, I want one place for all tags, without having to create two different routes for both tag groups.

1 Answer 1


Ok, so I'm tenatively answering my own question — although I'd like someone to shed light on the duplicate tag problem — it seems like a combination of #1 and #2 works quite nicely, although I haven't extensively tested it yet.

{% if tag is defined %}
  {% set tag = craft.tags.slug(tag).first() %}
  {% set entries = craft.entries.section('articles').relatedTo(tag) %}
{% else %}
  {% set entries = craft.entries.section('articles') %}
{% endif %}

{% for entry in entries %}
{% endfor %}

This is working with the route articles/tag/[tag token] set up. The only issue is when a tag that has a duplicate slug, whether that be within the same tag group or a different one, it returns no results (I'm not great at reading logs, but it doesn't seem to throw any errors either).

Any additions to this answer would be appreciated!

  • I believe this would solve your "duplicate tag issue": Change {% set tag = craft.tags.slug(tag).first() %} to {% set tags = craft.tags.slug(tag) %}, and then do {% set entries = craft.entries.section('articles').relatedTo(tags.ids()) %}. With your current code, the .first() tag returned might not actually have any related entries, in cases where there are more than one tag with the same name. Aug 11, 2016 at 13:33
  • @MatsMikkelRummelhoff Thanks for the tip, I think for now I'm just going to enforce no duplicates on my client. Yours sounds like a sensible solution, but the idea is to have two distinct tag groups — that method would display all articles, with no easy way of separating them into their groups. Right? I imagine two routes would be the only way to achieve this seperation, which is overkill for article tags.
    – Rob
    Aug 17, 2016 at 18:23
  • You can better see what I mean here and here.
    – Rob
    Aug 17, 2016 at 18:30
  • No disrespect, but the "no duplicates" thing doesn't really sound enforceable. Sooner or later, someone's probably going to add a duplicate tag and you're going to have a problem. IMHO, considering the two tag groups are distinct, it wouldn't be overkill at all to create two routes, it'd make sense. Assuming "Types of issues" and "Types of therapy" are your two tag groups, you could have routes like articles/therapy/{tag} and articles/issues/{tag} – much more semantic than just articles/tag/{tag}, and more future proof (perhaps in the future you'll have 3 or 4 tag groups). Aug 17, 2016 at 19:11
  • Since the two routes would obviously point to the same template, it'd be a minimal amount of work to set up, too – all you really need is to add a .group(tagGroupHandle) to your craft.tags query, where you pull the tagGroupHandle from the request URI (either by using a route token, or by looking at the relevant segment via craft.request). Aug 17, 2016 at 19:16

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.