Add CKEditor JS library to core

Whoo, I am here to help whatever is needed to make this happen :) - happy we finally settled on one.

is this the WYSIWYG module with the CKEditor lib enabled or the CKEditor module?

@sun or @TwoD might have a more precise response to that, but as far as I can see #1833716: WYSIWYG: Introduce "Text editors" as part of filter format configuration introduces an editor.module which is about half of what wysiwyg.module does: it allows to attach arbitrary text editors to text formats. The second half of WYSIWYG API, i.e. generalizing the editor/JS settings in order to be able to provide editor-agnostic plugins or buttons, will not be part of this effort.

So (assuming this all goes through and Drupal 8.0 ships with CKEditor) replacing CKEditor with e.g. TinyMCE will probably not be done by simply dropping TinyMCE in the right directory, but will require some, albeit minimal, code to manage the settings/buttons etc. It will still be lots easier than in Drupal 7.

So (assuming this all goes through and Drupal 8.0 ships with CKEditor) replacing CKEditor with e.g. TinyMCE will probably not be done by simply dropping TinyMCE in the right directory, but will require some, albeit minimal, code to manage the settings/buttons etc. It will still be lots easier than in Drupal 7.

I'm not sure what @sun's future plans are for WYSIWYG module, but there's no reason why WYSIWYG itself would not continue to exist in Drupal 8 and provide its generic plugin API, just like it does today. It would have to do less work than before since the binding of text formats and text editors is done for it, but the majority of its effort is in its generic plugin API.

Anyway, sorry let's focus on the task at hand. Like @webchick mentioned, right now we need to work on #1833716: WYSIWYG: Introduce "Text editors" as part of filter format configuration. Wim Leers and I are maintaining http://drupal.org/project/wysiwyg_ckeditor as a drop-into-core module in the 8.x-1.x branch.

No matter how long it takes, or how many deadlines have to be missed, or how many extra phases need to be added, WYSIWYG absolutely must be in Drupal core for Drupal 8. I fully agree with webchick when she says:

shipping a CMS in 2013 without a WYSIWYG editor out-of-the-box would pretty much be the death knell of Drupal

It is a strong sign of just how good Drupal has been in other areas that it is still alive as a CMS without ever shipping with one. I was amazed when I first started with Drupal (at Drupal 6) that WYSIWYG was not part of Drupal. I was even more amazed when Drupal 7 came out that it still did not have WYSIWYG by default. Now, at last, I hope that enough people see the wisdom of having one in core by default for Drupal 8.

Cross-post my comment from issue 1008522 comment #57 as I think it needs to be said

----------------------------------------------
I appreciate the work going on in this thread -- it is certainly an interesting read. just one quick point:

I think the big win with WordPress is not its inclusion of TinyMCE, but whatever was done to add the 'Upload/Insert' button above the (default wordpress) editor window. (see this demo page user/pw:admin/demo123)

It's the image and file management that has caused the most pain for the users of the sites I've created. (I've created many sites for community groups comprised of (generally not-super-computer-savvy) people who just want to write pages and not think too much about it. It's hard to convince them to let me use Drupal when many of them have seen how easy it is to add images in wordpress.
------------------------------------------

The various javascript editors out there all work reasonably well. But the true pain in Drupal currently is media and other file upload and management. I generally use the ckeditor module + IMCE and every time I launch an effort to build a new site the same flak always comes up -- "why is this so hard?", "Why can't it be like WP?", etc.

I'd say that including an editor is only half the battle -- (Image) file management is necessary as well.

Thanks

thanks again, tod

I'd say that including an editor is only half the battle -- (Image) file management is necessary as well.

Yep, I think everyone working on this is aware of this also. Fortunately we already have a new modal system in core (#1667742: Add abstracted dialog to core (resolves accessibility bug)) which sets us up nicely for modals for file management. The CKEditor project that we're targeting for core (http://drupal.org/project/wysiwyg_ckeditor if you're curious) also already has a specialized image button that is ready to swap out CKEditor's built-in modals for the those provided by core. Finally, Views being in core sets us up for a simple yet customizable file browser. The pieces are all in place, we just need to tie them together.

Can anyone clarify what this issue is actually about?

Dumping the CKEditor library into /misc/ckeditor?

That can happen anytime; i.e., now.

As usual, the library/external vendor code should be dumped into core upfront, separately from the integration code.

As usual, the library/external vendor code should be dumped into core upfront, separately from the integration code.

I didn't realize this was an official (or even unofficial) policy. With CKEditor, we will make a custom build of the library that only includes plugins we feel are necessary for Drupal core, and exclude the ones that seem unnecessary (i.e probably the Flash, Smileys, HTML Page, and others). I already created a custom build which can be reproduced by uploading the build-config.js file that is included when you download such a custom build from ckeditor.com. Here's the file I created already: http://drupalcode.org/project/wysiwyg_ckeditor.git/blob/refs/heads/8.x-1...

However afaik, the plugins we'll include are not finalized, since Wim and others would like to include the Widgets plugin (the Aloha blocks equivalent), which isn't finished yet, into the build.

So to answer your question, I had thought of this issue as adding the module and library to core. But if we want to specialize it into just adding the library, we could do that. The current build would be a good starting point, we could revise later.

Yes, we can always revise later. In the same way we're revising + updating all other vendor libraries. So let's add it. :)

Well here we are then. It's important to note that this version of CKEditor won't fully support Edit module yet, since some upstream changes are still necessary:

- http://dev.ckeditor.com/ticket/9794 (required)
- http://dev.ckeditor.com/ticket/9387 (nice to have)

But if needed we can easily include the "sharedspaces" plugin independently in the CKEditor module as a temporary measure, rather than bundling the plugin as part of the compiled/compressed version of the library.

Here's a patch adding CKEditor 4.0.1 to /core/misc/ckeditor. The build-config.js file can be uploaded to ckeditor.com to reproduce the build configuration. One additional change I made was to remove the "samples" directory also, which I don't think is an option for the builder.

I'd like to hear Wim's opinion on waiting vs. doing it right now. Committing this to core doesn't necessarily make the existing CKEditor module any easier to test, since you can already download and install it on a clean D8 install from http://drupal.org/project/wysiwyg_ckeditor.

For anyone curious, it's 1.85MB because it includes a number of translation files (750KB). The main JS file itself is still 415KB, which we can make smaller if we decide to exclude more plugins (i.e. table or specialchars), but I think this base install is a pretty good balance between cutting out useful features and saving file size.

I don't think this needs further coordination.

Can you add a /misc/.gitignore file (in /misc, not /misc/ckeditor) to ensure that the samples directory is excluded in the future?

With that, we should be ready to go here.

Can you add a /misc/.gitignore file (in /misc, not /misc/ckeditor) to ensure that the samples directory is excluded in the future?

Good idea on the .gitignore file in misc. I imagine adding the samples directory would be an easy mistake. New big patch, coming right up.

Thanks! :)

