Panel: Change the template

I know that this suggestion/request/wish has come up multiple times, but every time I stumble over it again, I keep asking myself how this would work conceptually. Maybe we can discuss this a little.

If the panel would allow to change the template of one page, what would happen to the data? Since the blueprint/fields of the new template might not match the old ones, should the old data, for which no new fields exist, be thrown away? Still stored in the content file?

What are your thoughts? Maybe also other ideas/implications, what would happen when changing a template.

The main problem I see here is an accidental change of template/blueprint with consequential data loss, which might in fact be quite dramatic for the user (even with version control in place because user cannot necessarily retrieve data from repo).

Since there is also no way to undo this template change in a way that will restore the data of fields that do not exist in the new blueprint, I think it would be important to keep the old data in place, so that this data is accessible when the user reverts to the original template. This could also be optional by asking the user if he wants to keep or discard the data.

If the field name of the new template is the same but the field type is different, this will also result in a loss of data. And this scenario is probably the bigger problem. Options

  • Ask user if he wants to overwrite data
  • Store old data in filename_old (at least this data can be restored by accessing the file via ftp/ssh)

Quite another option would be to create an attic with history data like Doku Wiki has it. But that’s not just a small change …

Another problem I see here is if the field name and the field type are the same but the old data doesn’t make sense within the new context.

On template change / load keep current data and populate the fields in the blueprint.

On save, ask If the user want to remove fields missing in the blueprint. If yes overwrite previous fields, remove not existing fileds.

I think the real change to the content should be on save, not on load or template change.

Do you feel like a temporary store (through session or so - similar to the unsaved changes from 2.1) would be sufficient? This could help for accidental changes that get reverted quite quickly, but not after days.

But at that point the user should ask herself/himself, why she/he wanted to change it in the first place, revert the change or just change the content of this field as she/he probably intended in the first place, don’t you think?

Yes, maybe, I was just trying to think “stupid user”. On the other hand, if there was a possibility to restrict template changes to changes that make sense, like change from an image article to a video article or something like this, then many problems would not arise and the developer would not have to take precautions against every ever so stupid change.

Yes, I think that would be sufficient. For everything else, backups or version control should do the job.

Actually, I think this might be similar to my other comment. Either the change was a mistake, thus a quite immediate revert should be done and cached/sessioned data would be sufficient. Or the new field probably isn’t intended to represent the same as the old one, even if they share the same name. So dropping that data is quite likely deliberate?

Yes, I think that as long as a change can be reverted even after saving that should be sufficient. But as I said above, the problem would be largely mitigated if the possible template changes could be restricted in the first place. If the possible templates for a specific subpage are restricted, that would be sort of automatic anyway.

1 Like

Or separate blueprint and template. Now they are connected by their names. Maybe the could be connected by a another way? Content value?

Just an idea.

@jenstornell How exactly do you think that should work?

Personally, I’d say this is bad practice. I’m trying to give fields descriptive names and use those field names for fields with the same content type in other templates as well. There could be a small note on naming fields in the docs to explain the consequences of changing the template and why consequent naming is important.

Personally, I would like to see all data kept in the content file itself. This would require changing the normal saving behaviour so extraneous information is not stripped out of the content file. For example:


title: What I had for lunch today
date:  2015-05-31
text:  Lorem ipsum dolor sit amet ...
tags:  lunch, food, personal

Suppose we wanted to change this blogpost to a default template, which has all the same fields except no tags.

The resulting default.txt should retain the tags field. The tags should not be deleted on save, nor should they be deleted during the template switch.

If the default template is updated to include tags, then the content will magically still be there in the panel. I can’t see any downside to this, and I’d be wary of deleting any data that the user doesn’t specifically remove.


If the old template and the new template share a field name but have different field types, I think we should still keep the original data in the content file.

The worst that could happen is we get a text field trying to convert to a radio or something, and no options show up in the panel. No harm done, thought this could cause some wonky template issues if the template expects to be parsing a radio field.

Or the reverse scenario, the original template is structured and the new template is textarea or something. The text box would actually be filled with useful content that the user can work with, rather than throwing it all away.

1 Like

