A typical select field with a set of predefined options looks like this:
Each option has a value that is stored in the content file and a text label that is displayed for the user in the Panel.
The advantage of this setup is that your text label can change without affecting the stored value and can be translated depending on the user's language.
If you output the field content in your templates, however, you usually don't want to render the raw saved value, but rather some modified representation, in many cases the text label you assigned in the blueprint.
Let's look at different ways to achieve this.
You could, of course, use a simple field setup like this:
In this case, what is shown to the user in the Panel and what is stored in the content file will be exactly the same. This works fine as long as you don't want to translate the text label or provide any context information.
With a more complex version of that setup, you can still save the desired output value but display translated text labels:
But all this is not very versatile and only makes sense in a single language installation. Therefore, let's see how we can stick with the first setup above and still get a more useful output than the key as value.
A typical solution is to set up a "category map" in your
config.php where you connect values to output strings:
You can name this array whatever you like, of course, to reflect what it contains.
In your template, you can fetch the value from this array like this:
If the value doesn't exist in the array, we fall back to an uppercased version of the field value.
In a multi-language installation, you can store your key/value fields in the
translations array in your language files:
And then fetch the value using the
Again, we use a fallback for values that do not exist in the
The last two versions are already much more versatile, but you might end up defining the same sets of key/value arrays in your blueprints and then again in the `config.php or language files.
Instead, you can also read the options' text labels directly from the blueprint.
We add the fallback value here just in case someone stores a value from outside of the Panel.
You can find more examples how to access information from blueprints in our "Using blueprints in the frontend" recipe.
The same principles can be applied to other fields that use options like the
radio field, the
multiselect field, the
tags field or the
To finish this, let's have a look at how to handle multiple options stored as a comma separated list, for example from the