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 https://getkirby.com/docs/guide/blueprints/introduction#blueprint-types:
The start page (Dashboard) of the Panel is defined in the
/site/blueprints/site.ymlblueprint.
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
or
template:
- articles
- whatever
In a new installed starterkit I use as /site/blueprints/site.yml:
### site\blueprints\site.yml
title: This website
columns:
# sidebar
- width: 1/3
sections:
# a list of all **level one** subpages
pages:
type: pages
headline:
de: Seiten
en: Pages
image: false
create:
- default
- another # does not exist in the starterkit
# a list of **site** files
files:
type: files
headline:
de: Globale Dateien
en: Global files
# main
- width: 2/3
fields:
info:
type: info
label:
de: Globale Felder
en: Global fields
text:
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.
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:
templatesfilter pages shown according to template and also what templates can be created- if you use the additional
createoption 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 thetemplatesproperty.
?? 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
templates:
- 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.