Posted by Melissamcewen on June 18, 2010 at 7:44pm
Comparison of WYSIWYG Modules. So far only the WYSIWYG module and CKEditor, but I'll add more soon. If you want to contribute....the edit button is there :)
Comparison of WYSIWYG Modules. So far only the WYSIWYG module and CKEditor, but I'll add more soon. If you want to contribute....the edit button is there :)
Comments
yes, those two; what if installed both..?
They seem to be something of the best. Should CKEditor disappear and be fully integrated into WYSIWYG?
I have both MODULES installed, both directing to the same CKEditor files. They can work together, or sometimes CKEditor and for some other pages WYSIWYG.
I haven't figured it out yet (and now first busy with some other issues), what exactly are the pro's and cons under several circumstances?
Well, CKEditor is obviously
Well, CKEditor is obviously just specific to CKEditor, whereas WYSIWYG tries to play host to a kajillion different graphical and semi-graphical editors. I think WYSIWYG takes a "jack of all trades, master of none" approach - it may be simpler in principle, but the level of customization you'll have with it versus a stand-alone module is just not as deep. There seem to be many in the community who favor killing stand-alone editor modules and having everyone just use WYSIWYG instead - a perspective I strongly disagree with, for the aforementioned reason.
The Boise Drupal Guy!
I think the WYSIWYG module's
I think the WYSIWYG module's approach is the correct one. The main difference to me seems to be that WYSIWYG module makes the assumption that an editor will be associated with an input format (e.g. Filtered HTML, Full HTML, etc). So you can create as many input formats as you need for different users/etc, and for each you can choose whether to use an editor, and if so choose the toolbar buttons, etc.
In contrast, CKEditor module (and most other standalone editor modules I think) take the approach that they will hijack specific textarea's and insert the editor's code. So they use an 'include or exclude' approach for setting which text areas will use the editor. This is fine when you start off just using the node body, but then later on you find other places which has the "input format" selector but the editor is not showing and you end up having to manage a huge list of text boxes which should use, or not use, your wysiwyg editor.
I recently switched from CKEditor to WYSIWYG and I think it is very much simpler to manage. Even though in theory it should be more complex, it turns out to be much simpler and IMHO better integrated into Drupal.
Okay, well, how textareas are
Okay, well, how textareas are targeted for editor replacement is a matter of perspective, I believe. I'm rather fond of the simple approach I use in the 3.x branch of [markItUp!](http://drupal.org/project/markitup) (though I just today realized that the code that's currently in CVS for that branch is actually the 2.x code… and it's been that way since February… arg. I'll fix it tonight), which is that only textareas to which input filters will be applied are replaced, and there's a "Disable markItUp!" link underneath the field. Clicking that link disables the editor immediately, but also permanently; it won't appear for that textarea anymore. (An "Enable markItUp!" link appears to allow you to turn the editor back on for that textarea.) Granted, markItUp! is much simpler in form and function than most other editors.
CKEditor's Include/Exclude approach feels a pretty hacky, yes, but, at least in my case, most of the sites I build for clients only need it on for three: node/add/*, node/*/edit, admin/build/block/*.
Needing to have different editors for different input formats for different roles, etc, strikes me as a nice feature if you need it, but heavy bloat when you don't, and most of the time you don't.
The Boise Drupal Guy!
comments, user profiles,
comments, user profiles, maybe some text fields but not others, etc. etc. it can get hairy, depending on the client's needs
Aaron Winborn
Drupal Multimedia (my book, available now!)
AaronWinborn.com
Advomatic
The aesthetics of "hackiness"
The aesthetics of "hackiness" are funny. To me, the whole reliance on complex configurations involving extra modules (Better Formats) and special configurations (create extra input formats) to achieve a simple end (prevent the editor from loading on field x or page y) is hacky, and adding a wildcard string-match to a field is elegant.
So, from my perspective, the old CKEditor approach (which the maintainers seem to want to get rid of in the 7.x version) is elegant, and the WYSIWYG approach is hacky.
Grim.
WYSIWYG lacks two features that are required on all our implementations, and a third that, while not critical, is highly desirable:
On the other hand, support for [3] is currently broken in CKEditor 6.x and 7.x (which appears to be due to a new method of supporting [2]), and [1] has been regressed out of the 7.x-1.x. So my current assessment of the state of WYSIWYG support in Drupal is "grim."