Yaml frontmatter #990
Yaml frontmatter #990
Conversation
|
Is that using strict yaml? |
|
Unfortunately not, to my knowledge serde_yaml currently only uses yaml-rust and not strict-yaml-rust. As soon as serde_yaml allows to use strict-yaml-rust as dependency or if a serde_strict_yaml emerges I'd expect this to be easy to migrate though. |
|
I would really prefer to have strict yaml only though but https://github.com/fralalonde/strict-yaml-rust doesn't seem maintained. Is there another crate? |
|
Nope, didn't find any crate apart from the unmaintained one you mentioned. So went for the "next best thing" which is at least maintained. |
|
I didn't mean to close all the PRs by deleting the branch :( |
er-vin
force-pushed
the
yaml_frontmatter
branch
2 times, most recently
from
8a2860f
to
f1de444
Compare
|
Do we wait for a maintained strict Yaml crate to appear? |
|
Need to rebase this once more I see, will try to do it next week. |
er-vin
force-pushed
the
yaml_frontmatter
branch
from
f1de444
to
3a6cc40
Compare
er-vin
force-pushed
the
yaml_frontmatter
branch
from
3a6cc40
to
5a9ecdd
Compare
|
this is great, I too have 18 years of content I'd like to move across :) |
er-vin
force-pushed
the
yaml_frontmatter
branch
from
5a9ecdd
to
7bd11fb
Compare
|
I hope this gets merged soon. Thanks @er-vin |
|
Bumping this to check if it will be merged soon. |
|
I'm curious: why not document something that may bring more people to use this software? |
|
I don't like YAML and personally think this is not a good feature but many people want it so I'm ok adding it (like themes). But adding it to the documentation means more people will use and will want to have YAML everywhere instead of TOML (config.yaml, theme.yaml etc) and it would make sense in terms of consistency. But I really don't want to ;( |
|
Well, here’s an idea: document it as a _migration feature_ and explicitly state the limitations and that it is meant only for onboarding older content.
Otherwise nobody will discover it and you’ll lose out on people like me (who have existing content and would like to use Zola without reformatting it) but who don’t dig into the internals of their engines. Which are likely the majority of Jekyll users...
Most people don’t care about the limitations of YAML. They just care that it’s easy to write, that their editor (and GitHub preview) support it and that their content can move across.
And many don’t want to learn TOML or use it extensively, because it is just harder to write (even I am OK with writing a config file, but don’t see myself switching to TOML for content). So having YAML for front-matter might be more then enough for attracting new users without adding too much attrition to possible migrations.
… On 28 Nov 2020, at 21:05, Vincent Prouillet ***@***.***> wrote:
I don't like YAML and personally think this is not a good feature but many people want it so I'm ok adding it (like themes). But adding it to the documentation means more people will use and will want to have YAML everywhere instead of TOML (config.yaml, theme.yaml etc) and it would make sense in terms of consistency. But I really don't want to ;(
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#990 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC73244RKXXPQVSU3GHKODSSFQ2PANCNFSM4MGEO7SQ>.
|
That's a good angle! |
Still, if we find a string we involve the TOML parser to make sure the content of said string would be a correct TOML date. In a pure TOML world this isn't exactly relevant, but this will come in handy when using a YAML deserializer. Signed-off-by: Kevin Ottens <ervin@ipsquad.net>
This will be necessary for the YAML frontmatter handling and corresponding unit tests. Signed-off-by: Kevin Ottens <ervin@ipsquad.net>
Signed-off-by: Kevin Ottens <ervin@ipsquad.net>
er-vin
force-pushed
the
yaml_frontmatter
branch
from
7bd11fb
to
26133e2
Compare
Signed-off-by: Kevin Ottens <ervin@ipsquad.net>
This is just a light update on purpose. There would be no point in pushing YAML too much, this is mainly here to help people with a backlog of posts to transition. Signed-off-by: Kevin Ottens <ervin@ipsquad.net>
er-vin
force-pushed
the
yaml_frontmatter
branch
from
26133e2
to
b43afd3
Compare
|
Thanks! |
* Accept dates presented as strings Still, if we find a string we involve the TOML parser to make sure the content of said string would be a correct TOML date. In a pure TOML world this isn't exactly relevant, but this will come in handy when using a YAML deserializer. Signed-off-by: Kevin Ottens <ervin@ipsquad.net> * Add serde_yaml and test-case dependencies This will be necessary for the YAML frontmatter handling and corresponding unit tests. Signed-off-by: Kevin Ottens <ervin@ipsquad.net> * Add YAML front matter handling Signed-off-by: Kevin Ottens <ervin@ipsquad.net> * Switch RawFrontMatter enum to wrap &str instead of String Signed-off-by: Kevin Ottens <ervin@ipsquad.net> * Update the documentation to mention YAML frontmatter This is just a light update on purpose. There would be no point in pushing YAML too much, this is mainly here to help people with a backlog of posts to transition. Signed-off-by: Kevin Ottens <ervin@ipsquad.net>
|
with this PR, I think I can switch from my Hugo + YAML front matter blog to zola ! thanks for the works, guy! |
This is an attempt at adding YAML front matter support to Zola. I'm carrying over 16 years worth of content which moved from Jekyll to Hugo and now to Zola. Obviously this makes it easier to have YAML support in the front matter.
This feature has been discussed in #317 already and I agree that YAML should be limited only to actual content and nothing more. This is mainly useful for legacy reason and for external tooling (mainly text editors) which tend to support properly only YAML in the front matter.