Best practice for blueprint options in plugins?

Kirby 2 Solved ✅
1

When using blueprint options in a plugin some keys are already used by the panel, like type and label.

Yesterday I also tried to use template and content as blueprint plugin options but it did not go that well. What do you think is best practice for options in a blueprint with a plugin?

Is this a good idea?

fields:
  some_field:
    label: Some field
    type: some_field:
    options:
      template: a_template
      content: Some content

Here I use options as a kind of prefix / namespace to prevent the plugin options to mess with panel stuff.

2

Here is a list of all keys that are used by the BaseField class. If these keys are used in the blueprint, they overwrite the values.

You can use any key with your own field, but if you base yours on BaseField, you have to respect its defaults.

Regarding your idea: While that works, it isn’t how it’s supposed to work. options is generally used for field options (like select, checkboxes etc. fields) and also you nest the options that are normally on the top level in other fields.

3

I see now that I’m quite an expert on trying to use the protected ones.

Thanks for the list. It will probably be very helpful! :slight_smile:

1 Like
4

I found out that even more fields than the ones from the list are protected, for example:

echo $this->template();

(inside a panel field)

5

Well, template() is a method, that’s defined below the property list. You can however directly call __call('template') which will get you around this issue.

6

Ahh, yeah, or at least:

echo $this->__call('template', null);
7

Oh, sure. Sorry about that.

8

$args does not seems to be used. If so, maybe remove it?

public function __call($name, $args) {
  return isset($this->{$name}) ? $this->{$name} : null;
}
9

The _call method always takes two arguments, that’s PHP magic. We could remove it, but I think we should keep it everywhere to be consistent.

1 Like