Replace Aloha with CKEditor via CKEditor project

You know there are a few good choices out there to choose from, but I never really understood the choice to use Aloha in the first place. Let's not even begin to discuss the maturity of the Aloha project over the maturity of the CKEditor project. I was also planning on replacing the editor, not that it wasn't nice, but because I don't seem to have as many options as I do with CkEditor. I thought Aloha was a little too specific and that a more common component to use with Commons would be more fitting.

Yes - Commons will align with Spark's choice of architecture for WYSWYG so that Commons can benefit from the extensive investment being made in the editing experience as part of the Spark project.

Currently it seems that Spark's D7 plan is to use the recently created WYSIWYG CKEditor project.

Existing alternatives to that project include:

http://drupal.org/project/ckeditor
http://drupal.org/project/wysiwyg

Some benefits over those projects include:

Bundled lightweight CKEditor 4.x version, optimized for Drupal integration (no unneeded plugins makes for faster loading). No need to download the editor separately.
- Additional add-on plugins that tightly integrate Drupal with CKEditor
- Drupal Image plugin
- Drupal Image captioning plugin
- Webkit Resize plugin (adds support for resize handles in Chrome/Safari)
- Dependency on WYSIWYG module keeps compatibility with other WYSIWYG editors
-Uses absolutely no inline styles. All buttons and cleanup uses a consistent set of classes which can be themed.

My understanding is that this new project aims to avoid functional limitations that sometimes come through extensive abstraction (eg through WYSIWYG API's default CKEditor behavior).

Since we haven't done the work necessary to make this change, I believe the proper status here is "active". This also lets other folks weigh in on the proposed approach.

Note that we had a call about "How best to integrate CKEditor v4 into Edit module" this morning as part of the sponsorship for #1879820: [meta] Get the D7 version of Edit production-ready, and landed on the "official" CKeditor project. See #1879832-1: Edit module integration with CKEditor for reasoning.

Not necessarily married to this, but my concerns about going with wysiwyg_ckeditor are:

1) It's a very new project, and (much along the lines of Spark) targets D8 first and foremost, with D7 a secondary consideration.
2) It says right at the top of the project page that it's currently incompatible with several contributed projects, which means there's still development work to be done on it.
3) Building WYSIWYG API support in implies (at least as far as Edit module goes) that we support editors other than Aloha and CKEditor and that's not (currently) the case.

I've cross-linked this issue from that one and will see if I can get nod_ and quicksketch to chime in.

Updating the proposal based on #7.

Hi, Spark? Yes, a spark of genius! I will try to keep this short as to why I'm a yes vote for CKEditor for WYSIWYG Module. I'm kind of new to this V2 GPL license and the competing business models that stems from it. I'm pretty sure you all have at one point or another needed, or wanted to integrate with something else. I mean really, I think it's long been about the API. I will go over Webchicks points.

1. I'm not so sure being new means anything here. The maintainer has a history with many projects, and also has what looks like a future with a D8 version. I can pretty much bet you that D7 will not be left in the dark, especially if others get on board to help out
2. With this type of situation you are going to end up with some sort of fragmentation, but imho this really speaks of larger issues and CKEditor for WYSIWYG Module seeks to address some of those issues. See my point #1
3. I do believe there should be a way to gracefully fallback to using another editor. See points 1 & 2

It's safe to say that speed kills the competition, but how will Drupal fare in 2014 with always having to clunk something together to achieve it's goals? We are talking about a project that is optimized for Drupal, but you are saying that there is no reason to get on board a project that screams tighter integration with core? You can't look at the new project now, but look at what it would look like if it were the standard.

There are many POV's trying to shape Drupal, Drupal should shape itself, which it seems to have done for the most part. To ignore those needs of Drupal over the needs of a POV is a very risky gamble. Who out there is willing to bet against Drupal?

I know that my writing style might be a bit elementary, but this topic certainly is not. I'm not trying to offend anyone, but I'm hopefully trying to help you see that perhaps even your own interest might not be the answer for Drupal. It is easy to embark on that path to start your journey. You should also never forget where you came from, because it is just as easy to lose your way as it is to embark.

I cannot stress that enough as we all journey on to a hopefully brighter future. I also cannot thank you all enough for your contributions, because I believe you are Drupal. Just like Drupal the product, the Drupal community is made up of different interest that managed to come together with something good.

Looks live I've almost built up enough fodder to formulate my predictions for Drupal. Thanks.

My concern with #7.1 is that we have limited amount of time to focus on D7 right now, and we can spend that time in one of two ways:

a) We can try and get WYSIWYG_CKEditor up to snuff (as the project page mentions, it currently doesn't support several contrib modules, so is lacking in some functionality), and also become a co-maintainer of the project and do ongoing maintenance (I talked to Nate and his interest is in mainly the D8 stuff and getting that into core; the D7 code was provided so non-core developers could try it out), which reduces the amount of cool things we can do going forward by diverting resources there.

b) We can work really hard on getting a nicely integrated out-of-the-box WYSIWYG experience in both Commons and Spark.

I would vastly prefer to focus on b). People who still want to use WYSIWYG module + TinyMCE or Aloha module or whatever certainly can. It's just a matter of turning off the default CKEditor module and turning on one of those other methods.

Thanks webchick that's very good information you shared. B sounds like a plan to me. I am just a simple man and at times I can't figure out why solution B cannot be applied to solution A. Math is not my forte so I'll just have to bow out of this one.

I've started this work in ckeditor branches of Commons and Commons WYSIWYG.

My next step is to re-roll #1063482: Use Libraries API for CKEditor.

This is committed! Below is a screenshot of the button config I exported along with a revised list of accepted tags.

Folks updating from Beta1 will need to disable the Aloha module and may need to disable and re-enable the Libraries module for the change to take effect.

Also, marking #1868190: Timeago integration breaks when Libraries module is enabled as fixed by the introduction of Libraries module and storing the TimeAgo's library inside the Libraries directory.

http://drupalcode.org/project/commons_wysiwyg.git/commit/db01ecf
http://drupalcode.org/project/commons.git/commit/bbe6278

Are those black lines above the button icons artefacts of the screenshot or is that how it actually works for you? I suspect your theme is interfering with CKEditor, because all buttons look … weird in comparison with "stock" CKEditor — see http://ckeditor.com/demo

Might be worth to check if it is simply caused by the black squares in icons.png (which should be fixed in 4.0.1, at least in packages generated with online builder).

#16: that's a very good point — thanks for chiming in here :)

The thing is that I did not see this problem elsewhere in Drupal 8 or Spark D8, so I'm not sure why it could be happening here.

I created a followup to investigate these artifacts - Thanks for pointing them out!

#1896754: Theme causes CKEditor line artifacts.