Access select label in section info

[dgsiegel]

Hi!

I’ve created a blueprint for a talk, featuring a select element:

fields:
  type:
    label: Session Type
    type: select
    options:
      breakout: Breakout Session
      focus: Focus Talk
      lightning: Lightning Talk
      workshop: Workshop
[...]

In an overview, I want to show all talks, featuring an info with the date and type of the talk:

info: "{{page.type}} // {{ page.date.toDate('D d M Y') }} {{ page.time.toDate('H:i') }}"

But this only uses the keys set in the select field (e.g. lightning). Is there a way to access the label instead of the key?

[texnixe]

Options:

Multiselect doesn't store values but the keys

You can’t store the values, unless you use your values as keys in your blueprint. options: "Interactive": Interactive "Print": Print # etc. Edit: if this doesn’t work, there is the long version below. 2. You can get the values from the keys via the $page->blueprint() method. 3. You could alternatively store your key-value pairs in an array in your config and fetch via the options() helper.

Example for option 2:

Select field's key/value

That would be dump($page->blueprint()->field('hosts')['fields']['host']['options']['apple']);

Example for option 3:

In config.php:

return [

    'session_types', => [
        'option1' => 'Some title 1',
        'option2' => 'Some title 2',
        'option3' => 'Some title 3'
    ]
];

In template:

<?= option('session_types')['option1'] ?>

Where you would replace option1 with $page->type()->value().

[dgsiegel]

Option 2 and 3 are hard to use inside a blueprint (especially the info section), but Option 1 looks great. Thanks!

[texnixe]

Option 3 is the most versatile though, especially when used in a multi-lang environment (where this mapping would go into the translations) and doesn’t require reading the blueprint.

[dgsiegel]

How would this look like when referring to it in an info line inside a section?

[texnixe]

Ah, I completely missed that info stuff. But it’s doable if you create a custom field method, that fetches the value.

[dgsiegel]

Right, then Option 1 is still the easiest

[texnixe]

@dgsiegel

Right, then Option 1 is still the easiest

Yes, but not very versatile. If you later regret your wording, you would have to change the blueprint and all your already stored values.

That is definitely an advantage of option 3 compared to the other options.