Color field: options query support

[distantnative]

This PR …

Features

• Color field: query and API support for options

myColorField:
  type: color
  options:
    type: query
    query: kirby.option('my.colors')

When passing an options array, keep in mind that keys will be used as the color values and the corresponding array value as preview text (for associative arrays, simple arrays are all color values only).

Ready?

• Unit tests for fixed bug/feature
• In-code documentation (wherever needed)
• Tests and checks all pass

For review team

• Add changes to release notes draft in Notion
• Add to website docs release checklist (if needed)

[lukasbestle]

@distantnative Could you please add examples to the XSS lab in the sandbox (basically copying the examples for the other options fields) to ensure that we never accidentally introduce XSS? Options fields are always a bit tricky here.

[bastianallgeier]

Something is weird. I cannot get a single setup in the lab running for some reason. @distantnative Could you post your test blueprint setup here?

[distantnative]

@bastianallgeier that's already included in the first post here. use it together with e.g. this config option

	'my' => [
		'colors' => [
			'#3e3e3e',
			'#aaa',
			'#ddd',
		]
	]

[bastianallgeier]

So weird. I must have had a typo somewhere. I tried the blueprint and added my own config options for it, but it didn't work the first time. Now it's all fine.

[lukasbestle]

@distantnative I have added the various "options" configurations for the color field to our XSS sandbox and discovered some bugs:

Actual bug

• I couldn't get the field to use an associative array from a query. So if I modify your example here to use keys with labels, those labels aren't used and just the color value is taken. If I do it like you write in the changelog snippet ("When passing an options array, keep in mind that keys will be used as the color values and the corresponding array value as preview text"), the field doesn't render at all.
  To reproduce: "Color (query, defaults)" field in the XSS sandbox

Consistency issues compared to other options fields

• String templates are not parsed in hardcoded options. They weren't before this PR and it doesn't change anything about hardcoded options, but I think it's confusing that color is now an options field but without the same options support in the blueprint.
  To reproduce: "Color (hardcoded 1)" to "Color (hardcoded 3)" fields in the XSS sandbox
• Text of hardcoded options is not rendered as HTML; all other options fields except select (which cannot render HTML) do this
  To reproduce: "Color (hardcoded 1)" field in the XSS sandbox
• The {< >} placeholders are not supported for options from query and API, instead they render a blank label; again a consistency issue with the other options fields
  To reproduce: "Color (API, with HTML)" and "Color (query, custom HTML query)" fields in the XSS sandbox

---

I think it would also be good to add PHPUnit tests for the new options features to the ColorFieldTest.

[distantnative]

I'll try to take a look at the examples to better understand your comments.

I think the first one is that if your return direct PHP for an option this has to be already in the correct format (as with other parts in Kirby, e. g. programmable blueprints). So no magic rewriting form associative array. But I'll need to have a closer look on that.

The second part I don't quite understand. Where and why should the color field now render HTML?

[lukasbestle]

I think the first one is that if your return direct PHP for an option this has to be already in the correct format (as with other parts in Kirby, e. g. programmable blueprints). So no magic rewriting form associative array. But I'll need to have a closer look on that.

Hm, then maybe I misunderstood the release notes snippet from the first post. I've also tried returning ['text' => '#aaa', 'value' => 'Some label'] as an option, but the result was the same (color is used, but label is ignored). Am I doing it incorrectly?

The second part I don't quite understand. Where and why should the color field now render HTML?

The labels for all options fields except select support HTML rendering. Given that the color field is now essentially an options field, I think it would make sense to also support it here for consistency.

[distantnative]

I think we still need to look at the context of the field and still dont see why and how HTML would make sense for the color field here, similarly to how it's not for the select field.

[lukasbestle]

The only reason why the select field does not support HTML is that the <select> input cannot render HTML. But the label in the color input can, just like the other options fields.

[lukasbestle]

Another thing I thought about is the flipped text and value props. With an associative array those allow to use the same key/value structure as with the hardcoded options, but with more complex data or customized queries it's IMO really confusing that the color code is the text and the label the value.

Maybe it was a mistake to make the labels the keys in the hardcoded options. Was there a technical reason why we did it that way and not like "#aaa": Label?

[distantnative]

I also wondered if that was a mistake, but I don't think we could easily change this now, or do you have an idea?

Let's continue here: #6101
I easily overlook discussions in merged PRs/closed issues