How do you work with drafts of already created posts?

I usually work locally and without the panel, so I can simply push changes when they are ready.

I think this problem is more inherent for clients who work online via the panel and if you don’t use a staging server, I guess.

Yes, absolutely.

1 Like


client accidentally overwrites german translation because he didn’t realise he hasnt switched it to english (revisions, drafts)

I have a multi language site ( where I have done that myself many times, because I moved the content from a WP installation. Because it’s just letters I think it’s hard to spot the difference right away. Flags would probably be better, but that’s another problem.

tab that containes information about revision, publish state and maybe meta information

Sounds like a nice idea. I’m not sure how that could be built in a good way with the files and folders but it’s probably possible to do with a plugin.


I think this problem is more inherent for clients who work online via the panel and if you don’t use a staging server, I guess.

Yes. I guess that’s the majority of all people who use Kirby?

Personally, I don’t like flags … but this is also another problem. :wink:
Using my translations plugin for myself for the first time, seems to reduce the amount of switches to the wrong language by mistake … at least for me.

Back top the topic: We update our content on the fly. If there are bigger changes, we do it locally and then transfer the folders by SFTP. This is a huge advantage of Kirby compared to a database driven CMS. :rocket:

Personally, I don’t like flags

How can you not like flags? You don’t like visual elements, like icons, images, photos and avatars either? :wink:

Using my translations plugin for myself for the first time, seems to reduce the amount of switches to the wrong language by mistake … at least for me.

Yes, that’s kind of an extra reminder. I still want to try it out, maybe today. I have had too much focus on my own plugin development. My brain is almost fried by all my ideas. :boom:

When i said i could Imagine having a tab for meta information i thought about the sections we already have in the blueprints.

It’s possible at the moment to add lots of sections, to add structure to our backend forms, but also these sections result in a huge form. It would be convinnient to move some stuff, instead of in a new section, in a new tab. That way i would at least be able to separate necessary information and unnecessary information (like seo, draft state etc). Stuff that we have to add to most pages in most projects anyway and that clutter the simplicity of the ui. (Plugin providing this functionality )

Going one step further, multi language stuff… As you pointed out we have multi language integration which gets multi domain support in 2.4 which is great, but the panel is not yet ready to handle it. There is a lot of funcionality missing which a user provided plugin is fixing - which is great! But. When you, I or someone wants multilanguage integration it would be awesome to get the information the plugin provides natively from the panel without having to hack Kirby. Don’t get me wrong, plugins and modularity and flexibility are great, but you for multi language stuff you either don’t want it or you want all features you can get (check which pages are translated und which are not, better visibility of current language, do I want a page to be visible in another language…etc)

My personal problem with plugins as a solution: they are maintained by developers who needed these for one or maybe two or three projects…, if they don’t maintain it i have to maintain it, to use it with future versions of kirby. This is a huge problem for me, since security is a big deal for my clients and me… If i cant update kirby because of a plugin that might break the site - we will have security issues… which is bad. :frowning:

I assume this post got really long so I should really split this in a couple of future requests…xD but I just had to write down the thoughts I had :wink:

1 Like

We talked about that the users (including myself) sometimes save the content in the wrong language.

I released a plugin that includes flags.

More info here:

Back to the topic, drafts. I have an idea for a possible solution.


I don’t really see a reason to have more than one draft to each page.

My idea is based on that there is only two states, one original and one draft. You have one published version online and you have one unpublished version that will be online some time in the future.

Screenshot 1

Explaining the screenshot:

  • A switcher on top. Green in this mockup could be the active choice.
  • Switching to the original will give the same fields but probably another content.

Screenshot 2

This screenshot is all about trying to show how the content is stored. It’s the same fields but they are duplicated.

The benefits of having the draft content saved to the same page are these:

  • The delete page still works because there are still no subpages to delete first.
  • The preview button will still work like before and to show the draft a possible solution could be to add ?state=draft to the frontend page url.
  • There would be no need for excluding pages in collections.
  • There would be no need for using routes to have error pages to the drafts, because there are no drafts pages.
  • A draft is a version of the current page. In that context it would not be a logical choice to have a new page as a draft.


  • The content text files will be larger, but by adding a hook to remove duplicate fields it would only need to keep the modified fields.
  • As far as I know the blueprints don’t handle logic at all. It would require to figure out a way to duplicate the fields automatically before the blueprint is loaded.


1 Like

Maybe it is possible to add the Draft / Original button as a Toggle button on the left, below visible / invisible?

I’ve been thinking some more about that approach and there are too many hard things about it. Some important things are:

  • Duplicate content in the blueprints.
  • No way to use logic in the blueprints.

Instead it should probably be some kind of new pages approach, where the draft pages are invisible. Some page clone feature would be required.

in comparison, do you know how GRAV solves this?

No, do you? …

i just downloaded it and checked the admin panel… seems like they don’t…
but you can set a publishing date in the options, which means you can work on a ‘draft’ and publish this draft, when it’s done or after a certain amount of time, which can be done in kirby by adding fields for publish and unpublish date…

Copying the page and working on an invisible copy like you mentioned would be the same solution you mentioned.

Statamatic claims to allow saving posts as drafts, but since it’s not free i don’t know how it is solved there.

I think copying the page, editing the copy, removing the old page and publishing the new page would be the easiest workflow.

1 Like

@philipp Ahh, thanks for that info. I have kind of been in this situation before but have not yet built a solution that I liked:

The problem with the above is that they only work for new pages, keep them unpublished or private and then publish then. It’s a little trickier to solve it with already live existing pages.

@texnixe I completely agree with you now. It just took some time before I saw it. Thanks! :slight_smile:

The biggest problem right now is cloning pages with like 30 images that are 3MB each. But I think I have an idea for that as well, completely without js (I don’t like js in cases like that).

I don’t know when I have time to build it tho.

Some other problems that might occur when cloning a page:

  • same uid / uri ?
  • invisible status not optimal, since sometimes visible / invisible might be part of the logic.
  • e.g. if you are using invisible pages for something else than drafts / revisions…

same uid / uri

I’m thinking something like this:


invisible status not optimal, since sometimes visible / invisible might be part of the logic.

I’m not quite sure I understand your point in this case. You mean some people use invisible pages for something else? I mean, a draft should never be visible on the frontend for visitors.

But maybe my prefix solution solved your issue?

Yeah, in thoughts of a generic solution the prefix should work. :slight_smile:.

Exactly e.g. to manage categories :unamused:

1 Like

Invisible pages can in fact be used for all sorts of stuff, e.g. if pages or just used as content containers or for registration pages or whatever. But it would be the developers’ job to filter pages correctly in case they want to integrate such a draft plugin, I think.


A custom collection filter could remove pages with slugs starting with draft-- from the collection. Another way is to have the drafts in a drafts folder. No matter what way, the drafts will still need to be filtered out somehow in the templates/snippets.

I want to show you an idea I have about drafts in already existing pages.

1. Create draft

It’s just a button with “Create draft”. It does only save the content text files. It saves the draft as draft--about.

2. Working with the draft

Photoshop mockup

In this screenshot you will see some things that you probably don’t understand at first sight.

Original files

All the files in the original page is listed here. They don’t yet live in the draft, but if I click one of the it’s copied to the draft. Click, click and both files are copied.

After they are copied they are in sync with the original and are hidden from the “Original files” list.

New draft files

In my case I added about.jpg and it did not exist in the original. Before publish the draft, it’s important to copy all used new draft files to the original. Else the pages would look different. They should be in sync.

After they are copied they are in sync with the original and are hidden from “New draft files” list.


Here we have the file another.jpg. It exists both as draft and as original file but even if they have the same name, the file size is different. The conflict needs to be resolved. It can be done by rename, delete or overwrite the file in the original.

After they are copied they are in sync with the original and are hidden from “Conflict” list.

All of this may seem like a big overhead and I added lots of text to explain it. In real life I think it’s easy and fast to work with.

3. Publish

I don’t have a publish button in the mockup but when the preview look good and there are no green and red fields you are good to go. Press the “Publish” button.


  1. Start from zero.
  2. Pull the files you need from the original.
  3. Push your new files to the original.
  4. Resolve possible conflicts (there might be none).
  5. Publish