Blueprints in Plugins for Kirby3

In Kirby2, I have some plugins that provide custom blueprints. I would like to rework these plugins for Kirby3. Unfortunately the blueprints defined in a plugin do not appear in the list of available blueprints when adding new pages.

To break its down, I created a simple test plugin. So the following in a clean installation of plainkit doesn’t work as expected:

site/plugins/test-plugin/index.php

<?php
Kirby::plugin('steirico/test-plugin', [
    'blueprints' => [
        'my-blueprint-from-file' => __DIR__ . '/blueprints/pages/my-blueprint-from-file.yml',
        'my-blueprint-from-array' => [
            'title' => 'my-blueprint-from-file',
            'preset' => 'page',
            'fields' => [
                'title' => [
                    'label' => 'Title',
                    'type' => 'text'
                ],
                'text' => [
                    'label' => 'Text',
                    'type' => 'textarea'
                ]
            ]
        ]
    ]
]);

site/plugins/test-plugin/blueprints/pages/my-blueprint-from-file.yml

title: my-blueprint-from-file
preset: page
fields:
  title:
    label: Title
    type:  text
  text:
    label: Text
    type:  textarea

Do I miss something or is it a bug?
Thanks a lot!

Are you allowing pages with this blueprint to be created in the blueprint where you expect this to show up? I tested your code, all good.

wasn’t it supposed to be:

'pages/my-blueprint-from-file' => __DIR__ . '/blueprints/pages/my-blueprint-from-file.yml',

1 Like

It’s not really necessary for the blueprint to show up and be used. But if you want to extend that blueprint, yes, you have to add the foldeer, otherwise, the blueprint will not be found.

That’s a good point.

The docs don’t give any information on how to differentiate blueprint types in plugins. Putting my page blueprint in the pages/ folder was a guess derived from the blueprint introduction

I’ll add that to the reference/plugins section. It’s not required to put blueprints in subfolders, but it makes sense, of course, unless your plugin only has a single blueprint.

Thanks! Obviously, I had to allow site/pages using the blueprint.

But it seems, the blueprint is not taken into account correctly.

I enriched my test blueprint as follow:

title: my-blueprint-from-file
preset: page
fields:
  title:
    label: Title
    type:  text
  intro:
    label: Intro
    type:  textarea
  description:
    label: Description
    type:  textarea

Adding a page based on this blueprint leads to a form with one textarea field, only. The file my-blueprint-from-file.txt appears in the content folder but the file content does not correspond to the blueprint:

Title: Intro

----

Text: Intro text....

Hm, I just spotted that you use the same title for your blueprint-from-file and the blueprint-from array, I guess that’s interfering.

But I just tested without that array, and if I use pages/my-blueprint-from-file I can’t create the page, and without pages, all I get is a standard page preset blueprint.

So there seems to be something wrong.

Thanks for double-checking. I removed the array blueprint, too.:wink:

Shall I open an issue on Github and reference this thread?

Yes, could you do that please?

That would be nice. Could you post the link here? I also have this problem for some time. I guess I cannot link to my slack-msg from here, so I might add a sample of how I did it in my plugin to your issue, maybe that helps solving it.

I can’t reproduce that the blueprint doesn’t show up on the list of available templates, and I wasn’t using the create attribute to make it appear. The thing I can reproduce is that the fields don’t appear and no matter if I use a preset or not, all I ever get, is a default page preset layout, while the text file gets the correct blueprint name. Very weird.

I think, the problem is related to the plugin’s blueprint definition.

I prepared the following files to include in the Github issue:

site/plugins/test-plugin/index.php

<?php
Kirby::plugin('steirico/test-plugin', [
    'blueprints' => [
        'pages/my-blueprint' => __DIR__ . '/blueprints/pages/my-blueprint.yml'
    ]
]);

site/plugins/test-plugin/blueprints/pages/my-blueprint.yml

title: my-blueprint
preset: page
fields:
  intro:
    label: Intro
    type:  text
  text:
    label: Text
    type:  textarea
  description:
    label: Description
    type:  textarea

While using these files, the form showed up correctly and the content file is correct, too.

After all, the problem might be related to the missing prefix pages/ in my previous examples.

@texnixe: Could you test/reproduce that, please?

I just copied my plugins blueprint to the kirby-blueprint dir and renamed it. Doing so it appears in the list of blueprints within the panel, but as you mentioned, whativer I do, I get the default-blueprint.

I did some further tests and I came to this conclusion:

The prefix is compulsory in order to get the blueprint registered correctly. e.g. 'pages/my-blueprint'

Not sure if this applies to other blueprint types as well.

As far as I remember I finally did my tests with the pages prefix, but I’ll double-check again later.