Improved Text Editor Capability

michaelkpate · 2015-10-15 16:26:56

In 2005, this was suggested.

davidm wrote #86694:

Even with Textile and quicktags (which I love ! Thanks Hakjoon and Mary), decent WYSIWYG editor are still being often discussed on these forums. Most of us have encountered resistance from some of our clients, who want WYSIWYG no matter what.

Even if some are better than other, browser compatiblity and tag soup markup are still plaguing those editor… A path toward innovation and maybe reconciliation with WYSIWYGs is AJAX. Forget the hype, the web 2.0 stuff let’s just say it can be helpful at times.

But enough talking, here is what brought me here : a demo of an AJAX based WYSIWYG editor.

I don’t know what it’s worth, if it can be used for textpattern, but it sure looks good from a user’s point of view… what’s your take on this ? Let’s push it a little : could we build a Textile AJAX editor with WYSIWYG ??? That would be awesome…

I think things have progressed a bit since Web 2.0. And since it has a nearly hijacked a different thread, why don’t we discuss it here?

Thoughts and Suggestions are welcome – But as always it will be up to the development team (unless someone submits a really nice patch) what the final choice is.

philwareham · 2015-10-15 16:32:29

I’m going to see if the author of SimpleMDE would be interested in adding Textile support, since I like the script and the licence is MIT (which is fully compatible with our GPLv2 licence).

michaelkpate · 2015-10-15 16:50:00

philwareham wrote #295815:

I’m going to see if the author of SimpleMDE would be interested in adding Textile support, since I like the script and the licence is MIT (which is fully compatible with our GPLv2 licence).

If you like it, I like it. It will be interesting to see how he responds – because he seems to be a really big Markdown fan.

NicolasGraph · 2015-10-15 16:53:27

philwareham wrote #295815:

I’m going to see if the author of SimpleMDE would be interested in adding Textile support.

Thank you for that! SimpleMDE looks great.

hcgtv · 2015-10-15 17:31:22

philwareham wrote #295815:

I’m going to see if the author of SimpleMDE would be interested in adding Textile support, since I like the script and the licence is MIT (which is fully compatible with our GPLv2 licence).

Since it uses CodeMirror, which already does Textile, it’s not a stretch to use SimpleMDE and create SimpleTXP.

Also see, Codemirror plugin and textile bar, MarcoK is ahead of us.

GugUser · 2015-10-15 20:55:58

What is with rah_textile_bar (and what is with Gocom ;-) )?

Bloke · 2015-10-15 21:13:48

hcgtv wrote #295820:

Since it uses CodeMirror

Just as an aside, I tried to integrate CodeMirror (and other) syntax highlighters in the Plugin composer. Didn’t end well. Despite the docs claiming you “just” need to add a class to the relevant textarea and CodeMirror would do the rest, it ended up blanking out the code box or generating script errors on the admin tab for large plugins. Things might have changed since 20xx when I tried it of course. But I also noted back then that it was a) big, and b) slow to render.

Although I forget which one, I know mrdale uses some kind of syntax highlighter on his sites (for Forms/Pages, not necessarily content-based markup as being discussed here) and I find it the single most annoying thing in existence to edit under. Apart from the slowness of waiting for it to render the page all the way from Seattle, WA to Leeds, UK and then jolting as it swaps out the textarea and redraws the screen, the indentation scheme alone is like having to wear a jumper your grandma knitted for your birthday. In summer. It irritates me like crazy.

Anyway, back on track, any textile markup scheme we consider needs to:

Have little or no impact on the speed of the admin side. Nimble and zippy are order of the day, even over long distances.
Be extensible: if we can hook into its API and extend that to plugin authors then anyone can alter the default bar to offer their own mix of functionality.
Offer a suite of markup languages (not necessarily out of the box, but have the ability to do so). From 4.6.0 we allow you to install your own markup system of choice and select it for editing. So, cf. the above point regarding extensibility: abc_markdown, for example, might add Markdown support to all articles, and it’d be bloody terrific if it could hook into a markup bar callback at the same time and serve up a config file for Markdown support, using the core’s chosen markup tool for rendering it.
Offer a preview ability. Although this may not be of use to some, having the ability to see how your content will render — albeit not in the context of the site — is something the core or a plugin could offer. We have the HTML view and other icons nearby that are begging to be reworked. There’s not much point having it render stuff with your template code on the back-end (might as well just refresh the site or use the View button for that) so any txp:tags you embed in the article body will render verbatim, but as a self-contained quick check it’d be a nice thing to have, even if core doesn’t offer it directly on day one.
Be compatible with our licence.

For my money (i.e. gratis, except for a nod back to the author’s site in the docs) MarkItUp is the clear winner so far. From what I can tell (and I haven’t tried to integrate it yet so I may have missed something) it ticks every box above, and then some. And it has natty shortcut keys too so, for Textile, you can select a chunk of text and hit CTRL-b to bold it, CTRL-i to italicise, hit CTRL-2 to get an h2. and so forth. So any LIbreOffice or Word users can just do whatever shortcuts they always have done or use the icons. And you can write functions for it to do whatever the hell you like, all configurable from a JSON document. And it has a tiny base file so it’s quick.

