YAML metadata tag/category-lists

[ctuxboy]

How adding tags/categories in YAML metadata, and how show it with twig? Inline? Or not? With or without brackets?

---
tags: tag-1, tag-2, tag3
---

---
tags: [tag-1, tag-2, tag-3]
---

---
tags:
  tag-1
  tag-2
  tag-3
---

What is the most efficient way?

[digitalinferno]

You can use inline value with comma and show it with a simple for:

{% for tags in pages[current_page.id].meta.tags %}
    {{ tags }}
{% endfor %}

This type of meta/tag, however, is just a sort of label that does not index anything, if you are interested in a system that allows you to see all your tags or articles connected to a specific tag you must use this plugin: picocms-tags a little bit old, but it works.

[mayamcdougall]

I'd have to double-check, but I'm 90% sure that your first example will just be read as a single string, and not an array. Your second and third examples should be okay though.

I think personally I'd go with this:

---
tags:
  - tag-1
  - tag-2
  - tag-3
---

But idk, maybe I just like the look of bullets. 😅

Whichever option you like best is fine. As far as I know, all YAML evaluates the same. There isn't one syntax that's better than the others. Readability is king, which I think tends to be the point of YAML. So whichever is easiest for you personally to read/write is best.

@vodkafilm's example works okay, though it could be shortened to:

{% for tag in meta.tags %}
  {{ tag }}
{% endfor %}

Since metadata for the current page is accessible via meta, you don't actually need pages[current_page.id] if you're looking at the current page.

But yeah, as @vodkafilm mentions, this won't provide any functionality on its own (like filtering by tag). You'd need to do that with either a plugin or some fancy Twig. Doing it in pure Twig would probably require a page reload and a Query String (the part of the URL that comes after a question mark?), but it's definitely doable with enough persistence.

