This module is duplicating what is already going on at http://drupal.org/project/wysiwyg. Please merge this with existing efforts at WYSIWYG.
See #462146: Add editor: CKeditor.
I disagree. The FCKEditor module has existed and thrived a long time while competing with WYSIWYG, which means that a lot of people prefer it. This is just a step up from that. This module can provide an interface and set of options specific to CKEditor, and that makes a lot more sense for people who only want to use CKEditor.
Why? Some people may not want the added overhead of the WYSIWYG API. Also, why can't this exist, yet FCKEditor module can exist? As can WYM Editor, YUI Editor, etc?
CKEditor trumps TinyMCE and other popular editors and is a great successor to FCKEditor.
I for one would love to see this editor on the fast track for support into a Drupal module.
It is not about competition. It is about working together to provide the best solution to the greatest number of people. Because when many modules offer overlapping features, we have to form groups dedicated to sorting them all out.
But this isn't an overlap with WYSIWYG. You can't say both modules do the same thing because they both give you a WYSIWYG editor, that's like saying ImageFIeld is the same thing as ImageBrowser because both give you a way to input images. The point of WYSIWYG is to make it easy to use any WYSIWYG editor with Drupal, and the point of (F)CK is to give you specific options and a specific interface for that specific editor. The two are actually in *direct contrast* with one another. One is a general solution, and the other is a specific solution. They're not overlapping.
WYSIWYG already supports FCKEditor, and CKEditor is being added right now per #462146: Add editor: CKeditor.
If you drew a Venn diagram, this module's circle would probably be entirely within the WYSIWYG editor's circle. In other words, 100% overlap.
Instead of coding a separate module, efforts should be directed at WYSIWYG to make it the best it can be.
Concerning "added overhead of the WYSIWYG API": please expand. I see little overhead. WYSIWYG is a simple module.
#6: there are quite a few things that FCK module does which WYSIWYG doesn't do. Therefore, not 100% overlap. Use WYSIWYG with FCK on a site and then use the FCK module on a site, and you'll a huge difference.
And in most cases, when there's a druplicate module, the lesser module will submit a patch to the greater module with any functionality that may be missing, but that can't be done in this case because the two modules are NOTHING ALIKE. sun (from WYSIWYG) would not accept this level of editor-specific code, so we'd be stuck with a ton of missing features.
Well, once we get #313497: Allow configuration of advanced editor settings and similar issues fixed the gap between Wysiwyg and modules like this one will soon be much smaller in terms of how an editor can be configured. Wysiwyg takes a different approach to where and in which circumstances the editor appears, so the gap will never be fully closed though.
OK, then work on those issues in WYSIWYG instead of diverting all the time to duplicate modules. :-)
People scratch their own itch. Let's not knock the guy for contributing code. Competition is healthy and contributed code is better than no code at all.
+1 for this module
+1 for WYSIWYG
If you got time to complain here, you got time to help get the CKeditor patch into WYSIWYG. Test and submit patches! #462146: Add editor: CKeditor
Please don't abandon CKEditor.
Saying this is a duplicate module with WYSIWYG and/or FCKEditor is kind of like saying that Iraq and Sweden are similar countries because both have the potential to be peaceful places.
Right now WYSIWYG does not have the advanced settings this module promises.
Right now FCKEditor does not support CKEditor at all.
My client needs to use CKEditor now and can't because there is no way to download this module. I tried WYSIWYG and it does not provide the customization I need.
+1 for this module
+1 for #10
Would love to see a customization configuration comparison. I currently use the FCKeditor module and am looking forward to using CKeditor for it's speed. I also am a heavy user of including/excluding FCKeditor's inclusion on body fields through my Drupal site. I also like the ability of forcing a simple FCKeditor profile on specific Body fields. Does WYISIWYG support that? Will it?
Unfortunately, WYSiWYG.API does not deliver with FCKEditor what it promises. You can check all the button options you want but that doesn't mean they will appear on the FCKEditor toolbar. The FCKEditor module, although it still requires you to edit the FCKEditor.config.js file manually, does a much better job at that. I have tried setting up CKEditor using the most recent WYSIWYG.API version and still don't get the toolbars I want. So it is not time to abandon development of a module that will fully implement CKEditor.
rsbecker, if you've found a bug with missing buttons, then please report it so we can do something about it.
Yes-- I'm forced to agree. My critical use case is not only different toolbars for different contexts, but also for different cck fields (ie i need a full toolbar on the body field but only a minimal one with 2 or 3 buttons on any of several cck fields and i have 3 or 4 of those 'mini' toolbars). With the fckeditor module, and hopefully it's ckeditor successor, it's pretty simple to do. Unless I missed it somewhere, and that's entirely possible, I could not figure out a way to do this with wysiwyg module (just today I took the current v2 for a test drive with ckeditor).
Looks like no work on it in a year per #322433: Replace default editor status option(s) with intelligent logic.
I have WYSIWYG API set to show the following buttons with CKEditor.
Bold, Italic, Underline, Align Left, Align Center, Align right, justify, bullet list, number list, outdent, indent, undo, redo, link, unlink, anchor, image, forecolor, backcolor, blockquote, source code, horizontal rule, cut, copy, paste, paste text, paste from word, show blocks, remove format, character map, HTML block format, font, font size, font style, table, search, replace, select all, create DIV container, flash, fitwindow, check spelling, teaser break
But I do not have buttons for all of those in content forms. The toolbar includes only the following buttons.
Bold, italic, underline, aligh left, align center, align right, outdent, indent, undo, redo, link, unlink, anchor,image, text color, backcolor, blockquote, source, horizontal rule, cut, copy, paste, paste text, show blocks, remove format, insert special character, format, font, size, styles, table, search, replace, select all, flash, spellcheck, teaserbreak
Until WYSIWYG API with CKEditor can give me the same toolbars I have with FCKEditor module and FCKEditor, it is not a replacement for the latter and, I think, the folks developing the CKEditor module should continue.
Hope I'm not overstepping my bounds here, but with the amount of support this module has and the fact that the maintainer is working on it, I think it's safe to say this is won't fix at this point.
Actually, I wasn't asking for a fix. I posted a response to a message suggesting that the developers of the FCKEditor module should abandon efforts to create a new version that works with CKEditor. My reason for not supporting that suggestion was that WYSIWYG does not do everything needed. To which I received a response that I should let the developers know what was not working. My message today was a response to their request.
+1 for CKeditor
Each WYSIWYG editor is not the same: different logic, structure, features, plugins... Each webmaster chooses an editor, and I don't need more overhead on modules. If I use CKeditor, I'll stick with the CKeditor module.
Merge all into one module even give more headache to module's maintainers :P
@rsbecker, I wasn't replying to you when I marked as won't fix. I was replying to the OP.
Just a note to anyone that voted for abandoning this module in favour of WYSIWYG module.
We'll not abandon it because there's too many users that need easy, fully working and customizable solution, where it is possible to easliy use all available CKEditor features, right here and right now.
I personally really like the idea of having one WYSIWYG module, so when this dedicated module will be ready, I believe we'll also spend some time on the WYSIWYG module as well, for example to be sure that at least when Drupal 7 will be out (and commonly used), there will be an awesome support for CKEditor in the WYSIWYG module.
I think the WYSIWYG module is overkill for most site owners. You only need one good editor, it's not necessary to give different user groups different editors, what's the point.
When it comes to Drupal and modules, the less modules and less overhead the better performance. Using WYSIWYG module with 50 editors enabled is too much bloat.
Wordpress has but one editor and it simply works, no need to re-invent the wheel.
You're misinterpreting WYSIWYG. It does not come packaged with 50 editors. You install the module, then you install whatever editors you want. That can just be 1. This one works the same way, except you can never use anything but the 1 editor it supports.
Yeah, I understand that but it's apparently made to add many editors, one for everybody and you know that's exactly the way it will be used too. To use it with only one editor would be as I said over kill and excess bloat. There's no other benefit to using it other than to use more than one editor. I get it, it's an itch that needed to be scratched, still too much for only one editor, better off just adding the one editor. I don't see the point of adding more than one editor.
You make no sense.
WYSIWYG module is smaller than this module, so if you want to avoid "over kill and excess bloat," then WYSIWYG is your answer. Compare the sizes of the latest releases.
Your thoughts about more than one editor being "too much" are just your opinion and should not be enforced by an arbitrary constraint in module design. You can achieve your opinion on your own site with WYSIWYG by only installing one editor. I, on the other hand, will continue using two editors--one for regular filtered HTML for most users and a different, more capable one for full HTML for admins. Per you, that is just "an itch that needed to be scratched," for me, it's a real and needed difference in tradeoffs.
Yes, and for me ckeditor offers options and configuration that wysiwyg module does not. It's very much like 'one size fits all' clothing-- yes it may 'fit all' (imo more often than not it doesnt), but it probably only fits a certain subset of wearers well. I now use both this module and wysiwyg, depending on the needs of the site, and remain more convinced than ever that this module should not be deprecated.
WYSIWYG is not just overkill for most implementations -- it's also inadequate. I.e., it does not yet meet the basic requirements for a WYSIWYG editor on most complex websites.
Custom editor modules offer features that WYSIWYG does not offer and will not offer for the foreseeable future. For my own case, these include, but are not limited to:
* Sizeable input fields.
* Ability to edit the positioning and order of buttons on a toolbar.
* Specifying a custom toolbar for a specific field.
These are hard and fast requirements. WYSIWYG isn't meeting them, and will have a hard time meeting that kind of requirement generally without enormous overhead and complexity.
Now, for other sites I work on, WYSIWYG might be great: I might want to be able to dictate the editor by the role [yes, you can do that if you know how] or content type. But that comes with the cost of losing functionality that I require on other sites, and it on those same sites offers no functionality I need.
Really, this insistence that people get on the same page and all work on one project is just weird. People use platforms like Drupal so they can have options. This is one excellent example of that. Of all projects, Drupal is probably the one that needs this kind of 'same-page' cheerleading the least.
WYSIWYG does not offer ... Sizeable input fields.
Works with CKEditor with the latest dev release of 6.x-2.x.
WYSIWYG does not offer ... Ability to edit the positioning and order of buttons on a toolbar.
Configurable through admin/settings/wysiwyg/profile/[profileID]/edit. See Buttons and plugins and Editor appearance sections.
WYSIWYG does not offer ... Specifying a custom toolbar for a specific field.
I'll grant no progress on that one, but at least WYSIWYG's main maintainer agrees that the logic needs improvement: #322433: Replace default editor status option(s) with intelligent logic.
Aren, I wasn't clear on what I meant by "sizeable input fields."
What I meant is that you can have input fields that are different sizes. E.g., body field is large, alternate title field is small.
The last version of WYSIWYG that I evaluated (about two months ago at this point) didn't even have that on its radar.
If WYSIWYG now allows you to re-position buttons on the toolbar, that's great, and I'll look forward to using that feature the next time I use it. Which I do expect to do -- just not on any of the sites I actually get paid to build.
I admit I may not have understood you correctly. It would be great to file feature requests in the WYSIWYG project queue for missing features.
Not all WYSIWYG editors are the same. CKeditor has some features that others don't. They have different implementations, different plugin systems. With this module, we have the pagebreak and teaserbreak button implemented. I don't know if the WYSIWYG HTML editor module does that for CKeditor and others. The toolbar presets are modifiable, too.
A module for all (or almost) WYSIWYG editor is, IMHO, overkill.
If I could get a detailed list of features missing in WYSIWYG, I would be happy to open feature requests over there to see if we can get it working.
Does using this module limit me to one editor for the entire site?
What I'm not understanding is why this matters. People not working on a specialized CKEditor module does NOT mean that WYSIWYG gets developed faster or better -- to assume that it does is to assume that resources not expended in one place will automaticaly allocate themselves in another.
That's just not how social ecosystems work. They're not zero-sum games.
The issue smacks of simply wanting everything but WYSIWYG to go away. I'm really unclear on why that would be a good thing, from a standpoint of open-source ecology, but it definitely feels contrary to the "open source" spirit, to me. In fact it seems really important to me that altnerate means of getting an editor onto a site are available, in case WYSIWYG goes in some direction that seems ill-advised, or it turns out to have a huge security hole, or its development gets stalled, or [insert reason here].
Put another way: If WYSIWYG should win out, it will. If the CKEditor module doesn't get many users, it will die on the vine. When does it work, the Bazaar model (what open-source development is based on) only works when the bazaar offers a lot of options. This request seems aimed at reducing the number of options.
escoles, you're right that resources won't “automaticaly allocate themselves in another”. But in fact here (Drupal) AFAIK we look for duplicate modules so that authors can join force. That's good, too.
I love many sun's modules, and it seems that I understand sun's reason on WYSIWYG module. But in this case, again, not all editors the same. Users can have their choices of modules. Take the stats on January 17th, on total:
FCKeditor: 57,406 (decreasing)
CKeditor: 4,725 (increasing)
That says all. We shouldn't abandon (F)CKeditor.
Don't abandon this module.
I've been watching this issue for some time now and I frankly don't see the point in arguing...
There are some people that don't like ice cream. That doesn't mean there should be a law that forbids others from eating it. We live in a free world. Let people have what they want if they want it. And please... I am not saying stop arguing over this (because if I did, I would then cancel what I previously said about freedom), but please seriously consider doing so.
This is really pointless. If there are people out there that don't like ice cream, just don't eat it. Don't try to force others not to.
Thanx for considering my thoughts and sincerely sorry for adding another post in this reeeeeally loooong and pointless talk about this issue (that I believe shouldn't be in the issue queue in the first place).
Don't abandon the CKEditor module.
I find that using one editor is simpler than maintaining multiple editors.
So why make things more complex with a whole wysiwyg framework?
The one module is easily configurable to do suit all my clients varied sites.
If needed, extensive developer docs/forums explain every detail.
I've used the WYSIWYG module, and I've used this module. For me, I didn't see any use in the WYSIWYG module - I only need one editor for my site, and this module provides that. The WYSIWYG module works well, and it's a well designed module, but it's just not the module that suits my needs.
the way I see it. When WYSIWYG gets support (doesn't even have to be flawless, although that would be nice) for CKeditor then I will switch. But CKeditor blows even FCKeditor out of the water to me and when I realized WYSIWYG didn't have support for it, I jumped for joy to the that there was a CKeditor module.
@nymusicman: WYSIWYG it supports it in the current 2.x-dev release.
Aren Cambre I don't understand your point of view. You believe that another module which acts as an go-between between CKEditor, and Drupal users is more efficient than a module that just does CKEditor?
As has been mentioned, for most users, WYSIWYG is bloatware. I installed it on a couple of sites, saw what it did, removed it and just reinstalled FCKEditor and, now CKEditor modules. I understand that some users are going to want WYSIWYG for their specific purposes, but I have not found one implementation yet I will need it for. I'm sure it's a great module.
However, this CKEditor module is brilliant, and exactly what the community has been asking for. Props to the developers! I think at this stage, asking this module to be abandoned, is frankly unrealistic, and patronising to all the people who want a module to do exactly what it does.
There's not much point in keeping a discussion going here. The issue was marked won't fix long ago and new posts aren't doing anything but pinging a bunch of people who have moved on.
The bloatware accusations are ridiculous. If you look at the current 6.x dev branches, CKEditor is about 50% larger. The current recommended releases are only 7K apart. Also, CKEditor appears not appear to have an API that supports extensions being added via other modules--or if it does, the documentation is missing.
@Aren Cambre: Yes, I discovered that just recently, I apologize for my ignorance.
However IMCE integration was still much easier with the ckeditor module. So, after seriously giving the WYSIWYG module a try, it's still not ready, or I should say the imce WYSIWYG bridge really isn't ready. Of course I can't blame WYSIWYG for that but it still does keep me using the ckeditor module.
Today WYSIWYG supports CKEditor in a non-dev release with 6.x-2.1: http://drupal.org/node/736112
The bad thing, though, is its toolbar customization feature has an obnoxious usability degradation. See #735624: Enabling one button removes default editor toolbar. If you're OK with default toolbars, it's fine, but if you want to customize the toolbars, woe unto you!
Just keep in mind the average user / site owner only need one functioning editor, the word press has just one and it's fantastic. Those who insist on having multiple editors need to re-think it. It's fine for developers who like to tinker with new toys and do testing and debugging, but for the average user one is all they really will ever need. Think simple, the word press is simple. Most users like simple, get it ?
Closing this in hopes that that will end this already-decided-on debate.
If I can't customize the toolbar that is a DEALBREAKER.
I agree with others. I have used WYSIWYG + FckEditor in the past, but then switched to just plain FCK and it seemed faster to me. CK Editor is pretty fast on its own and is as customizable as I need it to be.
Does this mean that WYSIWYG should be discontinued?
#52: Nope. It means both can live in harmony.
It was meant to be a joke regarding this whole thread.
@Jay, haha, can't believe I missed that. My bad.
I was looking for a discussion along the lines of wysiwyg module vs. ckeditor module and this thread was quite useful in that regard. Interesting to see both sides.
At development conferences I frequently hear people pushing wysiwyg module for whatever reason. I've followed that advice until 3 months ago for a project which used ckeditor module. I was quite skeptical about it at first. But it's been mostly a very good experience - and after reading this I feel much more confident in using the ckeditor module on future development.
ckeditor is all I use now on all projects.
I have tried both Wysiwyg and CKEditor; the configurations that Wysiwyg provide are nowhere near what CKEditor provides. Granted Wysiwyg editor tries to do a lot, but that in fact is its undoing. Using Wysiwyg editor instead of CKEditor means losing so many great features. Sorry, but CKEditor definitely has my support.
Consider Ubuntu and WordPress. What do they have in common (especially compared to, say, Debian and Drupal)?
Answer: both decided to keep only one tool per function. Not because this tool is the best (although they try to of course), but in order not to confuse users.
Consider WordPress's built-in permalink management versus Drupal's (Pathauto + Token are necessary download). Which one provides the best experience from a newbie point-of-view (and not only a newby: when making a living out of installing blogs or CMSes, every options installed as default is a big plus)? Yes, this is WordPress.
Back to the topic: It should be made clear why there is both a WYSIWYG module and several dedicated modules. This should be short and simple explanation (KISS principle) and should be written on top of each of the involved modules. After reading this whole thread, I consider that, ultimately, this is a matter of "merging pending + some die-hard reflexes from some old-time users". I may be wrong, but I could not figure out more than this here. Which means that this is unclear.
And we all know what happens to unclear topics: people want to get rid of them and they have to ways to do so: either dismissing the issue (but for something as important as WYSIWYG, this is not an option) or solving it by randomly choosing a side, whithout any concern about choosing the best solution.
Conclusion #1: communicate!
Conclusion #2: Drupal developpers: choose a default WYSIWYG editor and put it in default install for Drupal 8. If not, Drupal will be considered as a "backyard CMS, without even a toolbar. WordPress is better". Would you like this kind of publicity?
Clan wars only benefit the competition.
Update: in WYSIWIG.module, CKEditor.module or BUEditor.module, I explain why WYSIWYG.module + CKEditor is my favorite (lowest footprint + best accessibility, respectively).
You can keep this open for ever, but this in fact is a non-issue (a simple plea judging from the title) and all it does is simply add to the bloat of the issue queue and make the maintainers' job harder. See #38.
btw, if you check the module's stats, you'll see that there are 40.000 sites using it. I mean, come one people... do you expect this to ever happen? Seriously now! -and just to make this clear this question comes from a person that doesn't actually use the module-
Drupal developers: choose a default WYSIWYG editor and put it in default install for Drupal 8...
I am 100% with you on this one, but from a person involved in drupal.org for almost 5 years now I'd expect better: file a new issue in the drupal core issue queue (where this request belongs), set it to D8 and link to it instead of posting your thoughts here - there simply is no point.
PS: this is not a code issue at all (more like a discussion), so adjusting as such. Also, it has nothing to do with any specific version of the module either, so there's no point in bumping versions.
It should be made clear why there is both a WYSIWYG module and several dedicated modules. This should be short and simple explanation (KISS principle) and should be written on top of each of the involved modules.
Fair enough. What if the explanation is 'this module provides feature x, y and z that WYSIWYG does not provide'?
I'd love to go to WYSIWYG. Each time I've evaluated it, I've found that it fails to meet my company's basic requirements for WYSIWYG integration. So we continue to use the CKEditor module. If we did not have the CKEditor module as an option, we would continue to use Drupal, but we would see ourselves as doing so at a cost in usability for our customers, in customer confidence (as we provided a sub-optimal solution), and in our time to document and support the deficiencies.
If CK abandons, I'm sure some users will petition to take it up. It does things we need it to do; that's why we keep using it.
Also, where do you come off switching status on this issue? This is not an "issue." It's a request. Changing back to the status the maintainer set it to. Also setting from 'critical' to 'normal', since this is clearly not a critical issue: This issue does not describe a defect which prevents people from being able to use CKEditor, ergo is cannot possibly be "critical."
Comparing the issue to wordpress is pointless - Drupal isn't wordpress. Apples and oranges. Wordpress is a great tool for what it does. Which is something different than Drupal does, and Drupal is great at what it does.
Newbies having problems: Newbies always have problems with Drupal. It's complexity is a result of its flexibility, and that flexibility is why people use it. Taking away from it's flexibility takes away from Drupal as a whole. And flexibility includes having more than one option.
Finally bad press: I don't think CMS are a popularity contest. People choose the right tool for their needs. People using Wordpress use wordpress because it fits their needs. People using Drupal use it because Drupal fits their needs. Does it really matter which one is more popular?
But there isn't any solid reason why Drupal 8 can't ship with a out of the box WYSIWYG like Wordpress has (and if you don't prefer it, you can use another via module).
Its like the biggest ??? for people when they install Drupal is that there is no text editor. Its the only CMS that doesn't come with one, that I know of.
#63 You'd better discuss about that elsewhere, as suggested by someone above.
...here you go: #1008522: Ship D8 with an out-of-the-box WYSIWYG editor
Seems like "won't fix" is the appropriate status here.
I would prefer to see CKEditor (and others) to continue to be developed separately from the WYSIWYG project. I did not appreciate being forced to drop a stable release in favor of a beta release when the WYSIWYG developer decided not enough people were testing the beta, and marked the stable as unsupported. I would rather choose an alternative to Drupal such as Wordpress or Joomla than be forced back to the WYSIWYG API.
This issue has no child issues.
Drupal is a registered trademark of Dries Buytaert.