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.
+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.
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.
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.
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).
A few years means a lot in terms of live span of a software module . 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.
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).
+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
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.
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.
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.
. 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.