I have both WYSIWYG and CK-Editor modules installed and enabled in my site. However, in response to a recent post (and elsewhere) I was told that I should NOT have both modules installed as they conflict with each other!

The module I am currently trying to configure (Media) specifically says that I need WYSIWYG AND CK-Editor

In the latest version of Wysiwyg (7.x-2.1) profiles allows me to select the editor for use with the Wysiwyg module. As CK-Editor was installed, it allowed me to select between CK-Editor or No Editor.

Opening up 'Installation Instructions' it lists a number of possible editors. The FIRST one is CK-Editor! I searched for the other editors listed, on the drupal.org website and found the following:
FCKEdit - latest version 6.x
jWysiwyg - replaced by Wysiwyg API
markitup - latest version 6.x
NicEdit - replaced by wysiwyg api
openwysiwyg - latest version 6.x
TinyMCE - replaced by wysiwyg api
whizzywig - latest version 6.x
wymeditor - discontinued
yui editor - latest version 6.x

I am running Drupal 7.7 Not Version 6! I want an editor - not another API on which to plug another editor!

On your main module page http://drupal.org/project/wysiwyg under the heading 'Supported editors/plugins' The FIRST editor listed is CK-Editor. It then goes on to list the ones listed above which are either for Drupal version 6.x or replaced by the Wysiwyg API or discontinued.

So, I have two questions:
1. Is CK-Editor compatible with WYSIWYG or is it not?
2. If it is not compatible, then which editor IS compatible with WYSIWYG 7.x-2.1 running under Drupal 7.7?

WHICH EDITOR SHOULD I BE USING????

Comments

Status:Active» Fixed

I should NOT have both modules installed as they conflict with each other!

Correct. The ckeditor.module from drupal.org is NOT the editor itself. It's an integration module to bring CKEditor to Drupal. You need the library from ckeditor.com, for both wysiwyg.module and ckeditor.module, but you only need one of the modules.

1. Is CK-Editor compatible with WYSIWYG or is it not?