(Coming from someone who's somewhat stubbornly done it before. 😂)

[ctuxboy]

You can use inline value with comma and show it with a simple for:

{% for tags in pages[current_page.id].meta.tags %}
    {{ tags }}
{% endfor %}

This type of meta/tag, however, is just a sort of label that does not index anything, if you are interested in a system that allows you to see all your tags or articles connected to a specific tag you must use this plugin: picocms-tags a little bit old, but it works.

Thanks for the help :smiley: I hoped there was an option filtering tags with Twig without plugin :confused: Looking picocms-tags, but it seems out-of-date(?), maybe not compatible with PicoCMS 2.x

[ctuxboy]

I'd have to double-check, but I'm 90% sure that your first example will just be read as a single string, and not an array. Your second and third examples should be okay though.

I think personally I'd go with this:

---
tags:
  - tag-1
  - tag-2
  - tag-3
---

But idk, maybe I just like the look of bullets. 😅

Whichever option you like best is fine. As far as I know, all YAML evaluates the same. There isn't one syntax that's better than the others. Readability is king, which I think tends to be the point of YAML. So whichever is easiest for you personally to read/write is best.

@vodkafilm's example works okay, though it could be shortened to:

{% for tag in meta.tags %}
  {{ tag }}
{% endfor %}

Since metadata for the current page is accessible via meta, you don't actually need pages[current_page.id] if you're looking at the current page.

But yeah, as @vodkafilm mentions, this won't provide any functionality on its own (like filtering by tag). You'd need to do that with either a plugin or some fancy Twig. Doing it in pure Twig would probably require a page reload and a Query String (the part of the URL that comes after a question mark?), but it's definitely doable with enough persistence.

(Coming from someone who's somewhat stubbornly done it before. 😂)

Thanks (again) for the useful info. Why you prefer 'dashes/bullets' for single list items? Yes i read a bit that dashes useful for multi-items? example:

---
products:
  - name: product 1
    description: text 1
  - name: product 2
    description: text 2
---

Or it is only for a clean Yaml-structure?

[mayamcdougall]

Why you prefer 'dashes/bullets' for single list items?

Just personal preference because of how it looks. It depends on the context for me. Since the tags are all single labels without any other information, I just find the dashes more easily readable. 🤷🏻‍♀️

When I see it, I think "Oh, this is a list!"

---
tags:
  - tag-1
  - tag-2
  - tag-3
---

Where as with this, I might look at it and think "Did I forget some information?" 🤔

---
tags:
  tag-1
  tag-2
  tag-3
---

"Was this supposed to be tag-1: some value?" 🤔🤔

But there's no "right" or "wrong" way to do things in yaml.

There's right and wrong syntax itself. Yaml is very picky about getting the indentation and syntax just right. But between the multiple choices of syntax, it usually doesn't matter as long as your data is being read correctly.

Yes i read a bit that dashes useful for multi-items? example:

---
products:
 - name: product 1
   description: text 1
 - name: product 2
   description: text 2
---

Yes, dashes can also be used for multiple items like this. The output will be slightly different though.

The tags output (with or without the dashes) will be the equivalent of this:

tags: [tag-1, tag-2, tag3].

While the "multi-items" example will look like:

products: [[name: product 1, description: text 1],[name: product 2, description: text 2]]

Each dash - denotes a new item, and each item now becomes an array full of items itself.

Hopefully that makes sense...

Yaml is somehow super simple, and super complicated at the same time. 🤦🏻‍♀️

Generally though, use whichever style syntax works right for you.

As long as YAML can understand what you wrote and outputs it the way you wanted, you're doing it right. 😉

[mayamcdougall]

Thanks for the help 😃 I hoped there was an option filtering tags with Twig without plugin 😕 Looking picocms-tags, but it seems out-of-date(?), maybe not compatible with PicoCMS 2.x

It looks like the most recent fork of that plugin is here: Pico-Tags.

Our Plugins Wiki is a mess right now. It turns out when you allow anyone to edit a wiki and add their own stuff to it... it gets very very messy over time. 😓

We'd really like to move everything to the Pico website instead... but that would involve us having to sort through all those plugins, making decisions on which versions were the "most maintained", and/or testing them for breakages. It hasn't been something that we've had time for, as we're just a small volunteer project.

Unfortunately, most of our plugins and themes get "contributed once, then forgotten". That's one reason I avoid plugins if I can. Old Themes at least are restricted to Twig, but old Plugins run right in PHP! 😰

Also, Twig I can debug, but I'm not a PHP developer so that makes trusting old plugins even harder.

---

As I said though, it is possible to do Tags in pure Twig (and I like to avoid plugins too 😉). The main hurdle would be that passing that data back to Twig would involve a GET request and a page reload.

If your goal is to just be able to click a tag and load a new page showing all the "search results" containing that tag, it'll work fine using only Twig.

And technically, the tag plugins would have this limitation too. The plugin only saves you from coding it yourself (and/or maybe has some small performance benefits).

If you wanted to achieve something that could do "live" changes/filtering, you'd need to come up with a solution using Javascript instead.

I feel like these Issues between you and @vodkafilm keep crossing over, lol. Over on #632, I was explaining how you could send a contact form without reloading via JS. (And that again, since Twig only runs when you're loading the page, you'd need JS for anything client-side).

I didn't share it before, but my very first Pico theme, Notepaper had a "Tag Cloud" feature. If you go to the demo site and click the two tags in the sidebar (it says "Tag Cloud"... even though there's only two tags 😂), you can get a feel for how Twig-only Tags would work. Clicking the tags sends you to a URL with a Query String, similar to how a search url works, which Twig then uses to filter only the pages with those tags.

The reason I didn't share it before is that I wrote it back in 2015 when I first discovered Pico. It's badly in need of rewriting. It works, but the code is very very messy and out-of-date. Also, it was written before Pico natively supported Query Strings, so it's got a mini-plugin that reads the data from the URL instead.

It's all very "janky". 😅

The code for that theme is all in one long, hard-to-read template with crazy if statements full of nested conditions and logic. I just kept adding features until it became too bloated to work on anymore. 😂

So while I can't recommend borrowing any code from it, it does have a working Twig-only "Tag Cloud" to prove to you that it can be done if you're determined. 😁 😒 😅

[ctuxboy]

Aha, thanks for the link to this tags-plugin, this looks indeed really better, installed and works perfect, really happy :pray: In the first place, i will adding tags and other metadata structured in dogzone.md, then test all the metadata in dogzone.twig. If all the things work, so can start migrate all the dogzones, cities and provinces to Pico :smiley:

I have the same mindset as you, try develop without plugins, however, sometimes i'm happy there are plugins in some usecases. Is one of the reasons interesting in Pico, all the things i can do by myself (and the help from the community :blush: ), it gives 100% control. But i'm also happy there are plugins like the user-role plugin, is also one of the idea's for dogvalley, give some users restricted access to the content.

So now try learn how all the things work, and when i have time, maybe i build also a plugin, i'm also interested in star-reviews, like/dislike, and a comments-plugin.

This cms is at the first place tiny and simple, but gives a lot of flexibility with the plugin-system, and that's the reason i'm so interested in Pico.

I didn't share it before, but my very first Pico theme, Notepaper had a "Tag Cloud" feature. If you go to the demo site and click the two tags in the sidebar (it says "Tag Cloud"... even though there's only two tags 😂), you can get a feel for how Twig-only Tags would work. Clicking the tags sends you to a URL with a Query String, similar to how a search url works, which Twig then uses to filter only the pages with those tags.

Very intersting your theme , it's the best way learn some things from others, really awesome what you build :smiley:

[digitalinferno]

@ctuxboy sorry, the right choise for tags management is Pico-Tags

[ctuxboy]

@ctuxboy sorry, the right choise for tags management is Pico-Tags

@vodkafilm test it , and works perfect :smiley:

[mayamcdougall]

I just look at things from the perspective of a theme developer. 😅

I don't like my themes to be dependent on plugins, especially knowing that most Pico plugins have an inconsistent lifecycle. They get abandoned, forked, continued, abandoned again, and continued again, lol. So I'd rather just implement things myself that way they're future-proof.

I've learned a little bit about keeping things maintainable since making NotePaper... and maybe some day I'll even go back and apply some of those lessons to it! 😅

(Being a little sarcastic here, since NotePaper is my oldest, most unmaintained Pico project. 👆🏻)

Glad that Pico-Tags plugin is working for you. 😉👍🏻

And yes, if you learn how to write Plugins, you'd be unstoppable with Pico.

(I'm unfortunately too stubborn to learn PHP myself, but I do know that Pico makes writing plugins really easy!)

[ctuxboy]

@mayamcdougall i understand your opinion, also trying addding no plugin or, if it to difficult developing myself , using a plugin temporaly or as plan b , so it gives extra flexibility to a cms like Pico without pressure :smiley: I my exist project, i do also a lot of coding by myself, without any plugin.

Plugins are awesome, but it is a pain for the most cms-systems if the plugins outdated, however i like it if there are plugins it gives extra flexibility if it needed :blush: