Support CKEditor in Panopoly

Following/adding tags from the closed issue.

@populist - While working on Demo Framework, I've had to do quite a bit of work to get Panopoly working with the Edit module, partially due to WYSIWYG issues. Edit does not use the WYSIWYG API, but instead uses the standard CKEditor module.

I believe the goal for Edit is to support all use cases for rendering - via core, views or panels. Inline editing would be good to have in Panopoly too... Would it be worth looking into to shedding WYSIWYG API and switching to CKEditor module?

Also: I think its also worth cross-referencing #1795978: Panopoly Magic's Live Preview has infinite reload loop due to textarea :input.filter-list refreshing the form and whether or not introducing a new editor would affect that problem.

Hey @populist now that wysiwyg module supports CKEditor 4 do you think it would be a lot of work to extend the edit module to support wysiwyg?

One of the reasons I am not currently going with CKEditor + Edit is the fact it does not leverage the wysiwyg module. :S

I have been running CKEditor module and WYSIWYG module in tandem and this is working as long as you limit the WYSIWYG profiles to specific entity bundles' fields using better_formats.

+ Subscribing.

Not having Ckeditor and thus not being able to use Edit module and direct editing was the only reason I didnt go with Panopoly for a huge project.
Apart from that Panopoly is awesome!!!
Cheers, Moritz

I also tend to think that Panopoly should dump TinyMCE and WYSIWYG API and do a full switch to the Edit/CKEditor combo in a few months.

CKEditor gained a lot of traction after the final D8 core decision, with their latest release being awesome and their team doing everything to cater Drupal's needs.
While I'm extremely sorry for the Aloha people, both TinyMCE and WYSIWYG will further lose traction.

Edit module is very promising regarding in-place editing etc. and is announced to become pluggable, too. We need to figure out though, how stable it currently is. Might be an experimental feature in Panopoly 7.x-1.0 but probably no default option yet.

Current options (for Panopoly 7.x-1.0) would therefore probably be:

1. Dump TinyMCE and WYSIWYG API and switch to stand-alone CKEditor, or:
2. Stay with WYSIWYG API but make CKEditor default

WYSIWYG module will reach its EOL with D8, as soon as D8's Edit is pluggable. And CKEditor will in the next months be more and more tailored to Drupal's needs. So atm there I don't see much sense in putting more work into the dead-end route. So I strongly tend to 1 as a first step towards integration of Edit module.

How do others think about this?

With CKEditor for WYSIWYG, there is another contender that seems to be closest to the D8 solution. However it is alpha, doesn't yet provide all inegrations we need, and didn't see many commits in the last months. So the future path for D7 WYSIWYG remains more unclear than I thought.
This means that we'd be crazy to dump our current implementation for something else.

So we're back at the OP: support CKEditor via WYSIWYG plus make it our default WYSIWYG editor, with the perspective of possibly switching later to whatever solution gains traction.
Sorry for the noise.

In my tests I've found that CKEditor via WYSIWYG does not work with the Edit module. I've only been able to use Edit module using the CKEditor module, as recommended by the Edit team.

As far as including WYSIWYG or leaving around TinyMCE, see #6

I was going to post an issue about integrating Edit module and inline editing but I see it's already being discussed here.
This is #1 on my list of features I would like Panopoly to take from Spark.
Since we currently rely on the WYSIWYG module, maybe we can start evaluating if we can patch the WYSIWYG module to support the Edit module?

+1 for inline editing with Edit in Panopoly

Note: I don't believe the Ckeditor module is supported with the Media module. I only think the wysiywg module is supported with media.

Just something to keep in mind.

#1022986: Integration with Media Module seems to be done but still having some issues #1445272: Media tags aren't converted upon second edit

This is a relevant issue: #1504696: Integration with CKEditor module

Couple of issues to follow:
#2148641: WYSIWYG-inserted images lose ckeditor styles which might solve #2028255: ckeditor styles break media module markup

I'm not sure if #2116639: Multiple items inside Media tagmap variables makes it broken. is still an issue.

@dsnopek It might be worth getting Panopoly on CKEditor (which would also make the transition to Drupal 8 easier in the end)?

@lsolesen: I agree! However, I don't personally have the time to take this on right now.

To use CKEditor this issue is relevant for the caption support #696734: Integration with CKEditor or WYSIWYG?

