Hey guys.
First of all, superb work Bastian.
Currently I am testing / finding solutions for my client but since Kirby is heavily reliant on Markdown, my client will have trouble updating the site.
I think there needs to be an setting to turn on more sophisticated styling options with a live preview. My client requested headings, justification and colors. Though I would say the latter is low priority. Also resorting to markdown editors is bad alternative.
Thanks
It’s not 100% ready yet, but I’m currently working on something you might enjoy: Kirby WYSIWYG Editor.
It’s a medium.com like visual editor field for the panel. It allows your clients to exit their content without knowing markdown.
Let me know what you think about it!
Great! Just wanted to suggest such a field plugin instead bloating up the Kirby core with more options. And given that I should be writing my thesis these days, it’s great that someone is already on it, so I’m less tempted to give it a try (tho I’m happy to help from mid April on). Thumbs up!
Hey Dieser,
Thanks for the suggestion of your plugin.
I had a quick play with your plugin and see it’s early in its development stage by the few bugs that arose, my question is, why not try port github.com/daviferreira/medium-editor to Kirby.
Hi @Boycce,
The plugin actually uses exactly that medium.com editor clone you mentioned. As I said, it’s not 100% ready though.
Maybe you should check out the develop branch, it’s quite a bit ahead of the code at the master branch and has many bugfixes already implemented.
Would you mind posting the issues/bugs you encountered either as issues over at Github or simply as a reply to this post? It could really help to make the plugin stable as soon as possible.
Cheers, Jonas
@DieserJonas Wow, great plugin! I’ll test it too 
How about the Initialization options of the original medium editor? I really like them.
Not on medium, but the medium-editor on github has options like:
To overcome some issues with html content being pasted into the editor (which could break the html to markdown conversion) these two options are enabled for now for all editor instances.
IMHO, having to reformat some pasted content is much less troublesome then a completely broken content file.
I think the same way - still I believe more options are always better 
(Do smiley look weird in Discourse or is it just me?) Its also about firstHeader: HTML tag to be used as first header. Default: h3 and the others.
That´s a great plugin especially for websites that are used by non developers. Hard to belive, but the markdown syntax is to hard for some clients. Even with instructions. I will test your plugin too…
This is actually configurable. You can set the first and second header either from your config.php file globally or on a per field base from your blueprints.
The same functionality has been implemented for markdown headings styles, the “doublereturns” setting and the buttons the toolbar shows.
If you have some other things in mind, please feel free to let me know or even open issues over at Github. 
PS: And yes, the smileys do look a bit odd 
I will 
(And some text, because I need 20 characters)
It’s really weird, I built websites for clients for more than 12 years — small clients, medium clients, bigger clients — and I never ran into any issues with Markdown with them. Maybe I have weird clients, I don’t know
In general I think you should break down data as much as you can to avoid any kind of formatting at all. All formatting should be done in the frontend maybe except some links or bold text. That way you always keep more flexible and future-proof. That’s the ideal situation for me. Of course this is not always doable in longer articles and for such situations such a plugin is definitely helpful, but please keep in mind that any kind of formatting the client does is mostly irreversible and uncontrollable.
Thanks for your insight @bastianallgeier.
I had the same thoughts when a client first contacted me regarding such a field. I never had any issues to convince clients to use markdown up until then. It’s really easy after all.
However, since I just provide the service and the client wanted to have such a field, I went ahead and built it. Fortunately, we agreed to release it as open-source, so others could benefit from it, too.
I do know that you have to be very careful with html markup being embedded into markdown and that it’s generally not a good practice. I learned the hard way creating this plugin. That’s why, once I do a proper stable release, I will enable a limited feature set only (the toolbar will offer options whose generated html markup can be fully translated into plain markdown only). If I do it like this, the toolbar is just a more convenient way of styling the default textarea buttons and the user get’s a realtime preview.
After all, the plugin tries to convert as much of the user input as possible into plain markdown upon saving.
Any advanced user/developer will be able to enable more features depending on their needs. It will be made sure in the documentation, that this may include some risks and is not always the best option.
Lots of discussion already going on, I don’t want to derail it, but personally I’m quite happy with Kirby storing everything in Markdown format - it’s so much more future-proof. But I have the same problem - the majority of my clients just don’t want to learn how to do Markdown-style text formatting. That leads me to the necessity of a WYSWIG editor that outputs to Markdown. I’ve been messing around with Hallo.js, I think it might do the job, but I haven’t tried attaching it to the panel yet. Going to try on my next project.
If it works, the best thing about the Hallo editor is that you can extend it very easily. Configuring it to output KirbyText flavored Markdown will be extremely simple.
I know the feeling. Most of my clients love wysiwyg editors, and are reluctant to write plain Markdown. On the other hand my oldest client (80 y/o) uses Markdown and likes it…
The Medium editor is very nice, but it tries hard to hide Markdown.
Hallo.js is nice too, but then you have too separate ways of writing. You could just hide the text field and pretend there’s only the regular wysiwyg, but then you can’t use markdown at all in the contenteditable.
Under the hood both still output html in the contenteditable and translate it to Markdown, which I find a bit hackish.
I love what editors like Byword or iA Writer do: plain Markdown with just enough syntax highlighting, so it does not look as dry. With a custom stylesheet it could give a good idea of what the final page will look like. Add a few buttons and you’d get the best of both worlds.
Unfortunately it seems very difficult to achieve in a browser, and I haven’t found any good implementation yet.
I have one particularly savvy client who uses the Byword editor to write his content, then copy/pastes it over to his Kirby site. I ought to set up Dropbox synchronization for him.
Stackedit has this kind of syntax highlighting, but it’s a huge project that doesn’t really work on mobile especially on phones. I would love something like a barebone version of Stackedit.