Importing blueprint stopped working (Grav 1.8)

Support Forms & Blueprints
,
1

I wrote a very simple plugin, tabs, that basically just ships a JS file and enables its use via a partial template and a partial blueprint. This way, the user (as in, developer using the plugin) can decide how/where to use it exactly.

The plugin hence comes with:

  • templates/partials/tabs.html.twig
  • blueprints/partials/tabs.yaml

In the past, I was able to import that partial blueprint like this, for example:

title: Tabs
extends@: default
form:
    fields:
        tabs:
            type: tabs
            active: 1
            fields:
                tabs:
                    type: tab
                    title: ā€œTabsā€
                    import@:
                        type: partials/tabs
                        context: blueprints://

The way I got Grav to pick up the pluginā€™s blueprints is via this method in the Pluginā€™s PHP file:

public function onGetPageBlueprints(Event $event)
{
    $types = $event->types;
    $types->scanBlueprints(ā€˜plugin://ā€™ . $this->name . ā€˜/blueprintsā€™);
}

This stopped working - not sure when. But it doesnā€™t work in Grav 1.8.

I tinkered a little and noticed that changing the import@ statement like this gets it to work again, and apparently I can then ditch the function in the tabs.php file entirely, which is nice:

import@:
    type: partials/tabs
    context: plugins://tabs/blueprints

But it seems less clean of a solution to have the user be required to specify the location of the partial blueprints so explicitly, including the plugin name in this case.

Is this just how it works in 1.8, or is there some other stuff Iā€™m not aware of? Whatā€™s the ā€œcorrectā€ way to handle providing partial blueprints for import via a plugin in 1.8?

2

@domsson, If your blueprint stopped working after upgrading to 1.8.x and works again after downgrading to 1.7.x, I would suggest to open an issue on Github.

Please keep this forum updated of any progress.

3

Gotcha. Currently donā€™t have a 1.7 system setup, but if I find the time, I shall try that! In the meantime, Iā€™m very much curious as to what the proper, intended way of going about this is for recent version(s) of Grav.

4

@domsson, Wanted to test your plugin on my latest Grav 1.7.x version, but the reported server error still persistsā€¦

Try running $ composer update inside your plugin folder, and the autoload will be created. This is how plugins are generated using the Devtools plugin.

Using composer is also mentioned explicitly in the Grav 1.7 upgrade docs: Use composer autoload

5

Oh, thatā€™s weird - it works for me since I removed the autoload() from tabs.php - I thought not depending on anything would make the whole Composer stuff optional, but I guess not. A bit confusing to me, all that - I have never used Composer.

I guess Iā€™ll add that back in again; though it will take a bit to get it all set up. The machine where I currently poke at this has neither Composer nor git installed. Will have to set up and use an entirely different machine. Looks like Iā€™ve opened a bit of a can of worms here for myself.

Wondering at this point if it is easier to simply keep a repo with a little collection of some blueprint and template files around, instead of turning something as small/simple as this into a plugin.

Anyway, thank you. Iā€™ll update here once I get a chance to set up and fix/test accordingly.

6

@domsson, Not sure if thatā€™s the problem, but your blueprint still mentions v0.1.0.
Your changelog mentions v0.2.1 and not v0.3.0 thoughā€¦

Maybe you should ping Andy on the Grav repo about your plugin not being updated.

7

@pamtbaau Ah, sorry for another ping, but I just realized: you probably tried v0.1.0 from the GPM, not the newest commit from the repository, correct? In which case, that might explain why the server error is gone for me, but not for you.

8

@domsson, I used the latest version from the GPM, as every/most user(s) of your plugin wouldā€¦

In my previous comment I assumed your latest ā€œreleaseā€ was not picked up by GPM yet.

9

Right, thank you for confirming! That, at least, is one problem solved (or at least not breaking stuff immediately) for now. The GPM hasnā€™t picked up on the newest version because apparently I didnā€™t tag stuff correctly, which is another issue.

But at least I can now go back to wondering about the initial question - how to properly enable the inclusion of partial templates via a plugin.

10

@domsson, When using Grav 1.7.49.5, your blueprint is not being importedā€¦

However, when using the following code, it works:

import@:
  type: partials/tabs
  context: plugins://tabs/blueprints

image
image634Ɨ467 14.3 KB

The docs for import@ mentions the following:

By default, blueprints:// resolves to /user/plugins/admin/blueprints/ therefore please note that if you are working in the context of a theme, you would need to adjust the context of your import statement :

form:
  fields:
    images:
        type: section
        title: Images
        underline: true
        import@:
          type: partials/gallery
          context: theme://blueprints

I guess the same applies to a pluginā€¦

1 Like
11

Interesting. I could swear I had this working on a 1.7 install - but maybe Iā€™m misremembering and it was actually a 1.6 one. Very much possible, my memory is a mess!

Either way, yeah, thatā€™s the way I managed to get it to work as well, and I get the feeling thatā€™s probably the way to do it. Feels a little wrong to have to hard-code the plugin name, but then again, being able to remove some of the PHP that scans the blueprints is kind of neat.

I guess Iā€™ll just roll with this - if anyone ever comes across this and knows better, please do let us know. :slight_smile: