YAML attribute capital letter?

[ctuxboy]

In the docs and theme examples there using yaml-meta-attributes in the md-files starts with a capital character, however when trying show a attribute then it only shows the meta-attributes start with a capital letter in the twig-file. I see a lot of themes using the capital letter in the YAML headers, but using lowercase letters on the twig-files.

Example:

md-file:

---
Title: Test
Address: Straat 34
City: Nieuwpoort
Postcode: 8620
Coordinates: 123, 456
Template: dogzone
---

Twig-file dogzone.twig:

<p>{{ meta.Coordinates }}</p>
<p>{{ meta.Postcode }}</p>

When using lowercase characters, it doesn't show the above YAML-attributes:

<p>{{ meta.coordinates }}</p>
<p>{{ meta.postcode }}</p>

When using lowercase attributes in the YAML-header and also in the twig-files then all works perfect!

What is the best 'convention'/safest solution? All lowercase? Or start the attributes with a capital letter?

[mayamcdougall]

So, there's two things happening here.

First, you can use a pico-theme.yml file in your theme to define your metadata properties. Check out the Default Theme's pico-theme.yml to see what this looks like.

Basically, you can use the meta section there to define the extra properties you'd like. In the Default Theme, these are Logo, Tagline, and Social. On the Twig side of things, these become meta.logo, meta.tagline, and meta.social. You're basically just defining aliases for them as Pretty Name: variable_name. The don't have to match either, but the typical practice is to just use the lowercase version of the same word.

Using pico-theme.yml in your theme folder is the proper way of handling your extra metadata properties...

But, the second thing you're seeing though is that most older themes don't have a pico-theme.yml, but they still have capitalized metadata. This is due to PicoDeprecated, Pico's backwards compatibility plugin, noticing that these themes are old and running them in a compatibility mode. If I remember correctly, this is because older versions of Pico didn't treat metadata as case-sensitive.

Finally, in some of my personal work (like the themes I linked before), you'll see me just standardizing on lowercase. This is just because I tend to build over-complicated arrays of metadata, since I like to add tons of customization to things.

I'll use structures in my metadata like this (from some contact page settings):

contact:
  title: Contact Me
  divider: star
  subtitle: Or Reach Me At
  subdivider: star
  disabled: true
  form:
    enabled: true
    action: /url.php
    method: POST
  items:
   - title: Phone
      icon: mobile-alt
      content: (555) 555-555
      link: tel:555555555

Which would be really complicated to read without that indentation. But, unfortunately pico-theme.yml doesn't support nested items like this, so I'm stuck using lowercase. 😂

[ctuxboy]

@mayamcdougall , Thanks a lot man for this clear answer. Like you good explenations :-) I learn a lot! Okay, the best way, using lowecase metadata!

At the moment, testing for best practices, and i have 500+ pages with the same metadata (dozones, city and province), adding some example/helper-comments in my config.yml, so when adding a new dogzone.md, i can copy the metadata (removing the comments). Maybe also a tip for other Pico users: some metadata is required, so adding '@@@', so when adding a lot of dogzones, searchin all the md-files for '@@@', so i know where some data is missing ;-)

But i see you work with more complex metadata structures, so i will testing/experimenting with such structures :-)

### YAML POST TYPES ###
#
# DOGZONE TYPE
# ---
# title: @@@
# address: @@@
# city: @@@
# postcode: @@@
# coordinates: @@@    # lat, long
# tags: @@@           # weide, bos, zwemvijver, strand
# omheining: @@@      # 0/1 (false/true)
# agility: @@@        # 0/1 (false/true)
# parking: @@@        # 0/1 (false/true)
# zitbank: @@@        # 0/1 (false/true)
# afvalbak: @@@       # 0/1 (false/true)
# hondenpoepbuis: @@@ # 0/1 (false/true)
# closed: @@@         # 0/1 (false/true)
# private: @@@        # 0/1 (false/true)
# opp: @@@            # ha
# links:
#     @@@: @@@        # naam x: link x
# media:
#     @@@             # "%assets_url%/image-x.jpg"
# notes:
# date: @@@           # Adding date ex. 13/02/22
# update: @@@         # update ex. 15/03/22
# author: @@@
# template: dogzone
# SEO/Social
# description: @@@    # meta description
# keywords: @@@
# ---
#
# CITY TYPE
# ---
# title: @@@
# postcode: @@@
# coordinates: @@@    # lat, long
# notes:
# template: city
# ---
#
# PROVINCE TYPE
# ---
# title: @@@
# coordinates: @@@    # lat, long
# notes:
# template: province
# ---

By example, this is the yaml-metadata for dogzone-name.md:

---
title: @@@
address: @@@
city: @@@
postcode: @@@
coordinates: @@@    # lat, long
tags: @@@           # weide, bos, zwemvijver, strand
omheining: @@@      # 0/1 (false/true)
agility: @@@        # 0/1 (false/true)
parking: @@@        # 0/1 (false/true)
zitbank: @@@        # 0/1 (false/true)
afvalbak: @@@       # 0/1 (false/true)
hondenpoepbuis: @@@ # 0/1 (false/true)
closed: @@@         # 0/1 (false/true)
private: @@@        # 0/1 (false/true)
opp: @@@            # ha
links:
    @@@: @@@        # naam x: link x
media:
    @@@             # "%assets_url%/image-x.jpg"
notes:
date: @@@           # Adding date ex. 13/02/22
update: @@@         # update ex. 15/03/22
author: @@@
template: dogzone
# SEO/Social
description: @@@    # meta description
keywords: @@@
---

