Over-aggressive inference in the yaml parser

Kirby 2 Solved ✅
1

Consider this structure:

----
variations:
-
  colour_id: 3105
  colour_hex: AD3431
  colour_name: RED
-
  colour_id: 5001
  colour_hex: 1E4477
  colour_name: BLUE

and this template code:

<?php $variations = $page->variations()->toStructure(); ?>
<?php foreach ($variations as $var): ?>
  <?= $var->colour_hex() . "<br />"; ?>
<?php endforeach; ?>

The “1E4477” colour_hex value is internally cast to float which outputs “INF”. This is definitely not expected. Others are being processed just fine.

FYI: I have tested with ->yaml() as well, but got the same result (expected). So it’s probably somewhere in the SPYC class as they both seem to use this internally?

I have already filed an issue on github, but decided to post it here too because I hope someone sees a way to workaround this temporarily?

2

What happens when you access the value?

<?php $variations = $page->variations()->toStructure(); ?>
<?php foreach ($variations as $var): ?>
  <?= $var->colour_hex()->value() . "<br />"; ?>
<?php endforeach; ?>
3

Output is also “INF”.

4

Have you entered the values via the Panel? The panel wraps this value within quotes. Should work then?

1 Like
5

True, this works then. I import them (not via kirby). Let me fix that in the import script. Thanks @texnixe!

Edit: To me, this still feels like a bug somehow. Where ever I check the Kirby docs etc I don’t see quotes? What is your opinion?

6

The Panel saves different kinds of input in different ways in structure fields, for example, it makes a difference if you just store a single word or multi-line text. In the same way, it handles different sorts of input, it seems, I don’t really know for what reason, if this is sort of automatic or to work around some issues. Maybe it’s just the way it is when input is yaml encoded (at least using that library). Do you use Kirby’s yaml::encode when you save to file?

1 Like
7

No, I’m using a python script. In my experience that’s a lot faster.

8

Alright, that probably explains it then. However, I’d leave the issue open on GitHub, let’s see what the devs have to say.

9

The input you want to save here really is an edge case for hex color values.
I would assume that nothing will change in the parser because 1E4477 is a valid floating number as for the specs.
And the only way to let the parser know that this is a string is using quotes or the multiline syntax as @texnixe mentioned.

colour_hex: "1E4477"
colour_hex: >
  1E4477
1 Like