Forum OpenACS Development: Re: CKEditor 5

Dear Josue,

We did some work that is already available upstream to integrate TinyMCE 7.

ad_form richtext fields and xowiki formfields work. For xowiki formfields, this includes repeated fields, compound fields and repeated-compound fields.

What is missing compared to the CKEditor 4 integration is custom OpenACS plugins. Some we have implemented downstream in a way that may be suitable for contribution at some point, for instance: * xowiki includelet * xowiki links * mathjax formulas * multimedia (with xowiki or file-storage backend)

However, as we are about to release we were not sure there was enough time to bring them up to the right quality.

Ideally, this should be the chance to rework the existing OpenACS plugins so that they could work with different editors regardless of their specific api. Our downstream implementations try to do this, but we still need to battle test them to see if we found a good solution.

During the implementation we have introduced for richtext editors the concept of "preset". A preset is basically a proc returning a configuration for the editor that we want to label according to a use case. An example of preset is "standard", "minimal", or "forum".

The reason we have introduced this concept is, that on LEARN we have coalesced on 5 or 6 configurations for our editor, that we use here and there on the system. So far, these configurations were dependent on the ckeditor4 syntax, but if we are to move, we wanted to provide a way to separate the logical aspect, e.g. "we want here a richtext editor with the minimal set of tools" from the editor-specifics. If we implement a ::richtext::ckeditor4::preset::minimal and a ::richtext::tinymce::preset::minimal, both returning an editor-specific configuration for the "minimal" use case, as soon as we change the preferred richtext editor in the parameter, the forms will keep behaving according to their preset, but using the new editor.

So far, we do not provide any out-of-the box preset in the usptream repo, because the idea is that presets are the places where we can put the nitty-gritty of our downstream richtext behavior. We may provide some upstream namespaced presets like "oacs_standard" at some point.

Feel free to try the richtext-tinymce package from the oacs-5-10 branch, feedback is welcome!

Concerning CKEditor 5, the current usptream code was based on a very early version of the editor and is probably not what you want. We are also working on an integration with the latest version, downstream-only for now. Upstreaming seems to be more complicated because of the way the editor has to be "built" for deployment, but I am not the person working on it. I will point my colleague to this post.