Importing Blueprints broken with 1.7?

I've got a theme that makes use of imported blueprints. This is done by making a new tab in the parent blueprint, while the tab contents sit in a separate blueprint that is then imported. Example:

blueprints/parent.yaml:

title: Parent
extends@:
  type: default
  context: blueprints://pages

form:
  fields:
    tabs:
      type: tabs
      fields:
        downloads:
          type: tab
          title: Downloads
          import@:
            type: partials/downloads
            context: blueprints://

With blueprints/partials/downloads.yaml:

form:
  fields:
    header.downloads:
      name: downloads
      type: list
      label: Downloads
      fields:
        .name:
          type: text
          label: Name
        .file:
          type: pagemediaselect
          label: File

This worked fine. Now I've updated the system to Grav 1.7. Ever since, the tabs still show up in the Admin, but they are empty.

Maybe I did something wrong with these blueprints that Grav 1.6 silently ignored, but now won't tolerate anymore?

@domsson,

• Have you read the upgrade docs?
• Did you run $ bin/grav yamllinter?

@pamtbaau:
upgrade docs

Yeah, I saw that there is a stricter YAML parser now, hence my theory that Grav 1.6 (with the previous parser) ignored an issue that it doesn't ignore now. However, running the yamllinter does not show any issues with my blueprints. The only file it does show an issue with is a system-owned file (account_new.yaml), which shouldn't have anything to do with this issue, I'd assume.

Does it work if you enable Yaml backwards compatibility?

strict_mode:
  yaml_compat: true

in system.yaml?

Sorry, should've mentioned that right away: nope, does not work with backwards compatibility turned on.

@domsson, You said you are using a theme which makes use of imported blueprints. I therefor guess that blueprints are stored in '/user/themes/<theme>/blueprints'.

If so, the blueprints will not be found when using the following import@ statement:

import@:
   type: partials/downloads
   context: blueprints://

Explanation:
According a late answer to one of your previous question regarding the same topic, context: blueprints:// points by default to the blueprints folder of the Admin plugin (/user/plugins/admin/blueprints). Above import@ will therefor point to /user/plugins/admin/blueprints/partials/downloads.yaml.

To have Grav search in the blueprints folder of a theme, one should use the following import@ instead:

import@:
  type: partials/downloads
  context: user://themes/<theme>/blueprints

The combiniation of type and context will now point to /user/themes/<theme>/blueprints/partials/downloads.yaml

Hm, I hadn't seen (or forgot) about the late answers of that related issue. However, there are two things that strike me as odd about the solution proposed there:

• context: blueprints:// is exactly how it is shown in the Grav doc's example
• It worked with just context: blueprints:// in the previous Grav version
• Using the context line that includes the hardcoded theme name seems like a bad idea; rename the theme an everything breaks?

I just discovered something interesting though: entirely removing the context line seems to fix the issue! I don't know if this is a "dirty workaround", or expected behavior, but I guess I'll roll with this for now.

Thank you for your thorough investigation! I'm sure this will be of help to others, as well.

I agree with your assessment and will therefore go with context: theme://blueprints.

@domsson, Just had to know... Also tested your case using Grav 1.6.30

When using snippet:

import@:
   type: partials/downloads
   context: blueprints://

Imports are found in the following order:

• themes/quark/blueprints
• user/blueprints
• plugins/admin/blueprints

This seems to confirm that Grav 1.7.5 has a breaking change with respect to the blueprints:// stream.