How to use import@ in form section of plugin blueprints.yaml

Support Plugins
1

Hi,

I’m creating a custom Plugin for an XMPP onboarding Process. And my form config in the blueprints.yaml is getting very big. Is there a way to externalize parts of the form?

I already tried import@ as described in Advanced Blueprint Features | Grav Documentation but it doesn’t seem to work for the admin form

2

for flex i use it a lot like this


    ps8:
      type: section
      import@8:
        type: quark/blueprints/geneller/menu
        context: themes://

idk about plugin blueprints.yaml

1 Like
3

Thanks, that worked.
I was missing the following rules:

  • you must(?) use a section for the import
  • you must(?) define the type with the folder name of your plugin as root, then all down to the blueprints file (server.yaml) excluding the suffix!
    • tested: or you set context: plugins://xmpp then you define type relative to your plugin directory. (I prefer that :smiley: )
  • it must(?) be a number in import@1, using a string does not work e.g. import@db

this worked for my plugin xmpp to include the file
$grav_root/user/plugins/xmpp/blueprints/partials/plugin/server.yaml

test_import:
  type: section
  import@1:
    type: xmpp/blueprints/partials/plugin/server
    context: plugins://

and this works too, (this is what I’m using now)

test_import:
  type: section
  import@1:
    type: blueprints/partials/plugin/server
    context: plugins://xmpp

even recursive includes (an included file contains an include) work.
I’m new to Grav, but it is already the coolest CMS I’ve seen in ages. It even motivated me to do PHP Again :smiley:

Thanks again for your Help :slight_smile:

4

i saw i could do many things with using flex and i tried to use it for so many things.
while doing that, “learn grav” helped a lot but still wasnt enough and i tried so many things for not hours but days :slight_smile:

  • from my experience and use cases, “section” is not a must but most compatible.
  • i also guess we must.
  • i also guess we must.
  • yes, but not “1” only. it can be any number, just had to be different from others since we use yaml, any number is okay and wont change anything other than being different.