i would also be interested in this as well… for the following reasons:
client accidentally overwrites german translation because he didn’t realise he hasnt switched it to english (revisions, drafts)
sometimes you would like to draft in the panel - client does not have FTP permissions.
articles are not necessarily the only pages that are invisible - it would be great to distinguish published and unpublished pages, invisible is something entirely different in some projects
Yes - it is possible to create a new field but: One page and 20 fields is not exactly superb…
Yes - it is possible to use a plugin but: Plugins are being created faster than they are being maintained…
Maybe i will post this into a separate ‘future request’ since it would be great to have some additional publishing features, e.g. a tab that containes information about revision, publish state and maybe meta information…if not build into the core these would still make great submodules …
client accidentally overwrites german translation because he didn’t realise he hasnt switched it to english (revisions, drafts)
I have a multi language site (ekobyn.com) 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.
Personally, I don’t like flags … but this is also another problem.
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.
How can you not like flags? You don’t like visual elements, like icons, images, photos and avatars either?
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.
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.
PS:
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
Back to the topic, drafts. I have an idea for a possible solution.
Idea
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.
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.
Pitfalls
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.
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.
@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!
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).
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.
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.