Wysiwyg module is compatible with the CKEditor library from ckeditor.com. Wysiwyg module is not compatible with the CKEditor module from drupal.org. (Pitfall: Wysiwyg module is not compatible with the "Drupal edition" of the CKEditor library from ckeditor.com, because they've, for some reason, decided to bundle the Drupal CKEditor module. Use the standard edition from ckeditor.com)

2. If it is not compatible, then which editor IS compatible with WYSIWYG 7.x-2.1 running under Drupal 7.7?

All of the editor libraries you listed are compatible with Wysiwyg module. But you've listed version numbers from Drupal modules integrating these editor libraries with Drupal. Some of them have been replaced by Wysiwyg module, which supports multiple editor libraries.

Look at the links in the Installation instructions table when configuring Wysiwyg module. They link to the editor libraries' download pages. You need to download the editor libraries separately because drupal.org doesn't allow most 3rd party libraries/code in their repositories for a number of reasons. But you don't need to download another Drupal module to use any of those libraries with Wysiwyg module. The other modules either existed before Wysiwyg module, or have a slightly different approach or feature set compared to Wysiwyg module - which is why they exist as separate projects focusing on integrating a single editor library with Drupal.

Thank you very much! It all makes sense now.
I've now disabled the CK-editor module, and downloaded the CK-editor module from their website (though without your pitfall warning I would likely have downloaded the Drupal version rather than the correct one at the top of the page), copying it to the sites/default/libraries folder.
Now I can use WYSIWYG module with the CK-Editor library!
Thanks again!

I'm glad I could help.
Btw, in the future we'll show a notice about the "Drupal edition" of CKEditor, and perhaps other things to think about when installing certain editors. Progress updates in #1352426: Allow editors to expose install notes (and clarify CKEditor library download).

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Priority:Major» Normal
Status:Closed (fixed)» Active

Thanks, TwoD, this helped, but I'm still confused as to what the differences are between using the ckeditor module vs the wysiwig module if one wants to use only one editor - CKEditor - on a Drupal site. Any recommendation? E.g. is the configuration easier for the HTML block formats menu with one of the two modules?

Thanks!

How easy one or the other module is to configure is very subjective, and I haven't used ckeditor.module much so I wouldn't be the best person to answer it. They do have the advantage of only needing to focus on one editor so they can put more time into the Drupal GUI and perhaps make a few specialized plugins for module integrations (for wysiwyg.module, most other modules needing integration with one or more editors provide their own plugins via Wysiwyg's API).

With Wysiwyg module you can certainly configure the CKEditor library to work exactly the same way as when used through the standalone CKEditor module, but today you might need to provide a code snippet to do it via hook_wysiwyg_editor_settings_alter() (see wysiwyg.api.php).

There's currently a patch to let you use a simple syntax for customizing the CKEditor Styles dropdown in #746524: No Font Styles for CKeditor, but since the Block Formats dropdown is very flexible and uses fairly complex settings object structures we've not yet come up with a GUI for it. The alter hook becomes very handy in this case as you can build that structure exactly the way you want it in a small custom module and hand it over to Wysiwyg/CKEditor. Even if Wysiwyg gets a GUI for configuring these settings later, you won't have to worry about your customizations being overridden after an upgrade as your module always has the final word on which settings are passed to the editor. I do not know how ckeditor.module handles such settings overrides now, or if they just expect you to edit the CKEditor library files directly - something we avoid to make installing new versions easier.

Why should I use Wysiwyg instead of the Ckeditor module? Is there any benefits I'm missing?

If you're missing sometething depends mostly on what you need and your own preferences. The modules use a bit different approaches to configuring CKEditor and how other modules integrate with it. Wysiwyg has the beginnnings of a cross-editor API allowing simple access and plugins to be written once for use with multiple editors.

I suggest you look around for projects provinding editor plugins, such as media related modules, and see which of Wysiwyg.module or CKEditor.module they support. Some support both by talking directly to the native CKEditor library API if it's there, else it talks to Wysiwyg which in turn relays things to the editor.

Wysiwyg also allows for direct access to the native editor APIs if needed, but that also means your module has to write one plugin for each editor you're supporting. Which is why we're trying to create a cross-editor solution for the most common operations.

Status:Active» Fixed

There's not been any activity or follow-up question in this issue for quite some time so I'm closing it to clean up the queue a bit. Feel free to change it back to active if something is still unclear.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Status:Closed (fixed)» Active

"The other modules either existed before Wysiwyg module, or have a slightly different approach or feature set compared to Wysiwyg module (.....) They do have the advantage of only needing to focus on one editor so they can put more time into the Drupal GUI and perhaps make a few specialized plugins for module integrations (.....)"

I am considering using CKEditor for a D7 site . I never used CKEditor before and did almost all customization (styles, blocks, custom html attributes etc) using hook_wysiwyg_editor_settings_alter plus one plugin.

I will transfer the D7 site to D8 as soon as there is a release. And here is the question: which of the two approaches to CKEditor customization (wysiwyg module with standard CKEditor edition or ckeditor module with Drupal CKEditor edition) is closer to what will be implemented in D8? In other words, assuming I'll be using the CKEditor shipped with core in D8, which type of integration is better to learn now to have easier time later?

D8 core provides a very slim WYSIWYG editor interface in the Editor module, which is then implemented by a new Ckeditor module, both of which look quite different from the D7 Wysiywg and Ckeditor modules. The new CKEditor module will be shipped with D8, so I'm not certain we will even need to re-implement that for D8 in Wysiwyg module.

I've only made test conversions of Wysiwyg to the D8 framework so far, while it was still very much in flux, so exactly how the D8 version of Wysiwyg module will turn out is to be determined. When I did it, D8 did have the new class based Plugin system with annotation discovery, where both editors and editor-plugins are implemented as actual Plugin classes handled by different plugin managers. That will be the largest difference when it comes to how settings and plugins are managed, at least internally. For D8, you will need probably need to convert your plugin hook implementation to a similar class, unless that plugin discovery mechanism can be kept intact. The settings hook in Wysiwyg may not need to change at all. D8 will use CKeditor 4, which is currently only supported by the Wysiwyg -dev snapshots.

Compared to D7, all D8 modules will be quite differen. I will however try to make the changes to Wysiwyg for D8 as transparent as possible from a developer POV. But as they say; the drop is always moving.

Hope that clears things up a bit.

Since CKEditor has been chosen as the default editor for Drupal 8, would it be an idea to add some text about that on the top of the WYSIWYG project description, and include a link to the CKEditor project? Perhaps using just the CKEditor module from the beginning will ease future updates, by reducing the risk of different mark up, as well as improving familiarity with the CKEditor? Also, the number of CKEditor project installations is still rising, whereas the WYSIWYG project is stalling.

By the way, the link to "This project needs your help" (http://unleashedmind.chipin.com/wysiwyg-3x) doesn't work.

I would like to update the project page more frequently, but I personally don't have access to do that. Sun is the project owner and the only one who can edit it, but his focus has been elsewhere and trying to get replies on Wysiwyg module related questions from him has, TBH, been a bit frustrating. Don't get me wrong, I have a lot of respect for sun and understand why he can't be around much here anymore.
I'll try contacting sun again, and see if we can do something about the project page.

I don't think using the CKEditor module from the beginning will make a difference when moving to D8. The generated markup is pretty much the same (depending on which plugins you've used, of course) and many plugins support both modules.

Yes, we've stalled, and I blame myself for that. I don't have any plans on quitting or intentions of letting Wysiwyg stay stalled though.

Perhaps you could be elevated to co-maintainer, or perhaps take over the project if sun has other priorities these days? It would make sense, since you are the one committing the most patches recently.

My thinking behind mentioning the CKEditor project on the WYSIWYG project page is mostly because using the CKEditor module from the beginning filters out some "noise" in the installation process for new users, since there is only one editor to deal with. But I do realize that there is also a place for the WYSIWYG project, in case people want to use other editors like TinyMCE.

Don't beat yourself over the head about the statistics. I think it is only natural that people gravitate towards the CKEditor module, after it was officially selected to be the editor for Drupal 8. Thanks for your effort on this module.