The changeTemplate workflow

[thguenther]

By default you can’t change the blueprint/template of pages. Only after you add the changeTemplate option.

That’s how the page settings dropdown looks in a fresh Kirby panel:

In Kirby 2 it was the other way around: if you wanted to restrict it, you had to list available templates.

I know Kirby 3 is a completely different story, with the pages sections etc. — but I find the process super exhausting:

1. There’s no changeTemplate: true option. So you have to define a list of every template in every blueprint.
2. A blueprint name changes? A new blueprint is added? You’ll have to open every single other blueprint and edit the list.
3. Defining the available templates in the blueprint of the current page may not always be the best idea. For example when the blueprint should have different changeTemplate options in a different parent.

Maybe I’m missing something and I’m trying too hard to use my Kirby 2 workflow. Is there any other, more efficient alternative?

[texnixe]

I did a quick test:

options:
  changeStatus: false
  extends: options/changetemplate

In /site/blueprints/options/changetemplate.yml

changeTemplate:
  - home
  - about
  - notes

That would at least be useful for those situations where you want to use the same options.

You can, by the way, put all your options into such an external options file and then reuse where needed.

options:
  extends: options/options

[thguenther]

Thanks a lot, Sonja!
I didn’t know you can put single options into external files. That’s neat!

Nevertheless, I still think the template change workflow could be optimized.

[texnixe]

@thguenther

I didn’t know you can put single options into external files. That’s neat!

I didn’t know that, either. I just thought it could probably work and tested it.

I actually quite like it like this, because usually a template change only makes sense in very limited circumstances. But that is just my personal opinion and your use cases might be different.

Maybe we can get some more feedback from other users and if it turns out it is not ideal for many, then open an issue in the ideas repo.

[ring]

I found this while researching the changing template workflow.

I think part of the reason why the general workflow currently does not allow for changing of templates by default is due to the features warning:

When an editor switches templates, all fields with the same name and type will be synced. Incompatible fields will be discarded. Be aware of this step when you define the list of compatible templates.

I wonder if it might be better in a case where template switches happen, incompatible fields are preserved in the content file.

Say you have two templates for photo galleries and one includes fields that allow you to configure some aspect of its template. Wouldn’t it be better if you could switch between the two templates while designing the content and see which template fits best without worry of losing fields or needing to make sure the other templates have potentially irrelevant fields just to preserve small bits of data.

But now that I write that out… aren’t the fields preserved in the blueprint and not the template?

[texnixe]

The problem is that even with identical field names, the format the fields are stored it might be incompatible (think of a field that stores information in yaml format vs. a field that stores information in a comma separated list).

If you want to preserve fields, you could make these fields hidden in the second blueprint, so that data is preserved, I guess.

Since we have conditional fields now, maybe some use cases that required a change of blueprint might be covered with this new feature and we’ll certainly see improved conditional fields/section in the future.

[texnixe]

May I suggest you create a feature request issue in the ideas repo:

getkirby/ideas

[thguenther]

I have a follow-up question related to this topic:
Is there any way to comfortably put a simple YAML list into a separate file?

Even with the great improvement suggested by @texnixe I still have to change the blueprint list in multiple files every time I add a new blueprint:

modules:
  type: pages
  parent: page.find("modules")
  create:
    - module.text
    - module.quote
    - module.text-graphic
    - module.links
    - module.carousel

# site/blueprints/options/changetemplate.yml
changeTemplate:
  - module.text
  - module.quote
  - module.text-graphic
  - module.links
  - module.carousel

Ideally I would like to “outsource” this list to a file which just contains something like this:

# site/blueprints/lists/modules.yml
- module.text
- module.quote
- module.text-graphic
- module.links
- module.carousel

That way I could simply reference the list in the pages section and the page options like that:

modules:
  type: pages
  parent: page.find("modules")
  create: lists/modules

changeTemplate: lists/modules

I tried it but couldn’t get it to work. Would it be possible to add such a functionality with a plugin or so?

[texnixe]

Hm, I don’t know if this can be solved with a plugin. The create option maybe with a custom pages section, but for the blueprint options, I wouldn’t know how.

[thguenther]

I think I found a solution by using a helper plugin to automatically generate the create: and changeTemplate arrays:

# site/plugins/kirby-modulehelper

$blueprints = [];
foreach (kirby()->blueprints() as $blueprint) {
	if(Str::startsWith($blueprint, "module.")) $blueprints[] = $blueprint;
}

Kirby::plugin('medienbaecker/modulehelper', [
    'blueprints' => [
        'modulehelper/create' => [
			'create' => $blueprints
		],
		'modulehelper/changeTemplate' => [
			'changeTemplate' => $blueprints
		]
    ]
]);

Using this plugin I can shorten my pages section…

modules:
  type: pages
  parent: page.find("modules")
  extends: modulehelper/create

…and module blueprints:

title: Quote
options:
  extends: modulehelper/changeTemplate

It seems to work great (and I’m quite a bit proud of it).
There’s only one issue: you can’t extend in an extend. That means it’s not possible to outsource the modules pages section and extend the modulehelper.

[thguenther]

maybe with a custom pages section

I just tried to do this by simply extending the pages section like that:

Kirby::plugin('medienbaecker/modules', [
  'sections' => [
    'modules' => [
      'extends' => 'pages'
    ]
  ]
]

…but it doesn’t seem to work:

In the docs I also couldn’t find any information on how to extend sections, only for fields. Is that not possible?

[texnixe]

Hm, I don’t think there is an extend option, it’s more a question of merging the original array with your custom methods: https://github.com/rasteiner/k3-pagesdisplay-section

[thguenther]

Ok, that’s surprising. Why can I extend fields but not sections?

The method you suggested seems a bit fragile to be honest. What if the core pages section changes?

[texnixe]

I’d say that internally the same happens when you extend a field

[thguenther]

Ah, I see. I will try to get it to work this way. Thank you @texnixe!

[HYR]

@thguenther Thanks for pointing me to this solution! For some reason I wasn’t able to get any blueprints back from kirby()->blueprints() I’m not sure why. But it did work for me create set my list via a config option(), so I’m able to set the list manually until I figure why I couldn’t create the list from kirby()->blueprints().