How to specify the templates that are allowed for the first level of pages

Because my question is basically the same as this question, @texnixe: Is there a blueprint option to specify the templates to choose from for the first level of the panel? I’m using the template option for sub parent pages like described for the Blog example with the articles.yml but this doesn’t work for the first/main level.


Look at

The start page (Dashboard) of the Panel is defined in the /site/blueprints/site.yml blueprint.

This means that in this blueprint you define the valid blueprints of the first menu level.

I tried it inside the site.yml file but it had no impact. Can you verify that it works there and give an example on how to use it with multiple possible blueprints?

I tried it with multiple allowed blueprints and just one blueprint. At the end, I was still able to choose any template on the first level:

template: articles


  - articles
  - whatever

In a new installed starterkit I use as /site/blueprints/site.yml:

### site\blueprints\site.yml

title: This website
  # sidebar
  - width: 1/3

      # a list of all **level one** subpages
        type: pages
          de: Seiten
          en: Pages
        image: false
          - default
          - another  # does not exist in the starterkit

      # a list of **site** files
        type: files
          de: Globale Dateien
          en: Global files

  # main
  - width: 2/3
        type: info
          de: Globale Felder
          en: Global fields
          de: |
              Diese Website verwendet keine globalen Felder, z.B. für die Felder im <HEAD> jeder Webseite.
              Daher gibt es hier derzeit keine Eingabe-Felder.
          en: |
              This website uses no global fields, e.g. for the fields in the <HEAD> of every webpage.
              Therefore there are currently no input-fields here.

This a NOT a multilanguage site!

I use create and NOT templates to avoid that some pages like the Sandbox page are not listed like in the original blueprint. But you can change these two words, if you want or need.

1 Like

Hm . . . I thought I can define this without providing the whole field structure for site.yml if I just want to limit the templates being usable on this level. It seems the create property is the very important part here. Is there some documentation about it? I can’t find anything about it via the search in the forum nor in the references.

After a longer search I have found:

Section properties:

1 Like

Ah, this explains why it has to be defined in the sections property and why it’s called different than it is for non-sections like pages of type pages without any field definition. Thank you for your help! This is inconvenient to implement.

Any other solution maybe, @texnixe?

I’m not really following you at the moment:

Pages sections:

  • templates filter pages shown according to template and also what templates can be created
  • if you use the additional create option you can further limit what you can create, but you might not need this property if you want to allow all templates that are defined with the templates property.

?? Do you mean pages fields?

Maybe I got the use of templates wrong or why it works:

My goal is to limit the templates I can use to create pages on the first/main level of my panel. Thus, I would use the template property like I did here: 3 times a blog. How to make 3 pages with 3 sections dynamic?

According to you, the create is only needed if I want to further specialize the limitation of template. This is not needed in my case: Any template I define under the template property will be allowed. Right now, I got this site.yml:

title: Site
preset: pages
unlisted: true

This is fine because I need nothing else content- or structure-wise beside my draft, unlisted and published categories, which are provided by default and working fine. So if I have to define fields and sections now, to limit the available templates, I’m confused why I don’t have to do it for my articles.yml of type pages.

In your example

you are using a so called preset. They work a bit differently from normal pages sections.

Exactly. If what you want to show and what you want to create is the same, its totally fine to use only the templates option. It is the typical use case for projects, blogs etc. where the subpages can either only have only one or multiple templates.

In the site.yml, you will usually have different pages sections, like in the Starterkit (not necessarily, but it probably makes sense especially if you have blog/projects pages). The photography and the notes section limit their templates to a single one, note and album respectively. However, you could also have different templates, maybe a video-album, and article-album or whatever to choose from.

Sometimes the create option might be useful in such cases, sometimes not. If @anon77445132 always wants to do that, that is up to him, but it is certainly no requirement.

If that simple setup is what you need, than that’s fine.

If you want to limit the templates in this preset, you can use the template option.

title: Site
preset: pages

  - photography
  - notes
  - whatever

No need to define anything else.

With this setup, nothing but pages with these three templates will be shown. And you will only be able to create new pages with these three templates.

Okay, so my mistake was to use template, not templates and I didn’t use the filenames (legal.yml) but the title (Rechtliches) in the blueprints. This solution works as intended by me.

I think template also still exists for single templates, but we have removed it from the docs (or deprecated it) to avoid confusion with multiple options. And yes, you have to use the filename, the title is often the same as the filename but some people prefer to be more verbose with their titles.

On a side note: Contrary to what has been claimed above , the site.yml is not the only place where you can define this set of first level pages (although you usually will, because you want to make all pages accessible from the “Dashboards”). In fact, you can put such a section into any blueprint if you want and if it helps the user (if you want them to be able to create first level pages from anywhere, for example). In such a case, where you use the same section in multiple places, if makes sense to move the section into a separate file (in site/blueprints/sections) and reuse across your blueprints.