Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configure default line width for string widget #5640

Open
timtorres opened this issue Jul 25, 2021 · 6 comments
Open

Configure default line width for string widget #5640

timtorres opened this issue Jul 25, 2021 · 6 comments
Labels
area: formats type: feature code contributing to the implementation of a feature and/or user facing functionality

Comments

@timtorres
Copy link

timtorres commented Jul 25, 2021

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 the string 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

  1. Implement YAML folding to keep this feature but not have it break sites. Seems like it'd be very easy
  2. Allow configuration on the string widget to remove or increase the limit

Additional context
Original forum post: String fields have newlines added to Markdown front matter

@timtorres timtorres added the type: feature code contributing to the implementation of a feature and/or user facing functionality label Jul 25, 2021
@erezrokah
Copy link
Contributor

erezrokah commented Jul 25, 2021

Hi @timtorres, the CMS does output valid yaml correct?
It seems we follow this from the link you shared:
image

@timtorres
Copy link
Author

timtorres commented Jul 25, 2021

@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.

@erezrokah
Copy link
Contributor

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:
image

Can you test if your site generator handles it? If so we could ask in the yaml library repo.

@timtorres
Copy link
Author

timtorres commented Jul 25, 2021

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 👍

@erezrokah
Copy link
Contributor

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).

@neo2k
Copy link

neo2k commented Aug 12, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: formats type: feature code contributing to the implementation of a feature and/or user facing functionality
Projects
None yet
Development

No branches or pull requests

3 participants