Using internal tags as a data property in routes.yaml


#1

Hello! Is it possible to use an internal tag as the data property in the routes section of routes.yaml? I want to pass a tag to use in a page template - I’ve done it successfully with public tags but not internal tags.

I’ve tried the shortform, where the ‘city’ tag is public:

routes:
  /: main
  /city/location1/:
    data: tag.city
    template: 
      - page-location

This works great with public tags and I can access it in the template using {{tag}}, but using this shortform doesn’t seem to allow for setting the visibility property (and therefore gives a 404 with internal tags). I’ve tried the longform:

routes:
  /: main
  /city/location1/:
    data: 
      city:
        visibility: visible
        type: browse
        resource: tags
        slug: city

But, while I can access {{city}} in the template, I can’t seem to do much with it; I can’t access it at all if I try it with an internal tag.

The reason I’m doing it is because I’m creating tag pages of internal tags, creating the URL of each tag page in the routes section of routes.yaml; but rather than hardcode a separate template for each tag page using #get I thought it would be better to reuse the same template each time and simply pass in the relevant internal tag each time.

Thank you for any help.


#2

There’s no such thing as visibility: visible, it’s public or internal, you also don’t need to set this, as internal tags are included in API responses by default.

I’d guess that where you’re going wrong is the slug for the tag. Internal tags usually have slugs that start with hash-, e.g. hash-city.


#3

Thank you very much for the speedy response Hannah! That’s certainly cleared some of it up for me. I’m still getting the 404 when I try the shortform with an internal tag, even with the ‘hash-’ before it. The longform gives me an object to use inside the template which I can access by using {{city}} but it doesn’t have any of the tag properties that I can access when I use the shortform (I wondered if it was an array, but I can’t seem to iterate over it either). I’m sure I’m missing something but I’m not sure what!


#4

Another related problem I’ve just encountered with using the data property is redirecting for collections. If I add tag.history to the collection mysite.com/city/history, it causes mysite.com/history to redirect to mysite.com/city/history.
Is there a better way of passing in tags (including internal tags) to templates for routes and collections in the route.yaml file? I’d really rather not have to hardcode a separate template for every single route and collection, as updating will be a nightmare!


#5

I’m sure what you want to do is possible, but I don’t really follow what it is you want. Can you explain what it is you’re trying to achieve?

It would also be really helpful to see the full routes.yaml file you have right now, with an explanation of what isn’t appearing correctly.

One thing I can clarify is that the data key creates a redirect by default, as that’s the most common use case. Using the long form allows you to disable the redirect


#6

Thanks Hannah - here’s my current routes.yaml file:

routes:
/: main
/london/st-pauls/:
data: tag.st-pauls
template:
- page-venue
/london/tower-bridge/:
data: tag.tower-bridge
template:
- page-venue

collections:
/blog/:
permalink: /blog/{slug}/
filter: tag:blog
template:
- index
/london/events/:
permalink: /london/events/{slug}/
filter: tag:london+tag:events
data: tag.events
template:
- index-london
/london/activities/:
permalink: /london/activities/{slug}/
filter: tag:london+tag:activities
data: tag.activities
template:
- index-london
/london/history/:
permalink: /london/history/{slug}/
filter: tag:london+tag:history
data: tag.history
template:
- index-london

taxonomies:
tag: /{slug}/
author: /author/{slug}/

Two main aims:

  • Use the same template (index-london) for london/activities, london/history, london/events etc. By using the tag filters I’m getting the correct collections of posts appearing fine (eg london/activities displays all posts tagged ‘london’ and ‘activities’), but in order to display the relevant tag’s feature image, display a relevant title (eg ‘London activities’ by accessing the name of the tags I’ve passed in), pull in the relevant tag’s description etc I thought I’d need to use the data property to pass in the relevant tag. Ideally I’d like to pass in both tags (‘london’ and ‘activities’) so I can use a city-agnostic template if I write about new locations.
    Problem: if I pass in ‘activities’ then /activities redirects to london/activities. If I pass in ‘london’ I get a weird URL - ‘/london/activities/activities/activities/activities/activities/activities/activities/’. If I use the longform (where you can set redirect: false) then I can’t seem to use the tag object (that’s passed into the template) in the same way as I can with using the shortform - I can’t access it’s name, slug etc

  • Each post also has an internal tag, which specifies the venue eg st-pauls, tower-bridge. Using the routes section of the routes.yaml file, I want to create tag pages based on each venue eg ‘st-pauls’ which lives at london/st-pauls (I’ve made these venue tags internal to keep the number of public tags to a reasonable number, otherwise I’ll need to create a new public tag for every venue). I’d obviously like to use the same template for every venue, so I thought I should pass the relevant venue tag to the ‘page-venue’ template, where I can then break the posts down by st paul’s activities, st paul’s history, st paul’s events etc by using #get
    Problem: Passing internal tags using the shortform produces a 404. Using the longform causes the same problem as above - I can’t seem to use the tag object (that’s passed into the template) in the same way as I can with using the shortform - I can’t access it’s name, slug etc

I hope I’ve explained it okay. I suspect that I’m making things overly complicated and probably missing some syntax; but in theory, it should be doable.

Thanks again


closed #7

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.