Vision for Kirby: Frontend editor

I fully agree. The content absolutely needs to be clean and maintainable.

I think that a preview mode could be a great solution, but the question is how to make sure that the preview is in sync with the content but not generated on the server for every single keypress either. Maybe that needs some kind of markers in the templates to tell the Panel which piece of content gets inserted where and how?

1 Like

There are some other issues we need to handle, because a lot of CMSs nowadays use some kind of postprocessing on the content, take SmartyPants (which is part of kirby) for example. It turns straight quotes into curly quotes and can do some other tasks as well.

If we care about beautiful and interesting layouts, we need tools like those to provide decent typography. We can convert straight quotes on-the-fly using JavaScript in a frontend editor, but what about more advanced features? Take PHP Typography for example, which also adds some <span> tags for styling your content and provides hyphenation by adding &shy; characters were applicable. This is getting so complex, that doing text transformations like PHP Typography does are very hard to integrate into an WYSIWYG-editor. You also really don’t want to have all those special characters like zero-width spaces and shy hyphens in the source of your content.

I know, that not everyone needs PHP Typography, but I think there are other examples, where postprocessing plays an important role. So what solutions do we have?

  1. Drop server-side processing of the content entirely and handle everything from curly quotes to dashes and hyphenation in the editor using JavaScript. The pitfalls: It needs a very advanced editor and also server-side checks to make sure that the code of the content is valid. Also, your might contain a lot of strange characters.
  2. Use a WYSIWYG-Editor in the frontend and do post-processing after the user has finished editing. This is not 100% WYSIWYG, but in most cases, body copy does not look to different from the output without hyphenation, curly quotes and correct dashes.
  3. Edit blocks of (text) content in a modal (some frontend editors handle it that way), but is this still true frontend editing? Maybe not, but it by far the most flexible approach, because it also allows us to use markdown for writing. This forum is a great example of how it can be done. By moving the editor to the bottom of the page and providing a live preview. For content management, this preview could be integrated above the editor right into the block of text, you are editing. Another big advantage of the approach is, that the editor’s modal can also be used for settings, metadata and behavior of a content block which will not be visible on the final page.

Which approach would you prefer?

I don’t get the hype about. Frontend editing is clumsy. If you’ve a 27" imac, you may’ve enough space left to work with. People tend to make sure their page looks good on their computer then, add some space there, resize images, trying to set every pixel exactly. They forget about other devices – much more if they see their changes in real time.

1 Like

Wow! BTW: Thanks for every single answer of you all! You’re awesome and I really appreciate this discussion. :+1:

Okay, forget about the WYSIWYG Editor. I’ve used the wrong term to name it. As I wrote:

So I personally would prefer an editor like the markdown editor by @DieserJonas. It’s sort of WYSIWYG but it’s also still a real markdown editor. An editor in which you can’t see which markdown commands you’ve used is way too complex on both sides: on code and on usability.

I like the idea having a preview beside of the content.

Or alternatively like the Ghost Blog Web-App.

Yes, that’s true. That’s also what I love on Kirby as a developer. And that’s also something I wrote down somewhere in this thread: in my opinion this has to be optional because the panel has to fit the workflow of the person who is adding, filling and editing the content and also to the use case - not vice versa. But in simply one use case it can be the perfect one: the use case of filling, editing or adding content on a website. And I guess this is the use case of about 80% of Kirby projects.

But I have to say this is the view of us designers and developers. And I totally agree that separating the content of it’s appearance is really important to have a clean and reusable content. But that doesn’t matter for a user who is just building blocks and writing text for his own or for his company’s webpage. It’s irrelevant for the user what’s happening under the hood.

Could you explain why a frontend editor or a preview is clumsy if “people tend to make sure their page looks good on their computer”? I assume that it doesn’t matter if people have a separate window, a preview beside of the content or a frontend editor: they will always tend to make sure their page looks good. So this suggestion is simply about making the preview thing as easy and as good as possible.

Don’t make the developer work the asses off

If the preview requires extra stuff to the template, or the blueprint for the preview to work, then it adds extra load on the developer every time a site is built. Those kind of features can easily break because some backend JS + some frontend JS has to work together.

Preview split-screen idea

I wrote an idea for the panel-bar plugin made by @distantnative

Preview in the making

It’s already in the making. The screenshot part is really buggy + hackish and I would not recommend anyone to use it at this stage. The panel-bar at master branch is stable and awesome, but not the preview yet.

This is how it works: It works with iframes, one for backend and one for frontend. It feels when the submit button is clicked and updates the frontend to the right when saved. That way there are no dependences at all, no extra work for the developer. That part I really like.

Preview in the panel

