Seeking a New Path for djangocms-text-ckeditor: Time for a Change

[fsbraun]

Hello, Django CMS Community,

I'm writing to discuss an important transition for the djangocms-text-ckeditor package. As many of you might know, CKEditor 4, the backbone of our current rich text editing in Django CMS, has reached its end of life. Additionally, its successor, CKEditor 5, presents many django CMS users issues with its license, necessitating a search for a new solution.

In response to this challenge, I have initiated a project to develop a potential replacement, which you can find at fsbraun/djangocms-text. This project aims not only to address the immediate concerns, but also to bring enhanced flexibility and functionality to our rich text editing capabilities. Here are the key changes and features I am focusing on:

1. Swappable Rich Text Editor: The new system will allow for a more flexible approach to rich text editing. The editor (the JavaScript bit), will be swappable, enabling users to choose or switch between different rich text editors according to their preferences and needs.

2. Customization and Extension: Users will have the opportunity to add new or customize their favourite rich text editors. This feature is particularly important for those who require specific functionalities or want to maintain a certain user experience consistent with their project's needs.

3. Enhanced Data Storage: In addition to the traditional HTML format, the new model will support storing content in JSON format. This advancement will offer greater versatility in how data is handled especially if you are looking for a headless solution.

As a first step in this transition, I plan to port the CKEditor 4 interface, including its child plugin functionality, to ensure a smooth and familiar experience for current users while laying the groundwork for these new features. Part of this transition will be to split the editor-specific JavaScript code from the CMS-specific code to make coding an interface for a new editor much simpler.

The child plugin feature will become optional (depending on your project settings).

I invite the community to join me in this endeavour. Your insights, suggestions, and contributions will be invaluable in shaping a robust and future-proof solution for rich text editing in Django CMS. Let's collaborate to make this transition as seamless and beneficial as possible for our community.

Thank you for your attention and support.

---

Looking forward to an exciting journey ahead!

[jrief]

I made good experience with the TipTap richtext editor. It is based on ProseMirror, which is widely used in various projects, but TipTap has a simpler programming interface.

Pros of TipTap:

• It can store the raw payload as JSON, allowing to add arbitrary data, for instance foreign keys to models.
• It is shipped without a toolbar, making it easier to be integrated into existing projects.
• It is impossible to add malicious HTML snippets, even if misconfigured.
• No need to use a plugin editor when adding elements, such as links, images, icons, etc.
• We do not need any "Text-enabled"-plugins anymore, because we can store all that data inside the JSON payload.

Cons of TipTap:

• Way harder to implement, since it is not plug-and-play.
• It requires to implement a special renderer, since the text body is not in HTML.

Django-Formset implements this kind of rich-text editor. Here are two demos:
https://django-formset.fly.dev/richtext/ and https://django-formset.fly.dev/bootstrap/advertisement

[fsbraun]

Its being "headless" means we get to fully integrate it into the django CMS look and feel. I think I'll take tiptap as a reference implementation for the editor interface. With respect to the rendering, I'll let tiptap render the HTML and post-process editor agnostic on the server side.

[Chilipp]

hey @fsbraun! I wrote down some django-app for a ckeditor5 in a project where I use django-cms (https://codebase.helmholtz.cloud/hcdc/django/clm-community/django-academic-community/-/tree/django-cms-4/academic_community/ckeditor5?ref_type=heads). The field implemented there (CKEditor5Field) is however not using the CMS-functionalities (as I did want to wait until there is progress in the djangocms-text-ckeditor). So I am happy to contribute here and work on the ckeditor5 implementation for djangocms-text 😃

[fsbraun]

Sounds great! I've fiddled a little and am positive that this is a good idea. I just would like task for a bit of patience until the API becomes somewhat stable...

[Chilipp]

alright, just let me know 😃

[fsbraun]

@Chilipp The time has come... Would you like to take a look at https://github.com/django-cms/djangocms-text ? There's a very basic CKEditor5 integration to start with. Would need to be configurable, support for text-enabled plugins, support for the new dynamic tags.

Let me know if you want to contribute, I can give you a short introduction.

[Chilipp]

@fsbraun my apologies for the delay! I am now available again and would be happy to contribute here 😃

Let me know if you want to contribute, I can give you a short introduction.

sure, why not. how and where do you prefer to do so? In the meantime, I will have a look into the code already

[fsbraun]

We have decided on nh3 as a html sanitizer in the technical committee on Feb. 9. It is a python wrapper around the Ammonia sanitizer. htmllib-based html clearing will not be part of djangocms-text. If you have custom sanitizer objects in your project, they will need to be adapted to nh3.