Right now TinyMCE is handling the 'wysiwyg' part and markitup is handling the 'html' option. If we switch to CKEditor/Edit do we lose the 'html' wysiwyg?

you could create a text format to use with the ckeditor/edit combination.

The only thing is that many of the other panopoly features have panopoly_wysiwyg format defined

The 'Edit' module requires the 'CKEditor' module. So that would mean we can't use the WYSIWYG module and we're stuck with just one wysiwyg library (ckeditor).

I think that would lead us to not have a wysiwyg experience to add html like we currently get with markitup.

How important is adding HTML via WYSIWYG to end users?

Inline editing via ckeditor/edit is such an amazing feature, combined with the IPE it would make for a truly awesome front end authoring experience.

How important is adding HTML via WYSIWYG to end users?

Honestly, I wish there was a good way to answer that question. As a base distribution, we'd have to somehow survey users of all the child distributions or something like that?

At this point, having been released and used by people, we have to be very careful when removing features. For the most part we try to maintain features that have already been out there for a while. :-)

Anyway, I'd still like to look into how hard it would be to get the Edit module working with CKEditor added by the WYSIWYG module. I think that is the most likely way we'll get Edit and CKEditor added without removing any features. If anyone wants to do the the research and coding on that - that'd be awesome! Otherwise, I'll get to it eventually...

Edit works with the ckeditor module not the wysiwyg module.

I would suggest refactoring to include a panopoly_wysiwyg and a panopoly_ckeditor.

The latest version of Edit module for Drupal 7 does not work with Panelizer. Until that feature is added, its not something that would be very helpful to people using Panopoly. See: #2169873: Compatibility with Panels / Panelizer

This might be a good opportunity for someone to step in and patch Edit to make this work. I know the maintainers of Edit are very busy with Drupal 8 and will need help getting this in for D7.

@SocialNicheGuru wrote:

Edit works with the ckeditor module not the wysiwyg module.

That is true currently, however, what I am suggesting is that someone look into how hard it would be to get Edit working with CKEditor via the WYSIWYG module. If it's possible and not prohibitively difficult, this would allow us to do everything. :-)

Anyway, like I said, this is on my TODO list (so I'll do it eventually), but pretty low priority-wise.

Could we perhaps split this into two separate tasks - #1: add ckedior, #2: add inline editing?

@DamienMcKenna: That's probably a good idea. :-) We could certainly get CKEditor support much easier than Edit support, because we know we'd be keeping the WYSIWYG module for just that. Then it's a matter of solving all the CKEditor and Media issues, or anything else that comes up we don't know about.

I agree with sentiments in #28, but it sounds like, for Panopoly, this might required 3 tasks.

1. Getting CKEditor into the distribution using WYSIWYG.
2. Adding inline editing to Panopoly and make Edit work with Panelizer.
3. Add WYSIWYG module support for Edit.

Regarding #29 - much of that has been worked on already. There are patches for CKEditor and WYSIWYG depending on how you want to go.

Ok, lets focus this on ckeditor and spin off the inline editing into #2209521: Add inline editing using the Edit module.

@DamienMcKenna: Thanks! :-)

thanks

Here is an initial patch to get the ball rolling. In this I:

• Update WYSIWYG to the latest dev revision
• Updated existing patches to apply cleanly (they were mostly related to TinyMCE)
• Add the patch from #1757684: Ajax error on Add another item
• Add the patch from #1338956: [upstream] HTML5 "required" attribute prevents forms from submitting
• Add the latest CKEditor for Drupal library (4.3.2)
• Updated the WYSIWYG profile to use CKEditor (I kept the settings as close as I could to the old TinyMCE settings)

Notes:

• I have left the TinyMCE library in place
• I have left the supporting code for TinyMCE in place in panopoly_wysiwyg_wysiwyg_editor_settings_alter()
• I have kept markitup for HTML markup editing
• I could not find a fullscreen option (there was one for TinyMCE)
• Caption filter doesn't work currently
• There is no 'kitchen sink' plugin (there was one enabled for TinyMCE, though I don't see why we need a kitchen sink feature)
• I'm not 100% that 'CKEditor for Drupal' is the correct version of the library to use. I read in #1414706-1: Wysiwyg / CK-Editor ? I'm confused!!! that CKEditor for Drupal is not supported and that the standard library should be used. But that was posted back in Jan 2012 and I know a lot of work has gone into the CKEditor support since then
• I have not tested very much at all! - do not use even consider using this on a production site

First impressions:

• It looks and feels great :)
• Inserting media seems to work
• Linkit does work, although the spinner for autocomplete doesn't - which made me think it wasn't working initially (but it does)

