Release announcement: http://ckeditor.com/blog/CKEditor-4.1-RC-Released

Added to core at #1878344: Add CKEditor JS library to core and updated at #1905424: Update CKEditor library, we should now update it again. The 4.1 RC release marks the stability of the Advanced Content Filter functionality that CKEditor implemented upon our request. That's also the flagship feature of this release.

So, why update? For several reasons:

  1. http://dev.ckeditor.com/ticket/9994 is part of 4.1 RC, which allows us to implement #1894644: Unidirectional editor configuration -> filter settings syncing, which is a major task, and (probably) the last CKEditor integration aspect for which there is not yet a patch.
  2. Currently, CKEditor always loads its styles.js file. However, we don't need/use it. This has been fixed in 4.1 RC: http://dev.ckeditor.com/ticket/9992#comment:4. It allows us to remove that file from our repository, and removes 1 unnecessary HTTP request. WPO FTW.
  3. Source mode editing when using in-place WYSIWYG editing, thanks to 4.1 RC's new "source dialog" plugin. (That opens up a dialog to edit HTML source code.) See #1886566-34: Make WYSIWYG editors available for in-place editing.
  4. Users can test Advanced Content Filter, potentially leading to bug reports for CKEditor. We already have it, but then we'll have a more mature version of it.

Relevant detail: to be able to not load styles.js when not using the "Styles" button/dropdown, we must set stylesSet = FALSE, I had to make the StylesCombo plugin implement CKEditorPluginContextualInterface: when the button is not enabled, it will set stylesSet = FALSE. See interdiff_php.txt for that.

With this new build, I optimized & clarified the build-config.js file again (which determines which plugins are included in the build). See interdiff_build-config.js.txt for that.

This means the CKEditor Widgets are temporarily unavailable (they're not part of the 4.1rc tag or the major branch, and the d8 branch doesn't contain the ACF improvements), but that's okay, we were not yet using that yet anyway, and they will be available again soon, when we update the build again. This update addresses all pressing concerns regarding CKEditor integration work.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Wim Leers’s picture

Status: Active » Needs review
FileSize
2.32 KB
8.04 KB
3 MB

Status: Needs review » Needs work

The last submitted patch, ckeditor_library_update_4.1rc-1937484-1.patch, failed testing.

Wim Leers’s picture

Status: Needs work » Needs review
FileSize
2.98 MB

I was running a slightly outdated & patched version. Both led to patch failure. Apologies.

Identical reroll, but against current HEAD now.

Wim Leers’s picture

I asked quicksketch to review this, and his feedback boiled down to this: the trickiness introduced in StylesCombo is not nice, let's have that in CKEditor::getJSSettings(), where the "essential defaults" are defined anyway. This is fine by me, and leads to StylesCombo to not be weird, so yay :)

Upon further research, quicksketch noticed this:

It looks like stylesSet variable is in core/style.js. it just so happens that stylescombo/plugin.js uses that variable (along with dialogs/div.js and stylesheetparser/plugin.js). So stylesSet really is a global variable, rather than one particular to stylescombo.


Also fixed a small bug in the tests, which allowed me to simplify the StylesCombo plugin! :)


In #3, there were still unrelated changes. I've attached a new interdiff_php.txt, that shows all PHP changes against HEAD (NOT against #3!). That makes it clear how little has to change thanks to quicksketch' suggestions! :)

webchick’s picture

Status: Needs review » Reviewed & tested by the community

If this is passing testbot, I don't see a particular reason not to commit this since it's simply updating a library. Marking RTBC and I'll commit it later on tonight if no objections.

Wim Leers’s picture

#5: it's slightly more than that. But, the "slightly more" part was already reviewed by quicksketch, and I rerolled it to implement all his feedback. So, I guess RTBC is fair now :)

quicksketch’s picture

Title: Update CKEditor library to 4.1 RC » Update CKEditor library to 4.1 RC and remove CKEditor default style configuration

Yeah, I think we should avoid innocuous titles like "update a library" and at the same time sliding in adjustments to our integration code. These particular changes aren't necessary to update the library, but they're related: The new build specifically excludes CKEditor's default style.js file:

deleted file mode 100644
index 9cd1c13..0000000
--- a/core/misc/ckeditor/styles.js
+++ /dev/null

By removing this file, we're no longer letting CKEditor provide any default styles. This means that we need to make the default Drupal configuration of CKEditor match it, so this patch also adjusts the "stylecombo" integration plugin and the default configuration sent by Drupal.

Really the update of the library to a new version and the removal of the style.js file probably should have been two issues as each is a different problem, but Wim took the opportunity of the library update to remove the default style configuration at the same time. I updated the title to reflect this.

--- a/core/modules/ckeditor/lib/Drupal/ckeditor/Plugin/editor/editor/CKEditor.php
+++ b/core/modules/ckeditor/lib/Drupal/ckeditor/Plugin/editor/editor/CKEditor.php
@@ -125,6 +125,12 @@ public function getJSSettings(Editor $editor) {
       'contentsCss' => $this->buildContentsCssJSSetting($editor),
       'extraPlugins' => implode(',', array_keys($external_plugins)),
       'language' => $language_interface->langcode,
+      // Configure CKEditor to not load styles.js. The StylesCombo plugin will
+      // set stylesSet according to the user's settings, if the "Styles" button
+      // is enabled. We cannot get rid of this until CKEditor will stop loading
+      // styles.js by default.
+      // See http://dev.ckeditor.com/ticket/9992#comment:9.
+      'stylesSet' => FALSE,
     );

I suggested this comment be made, but this is probably a bit overly verbose. It's not worth holding up the issue though. This gets +1 RTBC from me.

webchick’s picture

Status: Reviewed & tested by the community » Fixed
Issue tags: -sprint +SprintWeekend2013

Oh oops, sorry for not digging in more. Thanks for the heads-up, and the +1. :)

Committed and pushed to 8.x. Thanks! It's great to get this updated for the forthcoming Drupal Global Sprint Weekend so we can do some testing.

I don't think we need a change notice particularly for this (moreso when we move to a stable version), so marking directly to fixed, and removing the "sprint" tag.

Wim Leers’s picture

#7: You're right, I should've mentioned that explicitly. But, really, this is just fixing something that we'd already noted before. A comment indicated in the build-config.js file before that this would be fixed upstream, so we're just implementing that bugfix here. After checking this with you, the way that bugfix got implemented got really simple, so then it really became a no-brainer, IMHO :) Thanks again!

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

Anonymous’s picture

Raven_MacLean’s picture

where are we supposed to place this patch exactly?