@bastianallgeier I would love to have a preview in the panel, just have this stuff in mind:

  • Make sure it has an URL so we can link to it from outside the panel.
  • Don’t make the developer work their asses off by modifing the template / blueprint just to make it work. It can turn into a bloat-mess, frustration. It will probably also add a lot of unknown issues for the Kirby crew because it can be a huge project to develop if taking it that way. (my opinion)
  • If updating an iframe, try to get rid of the blink-effect. I don’t mind the delay, but the blink makes me blink. When I blink I lose focus and when I lose focus I can’t get anything done. The issue probably depends on that the JS and CSS links are removed and added again. I don’t have a solution for it.

Interesting to read all the different opinions. I really like to use Kirby because I can predefine content models (blueprints) and access this data whenever I need it in a really simple way.

I’ve followed this thread for some time now and still haven’t read every single post. However, I think there are two problems, that should be solved in different ways in different ways although they are somehow related.

  1. Some of you want a more flexible editing interface to create more complex layouts.
  2. Some of you want a better preview of how your content looks before publishing.

(And some want both… :slight_smile: )

Trying to solve both problem with a single solution like a full-featured frontend editor seems legit at first, but I’m convinced that this won’t work with Kirby given the many different use cases of this cms.

A (better) preview mode

Currently I’m working on a project for a company offering temporary industrial architecture solutions. I’d say it’s a medium-sized Kirby project; a project where we have to display different features, technical data etc. I try to use Kirby as a repository for content that is displayed in various ways on different pages. In some cases content is manipulated before it’s shown on the website. We are even considering to create a simple API to access the data in different applications. That is probably a small-scale example of what @bastianallgeier was talking about.

It’s impossible to replicate this process for a frontend editor to show a real live-preview of the website. The only true live preview is what you see on the website. Trying to reproduce the template output in an editor will always fail if you’re working on a general solution that should work on different themes. Some services like Medium have created great editing interfaces but these tools are limited to a single service and purpose.

Currently, if you’re a tech-savy person, you can use git to see a preview of your changes on a local machine or a staging server and then simply push the changes to the live server. However, this is probably not a solution for most Kirby-users especially when developing for clients from a totally different background. Furthermore, git is not supported by most shared-hosting providers.

I’m not sure how versioning/drafting in Kirby could look like, however, there have already been some ideas on this forum.

Providing a better editing interace

I think the best idea is to use some kind of syntax highlighting for markdown (using the visual markdown plugin by @DieserJonas) or a simple split view preview in order to get a simple visual representation of the longer text content, e. g. for the blueprint of a blog post. This way, you’re providing a better writing experience.

If you’re clients need to create more complex layouts themselves, I’d really recommend using the kirby builder plugin by @timoetting. I’ve been using subpages but this plugin makes it a lot easier and allows you to add basic styling to the items, e. g. you could add italics to a blockquote-module etc.

For me, this is a great combination to give my clients more advanced editing possibilities while maintaining a consistent design.

— Till


Here’s another take at in-place editing: Content Tools.

I like how they make things draggable, look at the “Drag and place content” section in the demo.


This is one of the most beautiful Frontend Editor, I have seen. I really like the concept of arranging images and other media, just by dragging it (only the arrow icons in the background look ugly). This seems to be a perfect solution for “single-block” content like a Blogpost or a news article.

I also like the fixed toolbar that stays at the same position, no matter where you edit. This makes the editor feel more like a application like InDesign or Word, rather than just a website. A toolbar could also be combined with context-sensitive panels (like in Adobe’s tools) for more advanced options.

Very interesting concept. Thanks for sharing! I think using markdown with this could be very very great in the end.

As I tried that out I needed a bit to understand that every paragraph is a “block” that could be changed by the toolbox. So building a new block needs adding a new paragraph.

Yes, lots of editors actually work that way, including the usual suspects: CKEditor, TinyMCE, Aloha Editor…
It’s a lot more obvious in WYMeditor as they show the paragraphs.

Hey all,

I’ve just posted about the frontend editor I’ve been working on:

Let me know what you guys think.

Today I found this frontend editor, based on blocks and markdown:

Imagine you’re defining the available blocks via blueprint and writing the text with markdown. :smile:

1 Like

