Support for “extended” fields

[AugustMiller]

Kirby supports global field definitions, meaning some blueprint files may not include the full definition for a particular data structure.

We either need to hook deeper into how the Panel builds Blueprints (or, Fields), or add our own merging strategy for any fields with an extends property.

At the moment, you can work around this by doing something like…

Architect::blueprint('fields/global-field')['options'][$option];

…to manually fetch the field definition, then dereference its various properties with the standard array syntax.

[jenstornell]

You have more stars than I do and it seems like yours are more stable. I'm considering to use yours instead and close mine.

This may help you with field definitions?

https://github.com/jenstornell/kirby-blueprint/blob/master/blueprint.php#L89

[AugustMiller]

Nice! This is a good starting point for one of the syntax options…

fields:
  field-key: extendable-field

…but we'll have to make sure we implement logic from the native Blueprint builder, here and here, in order to capture the alternative extends syntax:

fields:
  field-key:
    extends: extendable-field
    label: Custom Label
    # Etc…

I have some time this week to implement— I'll keep you posted!

[jenstornell]

Also, be aware of this:

https://getkirby.com/docs/developer-guide/plugins/registry

// Register set field
$kirby->set('blueprint', 'article', __DIR__ . '/blueprints/article.yml');

// Register set field definition
$kirby->set('blueprint', 'fields/title', __DIR__ . '/blueprints/fields/title.yml');

I used this to get all registered blueprints:

$blueprints = kirby()->get('blueprint');

https://github.com/jenstornell/kirby-revisions/blob/master/core/blueprint.php#L13

[AugustMiller]

This is a lot more complicated than I'd imagined— especially when we need to walk down through Blueprint constructs like the Structure field and its potential to use the extends directive within a subfield.

Overall, I'm more inclined to suggest something like the following, in the documentation:

Architect::blueprint('fields/subfield')['label']; # -> Extendable Field Label

The core blueprint method is not opinionated about the data it decodes, so you can use its results just like a standard array.

[jenstornell]

So you mean that by doing the above you tell the function that it's a field definition? That's really much better than nothing. It would work in many cases but at the same time you need to know how the blueprint is built to use it correctly. I'm I right?

[AugustMiller]

By virtue of the registry, this syntax (using the path as a blueprint name) works automatically.

In theory, you know how the blueprint is structured because it's checked in to the same version control repo— the developer should keep them in sync.

[jenstornell]

What is the status of this thing? I did not get the last comment.

[AugustMiller]

I don't think it's worth duplicating logic from the core to assemble extended blueprints. Instead, I'd like to suggest that the implementing developer use the above example to manually read the blueprint partial.

My comment about version control was only to say that I didn't want to introduce complexity into the plugin without first looking at ways to use the existing API.

If I have a blueprint like this…

# site/blueprints/monster.yml

title: Monster
pages: false
files: false
fields:
  title:
    label: Monster Name
    type: text
  languages:
    extends: languages # <- Extended field!
    label: Spoken Languages
    columns: 4

…with an extended field like this…

# site/blueprints/fields/languages.yml

label: Languages
type: checkboxes # <- Note that this is a `checkboxes` field!
options:
  abyssal: Abyssal
  aquan: Aquan
  auran: Auran
  # ...
  telepathy: Telepathy
  terran: Terran
  undercommon: Undercommon

…these two files are almost certainly checked in to my version control software, and deployed together. In addition, the template files, route config, one-off plugins, and any other PHP file where I may be using the Architect plugin are (hopefully) also tracked in the same repo…

foreach ( $page->languages()->split() as $language ) {
  echo Architect::blueprint('fields/languages')['options'][$language];
}

…so the developer knows when they need to reference a blueprint partial, and can fall back to basic array-accessor notation.