Dnn.Platform
Dnn.Platform copied to clipboard
dnnsoftware
[Enhancement]: Replace CKEditorProvider with a New Provider
Is there an existing issue for this?
- [X] I have searched the existing issues
Description of problem
The existing CKEditor has reached end-of-life; upgrading to the latest version of CKEditor is not possible due to the license model changing.
As we look for a replacement, this ticket was created to document the minimum requirements necessary.
HTML Editor Settings Requirements
The existing CKEditor provider supports multiple overriding levels of configuration of many settings, and not all of them work as desired or are no longer supported.
To simplify this configuration, we would support the following configuration.
- Host Configuration
- This would be the default configuration of the editor for all portals, including the toolbar configuration, security setup etc
- Portal Configuration
- This would be an override of the host level, with different options for input/validation as supported by the platform. With an additional ability to limit the toolbar by a given Role, at minimum.
Configuration elements should be stored via the file system in a SECURE JSON file.
Breaking Changes for Those Transitioning from CKEditor
By supporting the above, we would no longer support the following features.
- Page Configuration - You are no longer able to override editor settings, including role-based toolbar adjustments at the page level
- Module Configuration - You are no longer able to override editor settings, including role-based toolbar adjustments at the module level
- No Migration Path Provided - Users must reconfigure any existing editor configurations.
HTML Provider Implementation Requirements
The following items must be implemented.
- WebForms Modules must still able to leverage the existing UserControl for integration
- Users must be able to browse for image assets to include in HTML content, leveraging all DNN API's & security, including proper linking (relative or LinkClick.aspx)
- Users must be able to browse for assets to link (documents), leveraging all DNN API's and security
- Configurations must be Applied
- Must function within an UpdatePanel for Web forms module
- Multi-Language support for the static text/prompts of the editor.
It would be desired, if possible when doing this also to support
- Usage from SPA or MVC Module using a supported pattern (Web Component or otherwise)
Possible Breaking Changes for those Migrating from CKEditor
- Content Templates - Currently in CKEditor you can modify the configuration to add content templates, this MAY not be supported by other editors
- Linking to specific portal pages using a dialog may not be supported
Description of solution
Possible options for providers would be
The critical requirement is that anything included be Open Source and controlled under a license that is allowable for consumption by a MIT-based project and actively maintained and distributed via a durable channel (NPM etc).
Description of alternatives considered
No response
Anything else?
This is being created to start conversations regarding the future for the HTML Editor, this needs future planning, validation that we are not missing other breaking changes AND developers to implement the final solution, so please discuss.
Do you be plan to contribute code for this enhancement?
- [ ] Yes
Would you be interested in sponsoring this enhancement?
- [ ] Yes
Code of Conduct
- [X] I agree to follow this project's Code of Conduct
Let me start by saying I'm interested to contribute on this one, out of interest, and because we have several clients that needed changes to the current CKEditor Provider.
Personally, I wouldn't scratch the page- and module-level configuration all that easy. I'd prefer to keep those, but solve the issues we have with it, like creating a better insight into what setting is coming from where.
I don't have an issue with storing the settings in a file, although having them in the database is also quite convenient and can help greatly in figuring out which setting is actually active.
In the current provider, there's a bit of a separation between DNN-related settings, and CKE-related settings. The DNN-related settings having to do with roles, pages, folders and things like that, whereas the CKE related settings (that monstrous Editor Settings tab on the provider options popup) basically is a 1-on-1 mapping to the javascript options for the CKEditor.
We should IMHO provide a decent user interface for the settings that are DNN-related. Basically these are the 1st 2 tabs on the settings page, the toolbars tab is a bit in between, to me.
Those editor-settings have turned out to be a pain: those options are exactly the things that tend to change when upgrading to a newer CKE version. The result is that we now have quite a few settings that just don't work anymore, and interesting settings we don't support. I'd advise to address this quite simple: give the administrator a way to add options to the editor (usually that's a json object anyway) and give them a way to add some javascript to be exectued after initialization.
In terms of requirements I'd like to stress out that host-level settings should be possible to be set on a host level. I added a few improvements in this area over the past year or so: for example: if you set a default file browser folder on host level, it doesn't make sense to store that as a fodlerId, since they differ for each portal. Same goes for roles.
Another rquirement would be an option to add images like we added with EasyImageUpload but is unfortunately broken now since the last CKE upgrade: a simpler way of adding images: no server browser where you can upload, but a straight away the file upload dialog to select a file from your machine.
That's about it for now. I'll see if I can come up with more later on.
why storing configuration in file instead of the database?
The recommendation for this was to allow easier manual edit for larger customization
I'd advise to address this quite simple: give the administrator a way to add options to the editor (usually that's a json object anyway) and give them a way to add some javascript to be exectued after initialization.
This is exactly why the idea of JSON storage rather than DB storage to allow easy management of editor only items. As trying to "map" everything is an exercise that I don't believe that we want to try that again
I'd advise to address this quite simple: give the administrator a way to add options to the editor (usually that's a json object anyway) and give them a way to add some javascript to be exectued after initialization.
This is exactly why the idea of JSON storage rather than DB storage to allow easy management of editor only items. As trying to "map" everything is an exercise that I don't believe that we want to try that again
Right, that's indeed exactly what I meant. Although storing in the DB would still be possible. But like I said, I don't have an issue with storing settings in a file.
@mitchelsellers I researched the licensing of CkEditor 5 a few moths ago and read that they can still give out other type of v5 licenses for OS projects. I can't find the blog post any more (of course) but here the same is suggested: https://github.com/ckeditor/ckeditor5/issues/991#issuecomment-385015577
So it might be interesting to contact them before deciding to "replace" the editor?
@mitchelsellers I researched the licensing of CkEditor 5 a few moths ago and read that they can still give out other type of v5 licenses for OS projects. I can't find the blog post any more (of course) but here the same is suggested: ckeditor/ckeditor5#991 (comment)
So it might be interesting to contact them before deciding to "replace" the editor?
On the pricing page it sais this:
What about toast-ui/editor i've used it lately in a project and really liked it. it is MIT
If we switch to a new editor, I feel that Markdown should be an (optional-use) requirement and on by default. Oh, and toast-ui/editor (mentioned above by @sboshuis) does Markdown. :)
"I've wanted to do [markdown] for years." - All the young dudes
I think it'll be nice to have like a favorites option where you can select the most popular feature each user used more frequently and allow people to choose to display the favorites only; by doing this maybe we can clear out the display a little bit and allow each user to have a custom option bar for the editor.
If we switch to a new editor, I feel that Markdown should be an (optional-use) requirement and on by default.
Markdown could be a nice to have feature, but in my opinion not turned on by default. The default should remain the Word-like interface my mom would be able to use.
If we switch to a new editor, I feel that Markdown should be an (optional-use) requirement and on by default.
Completely agree. New stuff always works best when it doesn't change (much) the old stuff everyone is used to. We don't want to be like Microsoft and every time we buy cheese, move it to a new place in the fridge . :)
IMHO, even with a new WYSIWYG editor, the default experience after upgrade should be as close as possible to the old/current.
As an FYI, I contacted CkSource who then Contacted @mitchelsellers and there is NO license available for CkEditor 5 that we can use.
See also: https://dnncommunity.org/forums/future-development/Projects/dnn-connect-brainstorm-wysiwyg-editor/
So this is not necesarilly a breaking change, since the current provider can still be included next to the 'new' provider. I mean, the CKeditor will remain working for as long as it keeps working. This might start as an optional extra provider
