Reuse only an options list in multiple fields

The CMS Questions
1

Hello, I am trying to find out how I could reuse a single options list for multiple fields. Imagine the following options list (very shortend version)

options:
  nix:
    de: Keine Auswahl
    en: No selection
  text-0-700rem: 0.70rem (11,2px)
  text-0-710rem: 0.71rem (11,36px)
  ....

This list is used in very many locations, same for color, paragraph lists and I think it would make so much sense to create text, color and paragraph option lists once and import them where needed. How could this be done in Kirby 4 and 3? I’ve searched but haven’t found anything yet.

Thank U

2

See for example: http://getkirby.test/docs/reference/panel/fields/select#dynamic-options

3

@texnixe, thank U very much 4 the link.
Please let me ask one more question. How would U create the query to fetch the complete “options:” part from the site.yml blueprint file for example?

tabs:
--contentfooter:
----columns:
------- width: 1/4
--------sections:
----------footer:
------------type: fields
------------fields:
--------------footer_background_color:
----------------label:
------------------de: Footer Hintergrundfarbe
------------------en: Footer background color
----------------type: color-palette
----------------unselect: true
----------------width: 1/1
----------------size: small
----------------options:
------------------bg-blue-100:
--------------------background: "#D2EAF6"
--------------------border: "#D2EAF6"
--------------------text: white
--------------------tooltip: Blau 100
------------------bg-blue-200:
--------------------background: "#A5D5ED"
--------------------border: "#A5D5ED"
--------------------text: white
--------------------tooltip: Blau 200
4

Wait a minute, you wouldn’t query it from the blueprint, but from the field values. What is color-palette, seems to be a custom field, no idea how this field stores its data.

And please, post your code with three backticks before and after a block, like so:

three-backticks-800x

And without those dashes all over the place. Thank you.

5

I’m sorry, I just saw your new post. color-palette is a installable extension for kirby. I’m possibly thinking to simple. My thought was to just fetch the options list, no matter what kind of content, take the delivered string and just write it at the defined location.

It’s easy to get exactly the options needed as a json string like in this example:

$site()->blueprint()->field(‘footer_background_color’)[‘options’]

Unfortunately the PHP example doesn’t “translate” to a working query in a blueprint file.

What would be very nice, if “importing” yml files like this:

fields:
  section_background: fields/section_background

could be somehow be extended/made functional to something like:

options:
  background_colors: options/background_colors
6

What I don’t quite understand is why you cannot simply reuse the whole field instead of just the options?

7

@texnixe, thank U for your patience. The reason I’m after a possibility to just load the options list is because the colors or widths, heights and more, are settings for sections, columns, paragraphs, card backgrounds which can all reside on one page. Take a card, maybe the card background should be blue, one section of the card red and another section white. Before adding the background color list three of four times to a blueprint, I think it would make more sense to fetch the list everywhere it’s needed. When fetching content and displaying it in snippets and blocks I need to be able to distinguish between the settings. Of course, the way I do that may be very optimisable.

8

What you could do:

Given a select field:

fields:
  mySelector:
    type: select
    options:
      type: query
      query: site.getSelectOptions

Then create a custom site method in a plugin

'siteMethods' => [
    'getSelectOptions' => function() {
        return [
	        'design' => 'Design',
                // ...
		];
	}
],

Instead of returning a hard-coded array, you can get this options from anywhere, including blueprints defined somewhere in the blueprints folder. So this could also return

site()->blueprint()->field(‘footer_background_color’)[‘options’]
9

@texnixe, I don’t understand everything, but I will certainly give your suggestion a intense look and try. Thank U very much for your time and thoughts. I will report how my implementation went along. All the best and best success

10

Hi, it certainly works with fields of type “select”. It doesn’t work with the color-palette extension (yet…). It will certainly make all other constantly used “select” fields with text sizes, weight and so on very much more manageable.
:hugs::hugs::hugs::hugs: @texnixe

11

Hi, I got something working, which suites my needs. I found Programmable blueprints | Kirby CMS, thanks @texnixe, which support fetching the necessary “options” for any other blueprint from the site.yml file.
For anybody who constantly needs the same colors in a color-palette and intends to use TailwindCSS class names as the value which is added to a template, this could be of help.
One place to manage, mutliple places to apply. I followed the instructions in the mentioned cookbook and came up with the following code which resides in /site/plugins/programmable-blueprints/blueprints/fields/cardbgcolors.php.

<?php
$fields = [];
$fields['card_background_color'] = [
  'label' => 'Card Hintergrundfarbe',
  'type'  => 'color-palette',
  'options' => site()->blueprint()->field('footer_background_color')['options'],
  'unselect' => true,
  'width' => '1/2',
  'size' => 'small'
];
$back = [
  'type'   => 'group',
  'fields' => $fields,
];
return $back;

Including programmed blueprints in another blueprint.yml file worked out best for me with an entry like:

card_background_color: fields/cardbgcolors

As suggested in the cookbook, “extends: fields/cardbgcolors” doesn’t seem to work, when multiple programmed blueprints should be included in one blueprint file.

fields/cardbgcolors is defined in this file:
/site/plugins/programmable-blueprints/index.php
Some code:

<?php

use Kirby\Cms\App as Kirby;

Kirby::plugin("cookbook/programmable-blueprints", [
  "blueprints" => [
    "fields/cardbgcolors" => function ($kirby) {
      return include __DIR__ . "/blueprints/fields/cardbgcolors.php";
    },
    "fields/cardtitlecolors" => function ($kirby) {
      return include __DIR__ . "/blueprints/fields/cardtitlecolors.php";
    },
    "fields/cardtextcolors" => function ($kirby) {
      return include __DIR__ . "/blueprints/fields/cardtextcolors.php";
    },
    "fields/textcolors" => function ($kirby) {
      return include __DIR__ . "/blueprints/fields/textcolors.php";
    },
  ],
]);
12

But here you then extend the complete field again, which I suggested right from the beginning and which also works right in your yaml blueprints without the PHP versions… And why did you turn a single field into a field group? Or is this just shortened?

13

Hi @texnixe, yes, that is true. Now I realize what U mean, it didn’t click. Trying to find a solution where only one single point of truth exists for defining colors for the color-palette extension, which can be used in any other blueprint “blinded” me somehow. With programmable blueprints a complete new field is created and all new fields fetch color-palette color definitions, options from one field in the site.yml file. My idea was to prevent having redundant lists of definitions which, when something changes, all need to be updated. This is now achieved. On a over complicated path? Yeah, but working. Can it be optimized? I would bet on that. At the moment it’s okay for me. Once again, thank U for your ideas. Without, I would probably still be experimenting…:+1::smiling_face: