Am I using blueprints wrong?

Kirby 4 Question❓
1

I’m wondering if I miss something about blueprints. Right now I have one blueprint for each section of my website (e.g. Blog, Microblog, Photography) and custom types for each of those (post, status, album) and sections for them - so I have 9 yaml blueprints for 3 different sections. I feel like I’m missing something here and are on my way into a mess :smiley:

For example, this is my blog.yaml and post.yaml

# pages/blog.yml
title: Blog
icon: "📝"
tabs:
  posts:
    icon: list-bullet
    label: "Posts"
    sections:
      drafts:
        extends: sections/blog
        # Only allow children to use post layout
        create:
          - post
        label: Drafts
        status: draft

      listed:
        extends: sections/blog
        label: Published Posts
        status: listed
        flip: true
  metadata:
    extends: sections/settings
    label: Settings

# pages/post.yml
title: Blog Post
icon:

columns:
  main:
    width: 2/3
    sections:
      main_fields:
       [...]
  sidebar:
    width: 1/3
    sections:
     [...]

# sections/blog.yml
type: pages
label: Blog
parent: kirby.page("blog")
size: small
layout: list
template: post
empty: No posts yet

The pages/blog.yml seems to be unnecessary, I just want to create a page that lists sub-pages - I think this should be a more generic template? Other pages on my site also list sub-pages, is there a way to make it more generic?

This is all my blueprints and it feels a bit too much :grimacing:

site/blueprints
├── blocks
│   └── spacer.yml
├── pages
│   ├── album.yml
│   ├── blog.yml
│   ├── book.yml
│   ├── bookshelf.yml
│   ├── default.yml
│   ├── home.yml
│   ├── micro.yml
│   ├── microblog.yml
│   ├── photography.yml
│   ├── plaintext.yml
│   └── post.yml
├── sections
│   ├── albums.yml
│   ├── blog.yml
│   ├── book.yml
│   └── settings.yml
├── site.yml
└── users
    └── admin.yml

Any hint and help appreciated, thanks in advance! <3

2

Theoretically, yes, in practice, it often doesn’t make that much sense. Like if you want to render those parents differently on the frontend, apply different filters etc., having different templates/controllers for them makes sense (and therefore, having different blueprints that define the content file name).

1 Like
3

Thanks, that makes sense. I was worried I was doing something wrong with all those blueprints :smiley: