Keys on Select Field Not Saved when a Key is 0

[jcohlmeyer]

Bug Description

Labeled value (from select fieldtype inside a grid) has no key value.

I would expect that the key would be accessible as {{ field:key }}

Statamic\Fields\LabeledValue {#2317 ▼
  #value: "Thursday"
  #label: "Thursday"
}

How to Reproduce

Try to get the key value from a select fieldtype.

Environment

Statamic version: 3.0.0.-beta-43

PHP version: 7.2.30

Install method (choose one):

• Fresh install from statamic/statamic

[twd3]

Might be duplicate of : #2066

[jasonvarga]

Did you try {{ field }}?

[jcohlmeyer]

That also prints the label, not the key.

[jasonvarga]

Looks like your label and key are the same though. What's in the blueprint file?

[jcohlmeyer]

My blueprint looks like this:

            -
              handle: day_to_show
              field:
                options:
                  - Sunday
                  - Monday
                  - Tuesday
                  - Thursday
                  - Friday
                  - Saturday
                  - Sunday
                clearable: true
                multiple: false
                searchable: true
                taggable: false
                push_tags: false
                cast_booleans: false
                type: select
                localizable: false
                listable: hidden
                display: 'Day To Show'
                width: 50

In the CP it looks like this:

In the content file it looks like this:

title: Site
data:
  logo: logos/TrinityLife-Logo-Complete-Yellow.svg
  notices:
    -
      title: Live
      background_colour: bg-red-600
      enabled: true
      notice: 'Gather online & watch the live stream service!'
      link: 'https://live.trinitylife.ca'
      day_to_show: Thursday

[jasonvarga]

Okay it's working as expected, except that options field in the CP is a bit weird.

When your values are zero indexed like that, it just saves a simple array - like you have in your YAML file.

Did you create the field through the CP or in the file?

[jcohlmeyer]

Ah. That makes sense. I created via the CP.

[jasonvarga]

Do you actually want those numbers to be the values?

I think if you start from 1 instead of 0, it'll actually save numbers.

[jcohlmeyer]

I do as I want to compare to {{ now | format:w }} and not make the user enter the day of the week as 0-6...

[jcohlmeyer]

This issue has not had recent activity and has been marked as stale — by me, a robot. Simply reply to keep it open and send me away. If you do nothing, I will close it in a week. I have no feelings, so whatever you do is fine by me.

Please keep this open. Also @robdekort I do consider this a bug.

[arthurperton]

I think the only way to solve these issues (see #3179 too) is to make both the keys and the labels mandatory. Then there will be no confusion about what the user meant.

Would that be an acceptable solution, to be added to v3.1?

It would also solve #346.

[jasonvarga]

I don't think that would solve anything. In this comment #2215 (comment) you can see that the values are all being defined anyway.

I think what might need to happen is to support an additional longer syntax for defining your options.

options:
  - 
    label: Sunday
    value: 0
  - 
    label: Monday
    value: 1
  - 
    label: Tuesday
    value: 2
  - 
    label: Wednesday
    value: 3
  - 
    label: Thursday
    value: 4
  - 
    label: Friday
    value: 5
  - 
    label: Saturday
    value: 6

[arthurperton]

Ah sorry if I wasn't clear. You're right, just making the keys and labels mandatory won't solve anything. Of course the code would have to be changed so that the array keys are always interpreted as the values. Also when they are 0, 1, 2, etc.

I really like your idea for an (additional) explicit syntax, as it is backwards compatible (since the old way is still supported) and also more intuitive when editing the yaml by hand. I'd also make it the default way for the select fieldtype to save the options.