I am creating posts for my plugins to make it easier to find them using the forum search and not just the docs search.
This plugin introduces two new ways to define blueprints for Kirby 4. (yes 4+ only)
Fluent & Named Helper Classes
Define blueprints in PHP files with the fluent definition or named parameter definition instead of just the array definition that Kirby provides. You can use the*::make()-helpers to create them and avoid typos.
Define blueprints for pages in PageModels and use public properties with PHP attributes to define fields. You will gain auto-completion and insights on hover for the fields in your templates.
site/plugins/example/models/ArticlePage.php
#[
Label([
'en' => 'Introduction',
'de' => 'Einleitung',
]),
Type(FieldTypes::TEXT),
]
public Field $introduction;
Benefits of using this plugin
You could alternatively use another plugin by @lukaskleinschmidt to create type-hints based on your regular Kirby setup but that would mean you need to update them on every code change. With my plugin you can define your fields in the PageModel and instantly have code-completion in your templates. Hovering the property name will, in most IDEs, show you the attributes you did set for easy reference.
You could reduce the risk of typos and get auto-completion if you use my Schema for Kirby’s YAML Blueprints. But using the *::make()-helpers and the PHP attributes will get you code-completion and type-safety within the blueprints themselves and in the rest of your PHP code (the PageModels, controllers, templates, …).
Why should you care about PHP based blueprints? As the excellent cookbook by @texnixe points out you can react dynamically on the state of your kirby installation.
many popular plugins use the same technique to show fields or sections depending on context of your page. like @tobimori 's seo plugin
my favorite use case is showing/hiding fields depending on the role of the user which complements the bouncer plugin, default when-conditionals or when-query plugin nicely.