Bug with structure field?

Kirby 2 Solved ✅
1

Before I add this as an issue on Github I want to be sure that this is a bug.

“Yes” and “True” as text prints “1”

  • Look at the blueprint below. It says “Yes” at the end.
  • Look at the output. It prints “1” in the Panel.

Why change the text?

Why is this translated to “1”? A bug? “True” gives the same result. I did not expect that because it’s not a value, it’s a text.

Selectbox does the same

I tried to do the same thing on a select box and the same problem appears there as well.

Click the image to enlarge it.

Pasted image788×797 34.3 KB

2

This behavior is the same for non-structure fields as well. Is it a bug? Maybe.

1 Like
3

I think, that this is not a bug, because every checkbox in the panel only writes a 1 to the file. The text: descriptor is always only the information text displayed.

Also, it would not be a useful behavior to store the value of the text descriptor, if the checkbox is activated, because the text can be different in different languages.

4

Yeah, but this is not about the stored value (1 or 0), which is perfectly alright, but the text that is being displayed next to the checkbox, if the text is “yes”. But then again, it would make more sense to be a bit more explicit in the text label.

5

It’s an issue with the way YAML is parsed. In YAML, yes is translated to a boolean => true => 1. You should be able to avoid that by wrapping it in quotes.

6

Yes it works with quotes.

Descriptive texts are not values

Descriptive texts in the Panel are ment to be just describing texts of what is going on. They are not values, and will never be.

Fix it on the Kirby side?

It could be fixed on the Kirby side by adding quotes, if the descriptive text is a direct match with a boolean (true, false, yes, no).

Any pitfalls?

What could be the reason for not fixing this on the Kirby side? Could it add new bugs?

Add issue?

Should I add an issue?

7

It’s something that’s coming directly from the YAML parser. There are places where this makes sense, though I actually doubt that “yes” should ever be translated to true/1. But if you use the default option for fields, it often makes sense being able to pass a boolean.

8

I agree that it make sense when using it as values, but not as descriptive texts.

Maybe it requires some kind of preprocessing and then I can understand that it would be a hard one.

I’ll rest my case for now on this one.

9

I think changing the YAML syntax and implementing our own would be quite confusing. It wouldn’t be YAML anymore but something strange…