Be interesting to see what SimpleMDE can bring to the deal, but it’d have to be pretty special (or MarkItUp would have to have a serious flaw I’ve yet to discover) for it to be knocked from my top spot at present.

hcgtv · 2015-10-15 21:37:26

Bloke wrote #295825:

For my money (i.e. gratis, except for a nod back to the author’s site in the docs) MarkItUp is the clear winner so far. From what I can tell (and I haven’t tried to integrate it yet so I may have missed something) it ticks every box above, and then some.

We have a plugin that uses MarkItUp, made by Petri Ikonen.

And we got funds, let’s go shopping, it’s only $6 ;)

Bloke · 2015-10-15 21:53:57

hcgtv wrote #295826:

We have a plugin that uses MarkItUp, made by Petri Ikonen.

Absolutely. A plugin is perfect for this kind of thing. I only mentioned my preference in case it’s deemed appropriate to include some kind of editing bar in core that plugins could extend and offer InsertMarkUpLanguageOfChoice.

One argument for it is that it helps new users get over the Textile learning hump. And I’d much rather have a bar that helped people write a simplified markup system of any denomination than one which writes HTML directly. I don’t think I’ve found one that writes decent HTML yet and allows hassle-free editing after the fact (though maybe I’ve not looked hard enough). Baffles me how TinyMCE is so popular.

hcgtv · 2015-10-15 22:26:18

Bloke wrote #295827:

One argument for it is that it helps new users get over the Textile learning hump.

Totally agree, we messed around with WYSIWYG editors years ago, hakjoon and mrdale were involved. Back then it was slow, nowadays, things are looking brighter, leaner code bases.

philwareham · 2015-10-16 06:31:06

How have I misse kuopassa’s plugins? There are some very interesting ones there. I will buy the MarkItUp plugin and test.

I’d still be keen for a core solution though, even if I had to pay some funds to get it in there. I can’t rely on my clients learning Textile (or Markdown, even though they would likely be more familiar with that).

wet · 2015-10-16 06:44:53

philwareham wrote #295836:

I’d still be keen for a core solution though, even if I had to pay some funds to get it in there.

Which begs the question: What should core do?

Ship a WYSIWYG editor with core (e.g. CKEditor)
Ship a syntax highlighter with core (e.g. CodeMirror)
Ship a “human markup generator” user interface with core (e.g. markItup)

All three options are valid and serve a noticeable fraction of the target audience.

Additionally, we need to discuss and solve:

Would we ship alternate “human markup generators” with core to add another checkpoint to our marketing blurb (e.g. Markdown)
How does this all fit into the “installable text filters” concept and into a general pluggable architecture?

hcgtv · 2015-10-16 07:37:10

philwareham wrote #295836:

How have I missed kuopassa’s plugins?

My reply, for risk of thread deviation, is here.

sacripant · 2015-10-16 08:15:47

My point of vue.

Please, don’t make the mistake of imposing a solution in the core.
Each project and each user can have his preferences (markup langage, WYSIWIG, live preview etc).
Each option can be activated or desactivated.
Plugins are made for that.

For me it’s better to improve the core for :

Use the markup of choice for all fields and custom fields (and not only body and excerpt) in article panel but for fields in images too.
Add the possibility to add new “markup system” and other system (yes wyswyg too) of your choice in “markup select”.

If Textpattern is a CMS, it must be adaptable and not impose anything.
If you impose a solution, Textpattern become a specialised solution, as in his begining : a blogging system.
I would even advocate to out Textile of Txp corp and make an “official “ plugin.

Yes, I want have the possibility to choose Textile for except, a wysiwig for Body, markdown for a custom field, etc.

@Phil, and I thinks it’s possible to have a plugin maintained over time which improve the write panel as you want, if you have other interested users which want pay for that.

philwareham · 2015-10-16 08:22:35

Thanks Bert.

@robert

My opinion on this is…

Ship a “human markup generator” user interface with core (e.g. mark-up)

We just need a tool to help users format text without necessarily having prior knowledge of the Markdown/Textile syntax – this has the additional benefit of gradually teaching the syntax as the user will see that syntax added to text when they click the UI. We can also turn it off for users that don’t need/want the feature.

From my experience with full HTML generators (such as CKEditor), they produce some pretty nasty HTML sometimes (such as empty divs and spans and inline styling). I would not be keen on that kind of editor at all. Rachel Andrew over at Perch has done several talks on the topic of CMS WYSIWYGs and they also favour the markup interface approach (although they have opted for Redactor, which is a closed route for us).

The author of SimpleMDE hasn’t the time to produce a Textile version as he feels it’s too niche for him, but he would happy to see someone else take his code and proceed a version for Textile (it’s MIT licensed anyway). Not sure if that is an option or if MarkItUp is better. MarkItUp also has BBcode and Wiki Syntax support if in the future someone created Textpattern textfilters for those (which isn’t likely, but is probably possible).

Would we ship alternate “human markup generators” with core to add another checkpoint to our marketing blurb (e.g. Markdown)

I would ship the Markdown option in core, yes, but have Textile as the default setting (changeable in the prefs or at an article level if possible? Don’t know how that would be interchangeable with any current content). Markdown won – it’s time to accept that (although I prefer the Textile syntax personally).

Textpattern CMS support forum

#1 2015-10-15 16:26:56