Open timtorres opened 3 years ago
Hi @timtorres, the CMS does output valid yaml correct? It seems we follow this from the link you shared:
@erezrokah
It seems we follow this from the link you shared:
Perhaps, but something is still going wrong so maybe my solution wasn't 100% of the way there... I'm a newbie so just doing my best here, but this output may still be causing issues with the combination of it being in front matter and the note that was under your screenshot:
Note: Plain flow scalars are picky about the
:
and#
characters. They can be in the string, but:
cannot appear before a space or newline, and#
cannot appear after a space or newline; doing this will cause a syntax error. If you need to use these characters you are probably better off using one of the quoted styles instead.
So does that mean that the plain flow scalar won't work in front matter because of the :
appearing after the field name and before the value?
title: My >80 character title
Could be related to my comment in the forum post about my front matter values not being wrapped in quotes. If there's a way to force/configure that behavior then I will test it out.
True, I agree this is a valid use case, just making sure we're handling the correct use one.
Note: Plain flow scalars are picky about the
:
and#
characters. They can be in the string, but:
cannot appear before a space or newline, and#
cannot appear after a space or newline; doing this will cause a syntax error. If you need to use these characters you are probably better off using one of the quoted styles instead.
I think the yaml
library handles that. It's highly used so I think chances of it outputting invalid yaml
are very low.
We have to be careful with quoting and make sure we're not losing any type information (e.g. dates/numbers). Maybe there's an option to do the following:
Can you test if your site generator handles it? If so we could ask in the yaml
library repo.
We have to be careful with quoting and make sure we're not losing any type information (e.g. dates/numbers).
But for strings this wouldn't be an issue right?
Can you test if your site generator handles it?
Yep this works exactly how the result shows 👍
But for strings this wouldn't be an issue right?
True - we'll need to make sure we only quote strings (or use the >
format).
Hi, i'm new to decap and faced with this problem here.
Switch widget from "string" to "text" does not help.
I parse md files with java lib flexmark, and they support literal to use multiline values.
Decap does not generate a "|" but only creates new lines.
I think it is not save to parse this markdown files and seperate between "multiline" and "subfields in decap cms".
What is actual the solution to configure decap, to save strings or text in one line? My strings in frontendmatter will be between 120 and 160 characters.
thank you
Is your feature request related to a problem? Please describe. The YAML library that the CMS uses has a default line width of
80
when writing content to front matter (may apply in other cases). This causes an issue when using thestring
widget as it inserts a newline at the 80 character mark but does not use YAML folding, so plain text is inserted on its own line. This is known to break site builds on Hugo, Pelican, and probably others:Error: Error building site: "site/content/author/author-name/index.md:6:1": failed to unmarshal YAML: yaml: line 5: could not find expected ':'
Workarounds include switching to the text widget or using a max character count, but we shouldn't need to do that.
Describe the solution you'd like Remove the line wrapping feature or disable it on strings. It feels like an opinionated way of making your code look pretty when many people have other ways of doing this, ex: Prettier on VSC (which coincidentally has the same default, but won't break the YAML structure).
I think this won't happen based on feedback from @erezrokah on breaking existing content, but the full impact hasn't been explored yet.
Describe alternatives you've considered
Additional context Original forum post: String fields have newlines added to Markdown front matter