I’m in favor of @texnixe early suggestion of storing separate backup content files for each template that has content. An intelligent user can clean up old files when they’re done manually, and the “stupid user” is not even aware of their existence. Some sort of purge backup content file could be available by a widget plugin perhaps, or a site config option like purgeOldDataOnSave that does it automatically.

Ok, first, there were also tangential discussions about wether fields that don’t belong to a blueprint should be deleted on save, or kept. The use case I think was primarily sites edited directly in text files, then switched to using blueprints.

Secondly, I think this is tied to another suggestion/request/wish: people who want to move a page. They may have created it in the wrong place by mistake, or they just want to re-organize things a bit. But if a page moves to a place where its “type” is not allowed (restricted by template: in the blueprint) it has to be converted. I suspect this might be a more frequent need than just switching template.

A lot has been discussed already, and I agree with pretty much everything @texnixe wrote.

To me the questions now are:

  1. how do we make it clear what will not convert automatically ;
  2. how do we help in taking the required decisions ;
  3. how do we help in doing something useful for fields that cannot be converted?

I’d like the whole process to be simple and automated, but the user has to make some choices.
A conversion UI is probably needed, I see it as two columns: on the left the current fields, on the right the destination fields. If fields of the same name exist, they’re chosen automatically. If the name matches but the type differs, a warning is displayed. Fields with no equivalent are marked as “will be deleted”.
For every field we can select another field in the targeted blueprint.
If you think it makes sense, I’ll do a quick mockup of what I have in mind.


Personally, I’d love to see that mockup as it seems this could shed some more light on my confusion of how to deal with all of this :smiley:

Also, a good question to ask ourselves is why would users want to change the template? I did a bit of search and didn’t find much information. Those who ask for this feature don’t explain why they need it.
On Github in issue 69 it’s about using another template, not using a different blueprint, so it’s different and could be done without converting. E.g. if a condition matches, in your PHP code you set a different template to render the same page and fields.

So why would someone need to convert content to another blueprint?

  • if it is only to move a page somewhere else, then it happens because of the way Kirby manages content in a tree-like hierarchy and the Panel restricts content-types, and we’re trying to solve a problem Kirby creates in the first place. (I’m not saying it’s a conceptual flaw, there are good reasons and benefits with Kirby’s approach)
    Or maybe it’s because the site should have been built in a different way :wink: But in most CMSes you can indeed move content around, and some see it as an expected feature.

I’m trying to find another reason, but can’t find any that makes sense for an end-user right now. Tell us your use cases!

Let’s try to identify some scenarios then.

  1. For a blog, you may have created different sort of blog articles, each with a different template, e.g. video article, image article, slider article. You might start with an image article and then think it over and decide to make it a video article. In such a scenario, you would need to
  • use a different template and
  • also another blueprint.

Some of the fields may be different but the main fields would be the same and it wouldn’t matter to loose the content of the other fields. You wouldn’t have to move the page, though.

  1. You want to move a page someplace else. In this case, you may or may not have to change the template and of course the blueprint, depending on what sort of template/bluebrint and data is allowed or required in the new location.

I think the reason why you can’t just move stuff as you want, is only partly due to the hierarchical structure. The point that is more important is probably the fact that you can define what content goes into each text file freely. As a consequence, you need a blueprint, that defines what sort of stuff needs to get in, and then you need a template to get it all out again.

Honestly, I’m not sure how often any of these use cases might arise. The article stuff could possibly be solved with a different content strategy but that might clutter the form (or we would need conditional fields, which would be great anyway).

1 Like

<3 conditional fields.

I think that the need to move pages and thus change the template/blueprint to fit the new location’s field structure would be a more likely scenario than just changing the template alone.

When I think of why would I need to change the template/blueprint but not move the page location, the only reasons I can think of are improvements to the page down the road without remaking all the pages. But if I’m improving the code anyway, testing, redeploying, etc… I would just change the content’s file name as part of the process without thinking about it much.

And if you could move pages, and changing the template/blueprint used is part of that process, you could in theory trigger the page move, then that rename function exists and can be implemented as a standalone as well.

In addition to move page, what about copy/duplicate page?

I don’t think this feature makes that much sense during the development phase of a project, but is rather intended for future users who can only access the site via the panel?