I’ve tried this my self before (and failed), but learned something:


  • Visual editors add a huge deal of complexity (you know that)
  • You better measure invest/return ratio before starting


  • Users are not tech savvy (even if owning latest iphone makes them think so)
  • Users are not designers (even if PowerPoint makes them think so)
  • All projects have different users
    • Some can handle complexity, some not
    • Providing appropriate tools is key
  • Designing a website is overwhelming
  • Designing a website takes time
  • Users get tired of designing if they have to do it all the time
  • Having more options/toolbars leads to paradox of choice
    • Business people get tired, abandon editor, get back to business stuff
    • Support tickets peak for reasons like: “How to make text blue? How to make picture bigger?”
    • Users must feel familiar with editor at first glance, chances are they won’t read help pages
    • Avoid learning curves: Tech people read manuals all the time, prior generations do some times, millenials jus don’t read manuals
    • If your implementation needs an “interactive tour” you’re heading off rails
    • Users from different languages interpret toolbar icons very differently, translatable text labels are the best


  • Do not ever underestimate the lazyness of users (specially youngest)
  • Visual content editors are not bad, nor wrong, they just need a strategic implementation
    • And figuring it out it’s hard
    • There are painfully countless ways to do it
  • Remember DESIGN is actually a whole formal career, you need years to master it
  • Tech people and profesional editors enjoy designing, they can handle it
  • Strictly predefined content blocks might be the safest starting point
    • No designing, just choosing
    • Like choosing a template when creating new page in kirby panel
  • I’d investigate implementations like, or
  • I’d deploy this feature as optional (a plugin)

Heads up!

Somebody will do it right eventually, it could be you


  • I like how kirby works, I like panel fields, but…
  • I’d suggest letting the user change template after page is created so they can feel like they have a “change theme” feature, it’s useful for having seasonal marketing pages which change over time but are yet foreseeable
  • I’d love to see strictly predefined content blocks as an option, but only if they are strictly predefined, otherwise fear a total mess

The future?

I see 2 extremes:

  • I expect profesional editors to fuse with technology and develop “super powers” they’ll use advanced editors or create their own, they are techies
  • I expect general public to lean towards “click here to create website” options like they won’t bother at all

Visual editors fall in the middle, still a considerable piece of the pie.

What a long list. I will just add something more to it.

Splitview - A real WYSIWYG

I’m the author of Splitview.

It refreshes the site iframe when the content is saved. That way it never need to know how the content is ment to be rendered.

About the keypress live preview problem

In Splitview or similar tools, it would probably be possible to get the unsaved content from the panel local storage. Javascript would be required.

Require extra html markup

If we have a text field it would probably be easy to add it, as long as we have some extra markup in our html. That way the javascript will know on what element it should add the content.

If statements

Maybe the user have a panel field called “template” where the panel user can add values like “blog” or “quote”. On the frontend it might be used to have a specific html snippet / template.

How can the javascript know how to handle that? It can be really messy to keep up with problems like that. Only this one case can be hard to code well.

Structure field

Same as for if statements. The structure field contains sub fields / values. For javascript to know what to do can be really hard. It might even need Ajax to extract things by PHP. If it uses Ajax it also will be much slower because it would require a new pageload everytime.

Also, think about all custom written fields that might be used.


I would say it could be nice for example Splitview to have some kind of live preview and I might add it.

However it would only be on “root” fields and only on content that should be added directly to the site.

That means, no if statements / conditions, no structure field values (at least not at first).

If you or anyone else have another idea about or have brilliant solutions to the problems I would love to hear it.

1 Like

Hi everyone,
I’m new to Kirby and really love it so far.

The Splitview plugin from @jenstornell is such a clever idea and well done – I recommend to try it out!
I like the ‘Distraction free mode’ and how the plugin makes use of Kirby’s responsive Panel layout.

Btw. Thanks to all forum members for the helpful posts I’ve read, yet.


You don’t actually have to use the panel at all, since stuff is just Markdown. I use Write to edit my content. Its a desktop app for markdown. Ulysses will probably work quite well too.

Interesting reading. My opinion:

  1. Markdown itself became so popular in the times when we all had any kind of WYSIWYG experience, must be a reason for that.
  2. Styling panel is not a matter of Kirby Core. There are no limits to make it identical to the site itself at the moment. Only when you’ll try this you’ll realise that is like make a site twice.


My experience is, most clients and people are fine with a customized backend. And they are happy about the easiest solution to publish their content. Type your text in that textfield, hit Save and you are done.
In most cases they want to spend less time with publishing software not more.

On the other hand I would like to use such tools in the design and development stage. Not to build the whole site without having to touch a line of code. But to speed things up and reuse + rearrange my custom designed site elements.

Here is another example of the many recent builder tools:

Btw. “… page builder with no limits of design” sounds a bit suspicious, but anyway.


Any news about this topic since 2016?
Is there any VISUAL Frontend-Editor that you would recommend to work with Kirby?

Kind regards

There are no such plans for Kirby, at least not in the immediate future.

With the blocks and layout fields, and customized blocks, you can actually go a long way into giving users a preview of what they will actually see on the frontend, without the need for a frontend editor, as you can see here:

You can find the roadmap here: Roadmap · Kirby Feedback

A live preview for the Panel has long been on the agenda and can be upvoted here: