With Kirby 4.1, the color field now has the option to work with queries. This is a great step in the right direction. It would be even more great if the color field now also supported key/value. For example, you could use the key field to save the name of the color instead of the hex or RGB value. Especially if you work a lot with frameworks like Bootstrap or Tailwind, it can sometimes make more sense to save class “text-primary” instead of the hex value, for example. Also easier for later site wide changes.
In combination with the query language, you could make colors globally available on all pages and change them dynamically. The whole thing could then be retrieved via queries in a similar way to the toggle field.
You can bypass the whole thing with the toggle field (see screenshot) but it doesn’t feel quite right yet.
Here is an example of what would be ingenious, based on the toggle field.
color:
type: color
mode: options
options:
- value: "text-primary"
text: "{{site.primary.value}}" // where by this is a color field in $site
- value: "text-danger"
text: "{{site.danger.value}}"
Or via a structure field
color:
type: color
mode: options
options:
type: query
query: site.colors.toStructure
text: "{{ item.name }}"
value: "{{ item.hex }}"
@Oliver.mayer not sure about your code examples though.
text-primary
would be the value to save, but the color code needed for the preview etc. certainly isn’t a text
either - the text is the text shown as side info on the field.
I’m thinking more along the lines of keeping the value: text
options notation of 4.1 and adding a store
option or so to define what to save.
color:
type: color
mode: options
store: text
options:
type: query
query: site.colors.toStructure
text: "{{ item.name }}"
value: "{{ item.hex }}"
That would of course also work. But to get more consistency, wouldn’t it make more sense to solve it like the other fields? I can see that my example above is the wrong way round. It should be like this:
color:
type: color
mode: options
options:
type: query
query: site.colors.toStructure
text: "{{ item.hex }}"
value: "{{ item.name }}"
Example of a structure field:
colors:
type: structure
fields:
hex:
type: color // for example #e74c3c
name:
type: text // vor example text-primary
With such a way you could define an awesome and flexible Color Palette you could site wide use.
But the hex isn’t just text, it’s the value of the color field. To me it doesn’t make a lot of sense to pour the color values into text
to put something else into value
. It’ll also make the field component really complicated as suddenly it needs to expect color values in both value
and text
option. That should be avoided.
I absolutely agree with you! That would indeed make it much more complicated. In this case, the “store: text” method would make perfect sense and might not be so complex to implement
The store
option sounds great! For me the color field doesn’t really work for options
at the moment since the chance of an exact color value to change during development or in in the future is too high.