[mayamcdougall]

Okay, the best way, using lowercase metadata!

I mean... 😓

The proper way is to use pico-theme.yml, but I seem to have accidentally given you a better idea. 😅

It does sound like your large dataset might benefit from just using lowercase though. 😉

(And that's a lot less work than defining each and every property in pico-theme.yml. Ultimately, it's for your own use, so it doesn't really matter how you approach it. That's what makes Pico so great. 😁 )

Also, using nested variables can help immensely when writing your Twig (even though it's not the "proper" way to handle metadata). It can really help you keep things organized.

From my example above (shortened):

contact:
  title: Contact Me
  divider: star
  form:
    enabled: true
    action: /url.php
    method: POST

In Twig, this becomes {{ meta.contact.title }}, {{ meta.contact.form.action }}, {{ meta.contact.form.method }} and such. This example comes from one big index.md file, so having these variable "organized" like this is a lifesaver. 😉

(Though, in my real code, I have the index page saved in a variable and I reference everything like {{ index.contact.form.action }}, etc).

some metadata is required, so adding '@@@'

I do the same thing when I need to remember to come back to something later while I'm working. Usually a ### or <--. Just something easily searchable that I know won't show up anywhere else in that file. 😉👍🏻

[ctuxboy]

@mayamcdougall , You give me inspiration building nicer structures, also where save my 'dummy'-templates :smiley: Adding a hidden dir and md-files for the templates:

theme/_templates
  dogzone.md
  city.md
  province.md

, if you have suggestions about my template/screenshot, shoot :wink:

It is indeed a better way, give the yaml metadata structure (see screenshot).

Maybe a suggestion: adding a 'cookbook'-page in the picocms-docs with nested variable structures and how render in twig, when see how your index.md is structured, i think you can do a lot with metadata structures, but hard to find the results in the twig-templates. Anyway it is awesome what you build :blush:

PS: now i know how integrate emoji :laughing:

[mayamcdougall]

Maybe a suggestion: adding a 'cookbook'-page in the picocms-docs with nested variable structures and how render in twig

Idk... I think @PhrozenByte would probably frown at me convincing more people to make overcomplicated metadata structures instead of doing things "properly"... 🤔 😂

Not sure about adding it to the current cookbook (which needs some work... also, do we even link to this anywhere? I had to look up the url). I did just add this to my notes for my ongoing / eventual Documentation Rewrite, since it does seem like a good "advanced tip". 😁

Glad it's working out for you! ❤️

---

By the way, I'd been wondering before if dogzone was some kind of translation oddity that I wasn't aware of... but then I saw on your Twitter that you are in fact documenting zones for dogs. 🐶

So, very cool. That seems like an admirable goal. 😁👍🏻

[ctuxboy]

Idk... I think @PhrozenByte would probably frown at me convincing more people to make overcomplicated metadata structures instead of doing things "properly"... 🤔 😂

:satisfied: but, it would be useful, or only some 'basic' structures :smirk:

Not sure about adding it to the current cookbook (which needs some work... also, do we even link to this anywhere? I had to look up the url). I did just add this to my notes for my ongoing / eventual Documentation Rewrite, since it does seem like a good "advanced tip". 😁

:open_mouth: first time i see this cookbook, thats really nice, didn't know this page existed!

Glad it's working out for you! ❤️

Thank you!

By the way, I'd been wondering before if dogzone was some kind of translation oddity that I wasn't aware of... but then I saw on your Twitter that you are in fact documenting zones for dogs. 🐶

So, very cool. That seems like an admirable goal. 😁👍🏻

Yes indeed and thx :pray:

I don't know how this names in english, so choose 'dogzones' :yum: My goal/challenge is build a platform find dogzones for dogowners. In the first time adding all the dogzones, but i'm not so happy with the first version. I have another idea rebuilding this project: a fullscreen (leaflet)-map and geolocation.

[mayamcdougall]

My girlfriend and I just got a dog recently, a Dachshund/Yorkie mix or "Dorkie" (sounds like "Dorky": nerdy, geeky, etc 😂). So, we're joining the ranks of the dog parents, lol.

I don't know how this names in english, so choose 'dogzones' 😋

I don't think there is an English word specifically for dog areas, so that works, lol.

It sounds like you'd probably need some Javascript in there at some point if you're doing an interactive map. Random tip in case it helps: I learned recently that I could export Twig variables to Javascript easily using <script> tags.

Anything you print inline (eg <script> var something = {{ some.pico.variable }};</script>), will get evaluated by Twig before Javascript (obviously, since JS is in the browser). It wouldn't be any good for secure information, since it's printed right in the HTML source, but for public stuff it should work. Just something I thought to share, since you're building that big YAML dataset.

I'm not a JS developer though, so I don't know much more about it than that. Suppose the |json_encode filter could also be helpful to share data in JSON format (let me know if it comes to that though, since the next_page/previous_page variables on each page cause a pesky recursion error when trying to dump page data with it).

Anyway, just some randomness. Shutting up now. 😅

[ctuxboy]

A nerdy doggy :laughing: , ah a dog it is very cute to have, and it is always happy :smiley: We have a Labradoodle since jan 2021, also a mix. So the idea for my the dogzone-project, comes when searching for dogzones. It is hard to find dogzones, and not all the local-goverment-sites published this info, so the project (dogvalley.be) was born :blush:

It sounds like you'd probably need some Javascript in there at some point if you're doing an interactive map. Random tip in case it helps: I learned recently that I could export Twig variables to Javascript easily using Githubissues.

Githubissues is a development platform for aggregating issues.