The current Grav Admin editor uses a WYSIWYM (what you see is what you mean) editor that requires to learn Markdown even if one uses the provided buttons only. Secondly, the markup is visible in the editor which is not everyone’s taste. However, markdown is very powerful and Grav admin editor even allows you to mix HTML, Twig, Markdown and Shortcodes (or other content-related plugins).
With a WYSIWYG (What you see is what you get) editor the specific markup for formatting the content is hidden. Presently, almost all WYSIWYG-Editors render their content into HTML. There are some editors out there, that generate Markdown syntax, but they are really limited in the syntax they use (no Twig, shortcode support etc.) and remove everything they don’t understand.
This is a community request to elaborate more on the thread started at https://getgrav.org/forum#!/general:admin-panel-and-grav-viabil to gather ideas and brainstorm what your favourite Grav admin editor should support and be capable of. It is enough to have a WYSIWYG editor that allows you to write down all your text, twig, shortcodes etc. that gets processed into HTML without getting back, or do you need more? What is it that your hearts beating faster?
Please be as detailed and as concise as possible to simplify creating a wish list of features for a possible yet not even existing editor.
First, for me it would be far sufficient to have a WYSIWYG-layer on-top of the existing hybrid-WYSIWYM. That is, a “writing-mode” wherein formatting is hidden. When I need to format the hybrid-editor works great, but when writing it can be distracting. So the writing capabilities of the increasingly popular zen-writers, but minimally so that formatting-options are discreet or preferably hidden.
Second, whilst I can see the benefit of translating Twig, shortcodes etc. before content is saved as Markdown, I fear this would mean a lot of content would include messy code. So I would at least want it to be optional when this is processed, so I can save pure-Markdown with Twig, shortcodes etc. stripped out, save it unprocessed, or save it processed. This is a technicality, but very important for being able to edit content outside of the Grav-editor.
Third, one fantastic feature that is included in a “lot” of editors these days - like on GitHub, StackOverflow - is direct input of images. That is, pasting images from clipboard to be saved behind the scenes and inserted into th e text, or simply drag-and-dropping them there. This requires fairly little of the editor itself, in terms of involvement other than inserting the image code for Markdown, but makes the process of writing much more efficient - no need to separately manage media outside of writing.
I spent a lot of time on making StackEdit available in the instances I run, partly because I had a display problem with the built-in editor, partly because I felt that users with less experience need at least a visual side by side control/preview of their markdown editing efforts. This week I learnt that originally the built-in editor operated with a side by side preview like StackEdit. In my implementation I enhanced StackEdit to allow images to be dragged and dropped and I added some of the extras available for GRAV and summary editing. That’s not really a layer as suggested by OleVik, a proposal that sounds good. In normal editing mode a WYSIWYG Layer with some reduced and markdown compatible features and in expert mode an improved version of the built-in editor, that would be great. Improved in expert mode means that I would still like to see side by side preview again, the possibility to configure layout and color schemes and an improved media handling.
Apart from this, StackEdit has another great feature that’s worth investigating: In the standalone version it all ows local storage and remote publish ing, including Wordpress instances. Why not GRAV instances? That’s something I have proposed as a nice feature.
For whom do we want a better editor in the Admin panel? And from different users perspective, what defines “better”?
Would it help to identify maybe three or four target groups or even persona’s? After all Grav is used in the field of webdesign and interaction design, so we should be able to do that.
thanks for the diverse answers. Let’s summarizes things a little. From the answers the Grav editor seems already be in a good position. It can be more distraction-free and should provide a drag-&-drop image upload method. I opened an issue here Admin Editor enchancments · Issue #997 · getgrav/grav-plugin-admin · GitHub to collect some ideas, I think, can already be realized.
In this thread I really like to hear what do you expect from a good WYSIWYG editor in Grav. As @OleVik pointed out there should be a distinction between simple and expert mode. As far as I understand, the expert mode can already use the editor Grav’s provides, but for the simple mode it should be more WYSIWG-like.
@bleutzinn
For whom do we want a better editor in the Admin panel? And from different users perspective, what defines “better”?
I really like to hear different users perspectives (devs, designers, customer needs). I specifically ask, whether a full-blown WYSIWYG-editor is something that people most want or not. And I ask because there were are a lot of discussions going on, that the Admin edit or is a pain for clients (also that they have to learn Markdown). And I really like to understand the problems, before I start writing on a “better” Admin editor integration that will find its way into the Grav admin plugin.
At the moment it seems to me, that the Grav Admin Editor does already a lot of things good and only needs some improvements, and that the discussions in several other older threads can be considered as solved.
I am surprised about the '‘what is better’ question. I have yet to me a non-techy user that would go anywhere near Markdown by choice.
Flat-file CMS systems that rely on a Markdown based editor must not forget that for most users a WYSIWYG editor the norm. So developing a system with Grav for a client who will edit content means recognising that we are taking something away from the client. This is especially true for any clients that are used to Wordpress and the like.
So for me there is no question about why this should be done. It must be done for Grav to be a sensible replacement for Wordpress from a clients / users point of view. And, in the end, they are the ones we work for .
Hello,
i also think, that from a customers point of view learning markdown could be a bit too complicated. Most of my customers are used to work with a ‘normal’ WYSIWYG editor.
Maybe a visual side by side preview would be a good compromise and makes it easier for customers to learn Markdown.
The features of the current editor are sufficient. Improving the insertion of links and images - the possibility of specifying crop sizes for example - would be a great help for the editor.
Has anyone of you experiences with Grav and ‘normal’ editors ? What about their feedback ?
I have not had issues with people not wanting to learn Markdown, in fact, once they see it they seem to embrace it happily. the current editor in the admin area seems to work well, I don’t see a need to change it.