CKEditor Formatter
This is an open discussion with 185 replies, filed under Extensions.
Search
CKEditor Formatter
updated to version 0.6
on 8th of December 2009
When this is production ready, it will no doubt be a defacto install. great work Tony!
This is cool, thanks for putting it out there. Would anyone be able to explain the advantages or disadvantages of using this or TinyMCE?
The problem I have with TinyMCE is that if someone copies and pastes something into it it’ll add loads of extra markup to keep the style, font, all of that. I’ve even had it copy and paste inline javascript!
Is there an easy way—or, better yet, is it done by default—to restrict what elements are kept in a copy and paste? For example only keeping:
- strong
- anchor
- paragraph
- emphasis
- bold
- italic
- lists
- tables
Everything else would be dropped. It would be even better if bold and italic were converted to strong and emphasis.
I believe Rowan has created a filter formatter of sorts that will take in messy markup code and pass it through a HTML Tidy then an XML validator and remove embedded style junk. I’ve only seen a very rough version of it and I’m not sure when he’s planning on releasing it.
The problem I have with TinyMCE is that if someone copies and pastes something into it it’ll add loads of extra markup to keep the style, font, all of that. I’ve even had it copy and paste inline javascript!
Same here. Clients like to copy and paste from emails and Word documents into TinyMCE or CKEditor. This shouldn’t be a problem, only, the editor will maintain Word formatting in a convoluted mangle of proprietary tags, annoyingly-namespaced XML and inline CSS. CKEditor does have a “Paste from Word” option but it isn’t failsafe, and you still need to remember to use it.
In the past we have had to train clients to paste text into a text editor, then copy/paste from there into Symphony. It’s a crap workflow for them, so is certainly a major weakness. For that reason alone we shy away from rich-text editors, favouring Markdown wherever possible.
For that reason alone we shy away from rich-text editors, favouring Markdown wherever possible.
Same here.
I strongly agree in preferring markdown (I just went and fixed another website issue due to TinyMCE). The problem is my clients want more control and I don’t like making them remember Markdown syntax.
Ideally, I’d love to be able to include the text format bar used on this forum but if I remember correctly there were specific reasons why we could not include it in Symphony?
there were specific reasons why we could not include it in Symphony
As far as I remember, Lewis found out that it doesn’t work if you need multiple instances on a page (which you might need in the backend).
That’s what I remember as well. Has no one come up with a solution or alternative? This is one of the few things that, in my eyes, keeps Symphony from being perfect.
Does anyone know how other CMS, such as WordPress and Joomla, handle the problem?
As far as I remember, Lewis found out that it doesn’t work if you need multiple instances on a page (which you might need in the backend).
We’ve just done a project (albeit not Symphony) that uses multiple CKEditor instances on a single page. No idea how it was done… but it can be done.
I have sections in my own installation (http://thecocoabots.com/) that use multiple instances of this editor without issue. It doesn’t seem to work with Google Chrome at the moment (I haven’t had time to investigate), but after a few tweaks here and there it’s working very nicely everywhere else.
As far as I remember, Lewis found out that it doesn’t work if you need multiple instances on a page (which you might need in the backend).
I believe my comments regarding multiple instances were in regards to widgEditor (although I do remember having the same problem with a couple other editors). I’m not a fan of CKEditor.
So I remembered it incorrectly.
Anyway I wouldn’t like to see any of these editors in Symphony by default.
As default, no but it would be nice to have a go-to option for client work. Whichever one it is has to go beyond the “Paste From Word” sort of buttons since most people probably won’t bother. They’ll think, “What’s the difference? I’ll just paste by right-clicking or ctrl+v.”
The reason I like using Markdown with an editor like the one above is any text pasted in automatically loses all styling and then you add it back by clicking the corresponding button.
Wow… I guess I disagree with almost everyone here… I thought you guys always went by the mantra “The simplest answer is almost always right”? How is it more simple for your clients/users to have to see and understand markdown rather than just hitting “bold” and seeing the text turn bold?
I understand WYSIWYG causes problems and I want to figure the answer out as well, but aren’t you guys just choosing what’s “simpler” for yourselves as developers rather than what’s simpler for your end users?
I’m kind of with TheJester12 on this too!
Clients want a lot, and sometimes things can’t be done.. but a stripped down wysiwyg like the basic CKEditor is far better to explain to a client than setting out a series of rules for markdown. I have also begun using the mediathek 2 extension for adding images to entires rather than using the wysiwyg to accomadate this.. So granting the client access to H tags and lists plus bolding text and a hyperlink is far easier in a wysiwyg than explaining html to them.
EDIT Horses for courses I’d say!
There are two big problems with rich text editors: floridity and browser inconsistency. The first problem is caused by the developers who are trying to mimic fully featured word processors. The second is a result of totally different approaches by browser vendors.
While the first problem can be solved easily, the second cannot.
While this might be acceptable for some projects, it is not in the context of an XML based CMS.
While the known rich text editors might be great for end users, they are not for Symphony developers.
In Symphony we need valid markup and in order to be able to manipulate the HTML output we need to have consistent markup across browsers that we can match using xPath. I’ve been working on a small rich text editor over the last months that only allows basic format (similar to Markdown). If you ever tried building your own rich text editor that tries to conform to the same standards across the different browsers and operating systems, you will see that it is a hard job. It requires a lot of code to simply teach all browsers to wrap content in paragraphs consistently and stop using div
or span
elements. And if we start talking about inline formatting: the options to markup strong text vary from using <strong />
(Internet Explorer, Opera) over <b />
(Firefox) to <span style="font-weight: bold" />
(Safari). And there exist funny tags like <br _moz_dirty />
here and there – and you never fully understand why they are there (at least these tags state what they are: dirty).
As long as these fundamental problems of rich text editors on the market have not been solved Markdown is the better choice in the Symphony context. Even if rich text editors are easier to understand for editors. Even if I’d like to have a rich text editor conforming to XML standards myself.
Fair point Nils.
Create an account or sign in to comment.
A new extension, “CKEditor Formatter” is now available for download. Comments and feedback can be left here but if you discover any issues, please post it on the issue tracker.