Importing blueprint stopped working (Grav 1.8)

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?

@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.

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.

@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

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.

@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.

@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.

@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.

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.

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. 🙂