I really like this but I suppose that there may be others that would like to use TinyMCE so maybe you can manage to have them both installed (or at least fetched) and that user can choose which one they prefer at some point.

It could be somewhere in Apps configuration (if that is possible beyond enable/disable the whole app) or it could be done by enabling/disabling WYSIWYG profiles.

Or it could be done by different module (wysiwyg_ckeditor and wysiwyg_tinymce).

Or you could switch to CKEditor completely? I currently prefer CKeditor but for no apparent reason except I've done it before and I didn't use TinyMCE. Also, CKeditor holds some future and most probably a lot of work will go toward better integration and experience and that could mean a lot.

The thing that bugs me most with Drupal is overall media handling and hassle with inserting media, adding alt and title, choosing image style and bugging user to learn all that stuff.

That is where CKEditor still didn't make much of a difference (from Drupal 6 days and FCKE), that image dialog simply sucks and there should be some better UX around that.

I have a relatively relevant question: as I'd like to include this patch into my build make how can I include patch and have it patched in profile/panopoly/... instead in sites/all/modules?

Here is my make file:

api = 2
core = 7.x

; Drupal Core  -- so I do not have to include it
projects[drupal][type] = core
projects[drupal][version] = 7.26

; Panopoly -- the main stuff
projects[panopoly][type] = profile
projects[panopoly][version] = 1.2

; Panopoly WYSIWYG patch for CKEditor -- but it ends up in sites/all/modules instead in profile?
projects[panopoly_wysiwyg][subdir] = panopoly
projects[panopoly_wysiwyg][patch][1965864] = https://drupal.org/files/issues/1965864-panopoly_wysiwyg-ckeditor.patch

; My favourites

; Modules
; ------
projects[] = module_filter

; Themes
; ------
projects[] = omega
projects[] = radix
; Admin
projects[] = ember
projects[] = shiny

#34 is definitely the right way to go. plans for further testing.

I may be wrong but I'm pretty sure the correct version to use is, strangely enough, *not* the CKEditor for Drupal, but just the full download of the normal version. If it works it works though... :)

@MacMladen I think that supporting TinyMCE might be something we would want to do, at least for a period after switching the default to CKEditor. Adding a setting on the Panopoly WYSIWYG settings page at /admin/panopoly/settings/panopoly_wysiwyg would probably be the nicest way to make switching out the editor easy for people.

I still haven't tested this patch, but just a couple random thoughts in response to the comments here:

From #34:

