[META] Port some initial CKEditor 4 plugin integration modules to CKEditor 5

@baddysonja suggested some of the CKEditor projects maintained by 1xINTERNET may be a good option for converting.

• https://www.drupal.org/project/ckeditor_bootstrap_table
• https://www.drupal.org/project/ckeditor_autocomplete
• https://www.drupal.org/project/textmatch
• https://www.drupal.org/project/textwatcher
• https://www.drupal.org/project/floatpanel
• https://www.drupal.org/project/xml
• https://www.drupal.org/project/ckeditor_ajax
• https://www.drupal.org/project/emoji
• https://www.drupal.org/project/ckwordcount
• https://www.drupal.org/project/notification
• https://www.drupal.org/project/codesnippet

I have not evaluated any of these, but at a glance it seems like a few may not apply to CK5 and there are some which may be better handled by a different plugin. For example emoji could be special characters and codesnippet may be covered with either Code (included in the main project) or CodeBlock

Great idea! 👍

But I'd suggest that instead of focusing on CKE4 modules contributed by a single organization, we should focus on the most widely used ones?

• Linkit: #3232190: CKEditor 5 readiness
• Editor Advanced Link: #3232052: Drupal 10 & CKEditor 5 readiness

editor_advanced_link (#3232052: Drupal 10 & CKEditor 5 readiness) is ready! 🥳

linkit is almost ready, it's now fully working, see #3232190-14: CKEditor 5 readiness! 🚀

With nearly 70,000 installs, the embed ecosystem as a whole is likely a non-trivial endeavor that could really stress test the existing API.

There are also integration complexities with things like Entity Browser that may catch edge cases.

Just an idea.

@Luke.Leber: Agreed! However, I'm far less concerned there. Rather than overriding existing functionality, it's completely independent functionality. CKEditor 5 is already integrated with Media Library and renders media embeds just fine. That is for Drupal core, not for https://www.drupal.org/project/entity_embed. But … that Drupal core functionality was actually a simplified port of https://www.drupal.org/project/entity_embed into Drupal core! It was hardened in contrib before going into Drupal core. Examples: #3064340: Make preview responses cacheable to accelerate previews, #2844822: The preview in CKEditor does not use the same Twig template as the one on the front end (default theme), #3064288: Only upcast `<drupal-entity>`, not any tag that has the appropriate `data-` attributes and many more.

So, while we definitely should have that ready, it's less likely it will find more edge cases.

Unfortunately, that module is de facto unmaintained 😱I am a co-maintainer for it simply because I had to help stabilize it before extracting the best parts of it for the media integration in Drupal core.

Any chance you're interested in becoming a co-maintainer, and start the CKEditor 5 port? 🤓😃 We'd definitely be able to give you any and all help you'd want or need! That'd allow us to continue working on stabilizing the CKEditor 5 module itself further for more edge cases.

Hey Wim, I don't think that I need to assume the mantle of co-maintainer to be able to contribute to entity embed. I probably won't have time til closer to Christmas, but will keep it on my back burner.

We have a unique use case in that we're running a customized embed formatter plugin (since long before core media embed support came to ckeditor4) and I'm eager to see if this can continue to be supported or if we'll have to figure something else out before cke4 support drops. It would be really nice if the upgrade path for folks like us that had to customize things before core media landed would be seamless.

I'll try to follow the same path as linkit and editor advanced link did and see what shakes out.

That does sound interesting :)

That customized embed formatted plugin runs on the server side. The CKEditor code just provides a blank canvas for rendering. So I’m pretty sure you’ll be fine.

I think the key question here will be whether h you want the nicer UX without a Drupal dialog (more work), or the current UX. The current UX should be easy to port, and there already is an example in the form of the Media Library button.

Good luck and keep us posted!

Adding the "ckeditor5" tag to make it easier to find other issues.

Semi-blocking CKEditor 5 issue: https://github.com/ckeditor/ckeditor5/issues/11128.

Hi,

I would vote for this Drupal module https://www.drupal.org/project/ckeditor_emojione too :)

There are many dependencies in the emoji module tho, compared to the emojione module.

CKEditor Font (#3239667: Drupal 10 & CKEditor 5 readiness) seems, at face-value, to be a (relatively?) simple port from 4->5, being a ckeditor core plugin that has a pretty light configuration. I'm also a co-maintainer, and would be happy to help on this in what ways I can.

#18: Why not rely on the OS-level emoji picker? Anyway, a quick search reveals https://ckeditor.com/docs/ckeditor5/latest/features/special-characters.h... — so supporting this should be trivial, since Drupal core already ships with the SpecialCharacters package, it just doesn't load the emoji-specific plugin in that package yet:

ckeditor5_specialCharacters:
  ckeditor5:
    plugins:
      - specialCharacters.SpecialCharacters
      - specialCharacters.SpecialCharactersEssentials

→ you'd need to add SpecialCharactersEmoji there and configure it correctly. The contrib module should be simple to port (can you please create an issue in that issue queue? 🙏), but IMHO it should not be ported: content creators should start using the OS-level emoji picker. Every OS has shipped with that for years now.

#19: 🥳 Great news! Commented over at #3239667-9: Drupal 10 & CKEditor 5 readiness 😊

Agree completely with the "more native solution" in #20. In the example in the ckeditor5-docs is the emoji is part of the "special chars ckeditor5-bar. Then I would vote for a separate button like a "🙂". Best would be inside there also emoji categories, like common in several messengers.

I think you're contradicting yourself there? On the one hand you agree with using the native emoji picker, on the other you advocate for an even more custom UI? I'm confused now :D

Wim, in the example editor for the emoji's here the emoji's are inside the "special chars" (the omega sign). Then the user has to select the emoji's category, if he only wants emojis. IMO it's a bad UX (see the attached screenshot).

I just wanted to say it would be better for UX to separate the emoji's in an extra "button" (or however it's called 😅) in the editor's bar. The "native" technique behind the scenes is good as it it (so not necessary to implement 3rd party libraries like emojione for example)

When you say “native technique”, do you mean native to the CKEditor 5 Special Characters plug-in? Or do you mean native to the operating system? 🤓

Lots of projects are now well on their way. And some are even looking into merging duplicate efforts: #3297106: ckeditor_font merging with ckeditor5_font, colorbutton! 🥳