Sorry, we don't support your browser.  Install a modern browser

Color Field: Key/Value Option like Toggle Field

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 }}"
2 years ago

@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 }}"
2 years ago
1

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.

2 years ago

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.

2 years ago

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

2 years ago

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.

a year ago