Kirby Panel and Blueprints
KB entry points
kirby://kb/scenarios/06-blueprints-reuse-extends
kirby://kb/scenarios/19-programmable-blueprints
kirby://kb/scenarios/53-panel-first-custom-field
kirby://kb/scenarios/54-panel-first-custom-section
kirby://kb/panel/reference-fields
kirby://kb/panel/panel-bundling-decisions
Required inputs
- Content model and required fields.
- Panel UX (tabs/sections/layout) and validation rules.
- Whether to extend an existing blueprint.
Minimal blueprint skeleton
title: Example
status:
draft: true
listed: true
fields:
title:
type: text
text:
type: textarea
Extends example
extends: pages/default
Common pitfalls
- Duplicating fields instead of using
extends.
- Implementing Panel UI logic in templates instead of blueprints or plugins.
Workflow
- Clarify the content model, required fields, and Panel UX expectations.
- Call
kirby:kirby_init and read kirby://roots.
- Inspect existing blueprints and patterns:
kirby:kirby_blueprints_index
kirby:kirby_blueprint_read
- Use Panel reference resources for field/section choices:
kirby://fields
kirby://sections
- Check plugin surface when custom Panel UI is needed:
kirby:kirby_plugins_index
kirby://extensions
- Search the KB with
kirby:kirby_search (examples: "blueprints reuse extends", "programmable blueprints", "custom panel field", "custom panel section", "panel branding").
- Implement minimal, convention-aligned YAML/PHP; prefer
extends and shared sections over duplication.
- Validate by re-reading the blueprint (
kirby:kirby_blueprint_read) and verifying frontend output with kirby:kirby_render_page when relevant.