Wow, another issue that changed overnight! Must've been one of the most productive 12 hours of not working on Drupal core and seeing things happen automagically anyway :)

I agree: commit 4.0.1 now; we can still update it later.

As for Edit module compatibility: we can temporarily add the "sharedspaces" plugin (http://dev.ckeditor.com/ticket/9794) that is essential to have CKEditor work with Edit module to the wysiwyg_ckeditor module (and consequently, to the CKEditor module core patch). So I don't think that would truly pose a big issue to the development, patch (re)rolling or testing process.

I agree: commit 4.0.1 now; we can still update it later.

Super, well that is what is here already.

In case people come into this issue later and wonder, "Why CKEditor?", please see #1260052: Candidate WYSIWYG editors.

This is adding a bunch of major UI's to core, can we make sure they are added before commit - and make a list of items we need to adress. I've seen too many issues go into core, with usability/ascetic issues that never get an issue made.

@Bojhan: this is the CKEditor JS, you can't use it yet. I.e. zero UI changes. Resetting status because I'm assuming it was due to a misinterpretation.

doh, sorry!

Upon a closer look, this patch is not yet registering CKEditor as a library. We need something like this in system_library_info():

  // CKEditor.
  $libraries['ckeditor'] = array(
    'title' => 'CKEditor',
    'website' => 'http://ckeditor.com/',
    'version' => '4.0.1',
    'js' => array(
      'core/misc/ckeditor/ckeditor.js' => array('group' => JS_LIBRARY),
    ),
  );

I had assumed that the yet-to-be-added ckeditor.module would own the library for CKEditor, rather than system.module. Is it beneficial/logical to use system.module instead? I suppose that means you could add the ckeditor library to the page even with ckeditor.module disabled, but I don't think adding the library alone (without any kind of Drupal integration) would be a useful ability.

AFAIK, anything in core/misc is owned by system.module. If it were to be owned by CKEditor.module, then it should live somewhere in core/modules/ckeditor.

The reason it must be registered by system.module is that other modules might want to use it too, but then they'd have to depend on CKEditor.module. CKEditor.module should only register the libraries that provide glue.

See e.g. #1849526: Add VIE and Create.js libraries to core (upstream fixes) for another example.

I talked to webchick and nod_ about this. They both are fine with deviating from the "core/misc -> system.module" rule, because it will soon become a library anyway and because there are indeed very few use cases for other modules to use CKEditor's JS, except for most likely the http://drupal.org/project/wysiwyg module.

I'm creating an issue for the CKEditor module right now, and it is in that module then that we will register this as a library.

If anybody feels strongly about this, we can still do a follow-up issue on "Where should CKEditor library live once CKEditor module is in core?".

Apologies for the distraction.

Here's the new issue for the CKEditor module: #1890502: WYSIWYG: Add CKEditor module to core. Updated the issue summary to link to it.

Yes, the hook_library_info() definition should be part of the integration code. Let's just add the library files here.

With regard to the question of system.module vs. ckeditor.module, we'll have to take a deeper look into the new architecture, in order to figure out how Wysiwyg module for D8 will actually look like. Off-hand, I can't tell how much of the ckeditor.module code will be re-usable for wysiwyg.module, or whether there won't actually be anything to re-use, and instead, only conflicting code.

Tagging; this helps the CKEditor folks track the "CKEditor in core" status on the Drupal side. On the CKEditor side, see http://dev.ckeditor.com/query?keywords=~Drupal.

Committed to 8.x.

YAY!

:)

Doesn't need to be assigned to Dries anymore as far as I can tell.