Moving CKEditor Integration to XWiki Platform

Development
#1

Hello all,

I’d like to propose the integration of the CKEditor Integration to XWiki Platform.

CKEditor Integration is a major feature of XWiki Standard and follows the same development cycles (for instance, we often need to release a new version of CKeditor to be able to ship it’s improvement in the next releas of XWiki Platform).
In addition, CKEditor Integration is so important that it’s improvement are documented in XWiki Standard release not even though it’s not officially part of it.

Since both as so tightly coupled, I think it’s interesting to integrate CKEditor inside XWiki Standard.

WDYT?

Additional question:

  • Currently, CKEditor Integration support XS 8.4+, which can make it more difficult to integrate new features. In particular, when one functionality needs to rely on an API, some feature detection mechanism needs to be done, which is sometimes complex and time consuming. Hence, it could be interesting to upgrade the minimal supported version to a more recent version, for instance the LTS version.

Related discussion:

#2

+1 to put CKEditor integration in xwiki-platform, it’s bringing way too much complexity as a separated project

For me, putting the ckeditor integration in platform means that it does not have to care about supporting any other version than itself. Like any other xwiki-platform module, xwiki-platform-wysiwyg-ckeditor (or something like this) 14.5 should work in XWiki Standard 14.5 and that’s it.

XWiki 13.10.x will keep relying on the contrib project which will get bugfixes if needed until 14.10.x become the new LTS.

#3

Thanks for bringing this up. I’m globally +1 with the proposal, I almost think we should have done it earlier.

My only worry is a wider discussion about the future of CKEditor in XWiki, AFAIR it has been discussed in the past because of the difficulty we have to upgrade to next major version, because of realtime edition.
So I hope we’re not too late in integrating back CKEditor now in platform, and that we won’t drop it in few years, but I don’t think so given the amount of time we already invested in it.

#4

Please do not forget the possibility to add CKEditor plugins when integrate the CKEditor to XWiki Platform.
Some existing CKEditor plugins are very useful - e.g search & replace - and even the simple integration of additional buttons for abbreviation purpose is useful.

#5

Question: does the CKEditor integration contain some public java interface (for plugins for ex) that would be hard to migrate (since the org.xwiki.contrib.xxx package will need to be moved to org.xwiki.xxx?

+1 from me (always been a strong proponent to have all XS be in platform and not depend on any contrib code - it doesn’t seem right to have that from various points - contrib is not managed by the core dev team, contrib is well contrib from its name, synchronized testing and releases, etc).

Thanks

#6

Some info from the past:

#7

A few years means a lot in terms of live span of a software module :slight_smile: . Any XWiki module could become obsolete in a few years, we’re just going to apply the standard deprecation strategy. So I wouldn’t worry about this.

The way the editor is configured doesn’t change. You’ll still be able to configure additional plugins.

It doesn’t have Java code at all, aside from the integration tests and page objects. The org.xwiki.contrib package is used to load resource from the WebJar and to get the installed version. In both cases the code will have to be updated, but there’s no breakage.

The problem is with the new image selection UIXP that uses the org.xwiki.contrib, but we can consider it as an unstable UIXP and simply rename it.

+1 for the move.

#8

Since we seems to all agree on the idea, we need to discuss its application.

Option 1: move ckeditor rights now

  • merge ckeditor to branch 13.10.x
  • merge ckeditor to branch 14.4.x
  • merge ckeditor to branch master
  • move ckeditor to the attic

Option1 bis:

  • merge ckeditor to branch master
  • keep the ckeditor integration extention for the other branches and move it to the attic when they are not supported

Option2: wait for the next lts

  • merge ckeditor to branch 14.10.x
  • move ckeditor to the attic

Option 1 is the most straightforward, Option 1 bis is a bit safer but requires to keep maintaining and releasing ckeditor for a few months. Option 2 is the simplest but requires to wait for a few months (and to keep releasing ckeditor independently until then).

WDYT?

#9

+1 for Option 1 bis, sure it means we keep supporting ckeditor contrib until 14.10.x is the new LTS but it’s only for blocker bugs so I’m not sure it’s that much work

#10

+1 too for option 1 bis

#11

I’ve created [XWIKI-19928] Migrate CKEditor to XWiki Platform - XWiki.org JIRA for option 1 bis.

#12

And the corresponding pull request https://github.com/xwiki/xwiki-platform/pull/1875

#13

In addition to the PR linked above, other points needs to be discussed.

Documentation:
I propose the leave the documentation at https://extensions.xwiki.org/xwiki/bin/view/Extension/CKEditor%20Integration/

Jira:
I propose to:

  • create a CKEditor component in the XWiki Platform project.
  • move all the improvement and tasks issues from the CKEditor project to the XWiki Platform project
  • Leave existing bug issues in CKEditor, but create new ones in both project when needed

WDYT? Do you see other points to discuss?

#14

Not sure what you exactly mean by “when needed”, but I would suggest duplicating them right away (if there is a tool to do that in Jira). We should see on both sides what are the bugs affecting them.

#15

Bug for features added only on Platform are not needed on CKEditor.

+1, ideally with a too indeed.

#16

OK, you were talking about new bugs reported starting now and not about bugs already reported on Jira. Then indeed it’s a case by case things and IMO what will happen is that we’ll fix a bug on platform and sometime also fix it on contrib in which case a contrib side issue will be created.

#17

14.4.8 will be the last release of stable-14.4.x before removing this branch (involving a release of CKEditor contrib extension 1.64.9).
Consequently, no maintained branch of XS will depend on the CKEditor contrib extention.
Unless somebody objects, I propose to move CKEditor contrib extention to the attic once 14.4.8 is released.

#18

+1

#19

Also note that unresolved issue from Jira Loading... will need to be triaged and moved to Loading..., unless:

  • they are duplicates
  • they are only relevant for the contrib extension
#20

Was implemented.