There is no 'kitchen sink' plugin (there was one enabled for TinyMCE, though I don't see why we need a kitchen sink feature)

I personally consider the 'kitchen sink' plugin important for usability: having too many WYSIWYG buttons visible by default is really confusing to some users. When I present about Panopoly, you'd be surprised how popular such a simple feature is. :-) So, I think we need a similar feature in CKEditor.

From #39:

@MacMladen I think that supporting TinyMCE might be something we would want to do, at least for a period after switching the default to CKEditor. Adding a setting on the Panopoly WYSIWYG settings page at /admin/panopoly/settings/panopoly_wysiwyg would probably be the nicest way to make switching out the editor easy for people.

If we add CKEditor, I think we should continue to support TinyMCE for the rest of the Panopoly 1.x cycle. This is because users may have customized TinyMCE with additional plugins (which maybe specific to TinyMCE) and I don't really want to have to force them to find equivalents or (if none exist) port them themselves. So, when we switch, it should setup new sites to use CKEditor, but leave existing sites unaffected.

dsnopek is right, there are too many sites built upon assumption that TinyMCE is default editor and probably some builders added upon that or developed some procedures based on that assumption.

Going from one default editor to another would probably make a mess for some builders out there so I think (although I said just the opposite) that TinyMCE should be included and default and CKEditor should be also included but as an option so that those who prefer it may have easy path.

CKEditor as default may start in version 2.x so nothing will be broken. There is big difference in Migrate 2.5 and 2.6 and that really complicates things as just simple module downloading may give you incompatible version and broke things (perhaps even kill some kittens and who wants that?!).

Just another vote in favor of dsnopek's observations and MacMladen's followup.

Various incompatibilities already make Panopoly updates complicated enough. If CKEditor becomes the default upon first installing Panopoly, at the very least it's essential that any upgrades leave TinyMCE as the editor. But that leaves the maintainers supporting two default editors, which seems like a lot of extra work for the benefit.

To chime in with the past three comments, I agree that if CKEditor bundled, let it be a secondary choice and not the default. I also think that upgrading TinyMCE to version 4 should be postponed indefinitely, with the roadmap being full implementation of CKEditor. TinyMCE 4 will require a bit of work in Panopoly WYSIWYG (ensure checking version before customizing [or else major errors], then customizing 4.)

Completely agree that CKEditor should be preferred going forward. It is clearly the Drupal standard. Would be ideal if workflow would allow multiple CKEditor profiles using custom plugins. This is an area that content editors pay a lot of attention to and CKEDitor has a great set of tools for customizing based on level of HTML competency.

Can someone give me a pointer on how to update my dist with this patch. It does not seem to work, even when I add it manually :(

@sonicthoughts' question in #45 about applying the patch was answered here: #2330915: Best Practice to apply patch to Panopoly Dist. Just an FYI, so no one worries about needing to respond here. :-)

I've disabled all Panopoly's WYSIWYG modules and enabled the stand-alone CKEditor module, but I don't see CKEditor when editing pages. Should this be working?

In other words - exactly what parts of Panopoly do I have to disable in order to use the CKEditor standalone module?

Update: I figured this out -- The CKEditor module required just a little more configuration than I expected. I had to enable CKEditor to be used for WYSIWYG in admin/config/content/ckeditor/edit/Advanced > Basic Setup.

Maybe I'm missing something, but it seemed much simpler than applying a patch to Panopoly.

Same thing here, I am very happy to have CKE in Panopoly base distribution some day, but it currently sets up manually in minutes:-)

I'm going to go out on limb here, and postpone this until Panopoly 2.x. It's possible to use CKEditor with Panopoly if you want. However, anything we do in Panopoly 1.x is going to need to be backward compatible, which means maintaining both TinyMCE and CKEditor configurations for WYSIWYG, and I think that's more maintenance burden than we're willing to take on at the moment.

If anyone disagrees, feel free to post your comments here and discuss! We can always re-open this later if we want.

I totally understand maintenance issues with full ckeditor support. Just FYI that client decided to pass on panopoly due to lack of ckeditor (among other things) due to training, consistency, and a bunch of other things. I'm mentioning only to emphasize how important wysiwyg to folks. I know that it can work with ckeditor but seemed like religion...Fyi as sometimes this feedback is important in priorities :)

@sonicthoughts: Thanks for the feedback! Panopoly 2.x is definitely going to use CKEditor (and Panopoly 2.x is my personal priority ;-)). But we're not going to be making any feature changes in Panopoly 1.x at this point per #2530998: [meta] Get Panopoly 1.x into maintenance mode (so we can focus on Drupal 8). If the community came up with a panopoly_wysiwyg_ckeditor or similar module in contrib, we could put it on the Panopoly app server?

I am using CKeditor following the approach of #47 and #48 and it has been working fine for over a year. But the latest Panoply updates Media to 2.0beta 1 which breaks CKeditor. I realize Panoply does not support CKeditor. Silly me for going off the reservation. But maybe you can help with this question?

If I could patch Media to the latest dev version (plus the Panoply patches to media), and then use the dev version of CKeditor and add a new module called MediaCKeditor, apparently all would work again. But this sounds like a risky plan as I don't want to have to keep patching future Panoply updates.

I might just rip CKeditor out and revert to TinyMCE but would prefer not to.

Any suggestions? Thank you very much for any tips.

@entrepreneur27: Hrm. That sucks! We'd definitely want to support people choosing not to use panopoly_wysiwyg and use CKEditor instead. :-(

Can you open a new issue against panopoly_widgets (where media comes from) about updating media or adding the necessary patches to make CKEditor work again? Thanks!

Done. Thx. See here. (https://www.drupal.org/node/2633496)

I also would like to change to CKEditor, but thinking in compatibility problems with other modules that Panopoly has, makes me wait. Maybe while D8 gets best practices solved (as dsnopek says in https://www.drupal.org/project/panopoly/issues/2549709#comment-12333649) this could be worked to easy the upgrade way from D7 to D8...

Thanks, as always, for your generous work :)

Has there been any movement on this issue?

Thanks