This was the first CKEditor5 in Drupal core meeting, held in drupal.slack.com in the #ckeditor5 channel.

0️⃣ This is an informal first CKEditor5 in Drupal meeting, please say hi if you're around (include your d.o)!Please feel free to post in these threads or start your own

lauriii hey :wave:
Gábor Hojtsy (he/him) hi
nod_ hi
hansa11 Hello! :wave:
larowlan Hi

1️⃣ Meeting time and cadence

zrpnr This was a time that was green across the doodle, but we are still a small group and I didn't make an actual announcement.I thought a small async posting would be good to start, but if another format works better I'd be glad to set up something else.
lauriii Sounds good. We can schedule calls on specific topics that would benefit from that :thumbsup:
Gábor Hojtsy (he/him) Agree
Gábor Hojtsy (he/him) I think every other week would be best for cadence. I can add it to the core events calendar.
Gábor Hojtsy (he/him) Created in the core calendar and invited @zrpnr and @lauriii. Happy to invite more :slightly_smiling_face: @larowlan should I add you?
Gábor Hojtsy (he/him) Also I think we can conclude right away that Dec 31 is not going to happen :smile:
Gábor Hojtsy (he/him) Which will be in two weeks on Thu
Gábor Hojtsy (he/him) Should I move it one week later or the one mid-January is fine?
larowlan I'll always be late, so no need for invite thanks anyway

2️⃣ Builds and source files

zrpnr For the prototype I'm keeping all the javascript src for the custom CKEditor5 build in the module, but eventually we will want to either change how the build step works or package the source elsewhere.There's some overlap with the decoupled menus and js modernization plans, such as #3176918: [policy, no patch] Publishing / Maintaining JS libraries produced by Drupal that do not have a dependency on Drupal
Gábor Hojtsy (he/him) @zrpnr so there is first the plugins Drupal provides, like for media, then the question is how the altogether built ckeditor is arrived at no? is this about the later?
zrpnr yes, the latter-CKEditor5 provides pre-compiled builds like the "classic" editor, but we would want to compile our own custom build with a selection of CK5 plugins and features.
zrpnr there are also javascript plugins that would be specific to Drupal where we would want to manage their source and add to the "build"
Gábor Hojtsy (he/him) hm, so would we pre-pick certain plugins and then offer even more plugins with the webpack dll method? why not have all of it with webpack dll? is that only for specific things or we would want to use it only for specific things?
zrpnr even if all the plugins were loaded dynamically, I think we would still have some custom build. For example, in the prototype I'm creating both the "classic" for textareas and "decoupled" for quickeditIf that build was packaged somewhere the source wouldn't need to live in Drupal core,
Gábor Hojtsy (he/him) ah makes sense, that is an important distinction (edited)
larowlan Three another core issue to move to package.json for external dependencies, so that could be relevant here

3️⃣ Plugins

zrpnr I think a combination of CKEditor5 plugins for changing markup and Drupal plugins for passing config makes sense, and I have a few examples in the prototype.However it currently means including some plugins in the build, adding / removing some at runtime.The CK team is working on a DLL system, https://github.com/ckeditor/ckeditor5/issues/8395
lauriii Have you had a chance to test their DLL branch?
zrpnr I haven't yet, but to start I'll try out the steps in https://github.com/ckeditor/ckeditor5/issues/8395#issuecomment-738807959
Gábor Hojtsy (he/him) As Piotr said, this is their direction so it would be good to provide “early” feedback IMHO
larowlan Have they looked at rollup, it has a solid plugin api

4️⃣ Media and Image upload

zrpnr The existing CKEditor has an image upload plugin which lets the user add an inline-image. This predates Media of course, and it would be good to build something now that uses Media.Wim suggested in #2966864: Add optional support for CKEditor 5 in D9 so we can remove CKE 4 from Drupal 10#comment-13924050 we could consider saving a media entity for even these inline images, and still get to keep the nice CKEditor5 UI like multiple uploads.
lauriii I don’t have a strong opinion to either direction but I’m in favor of the current approach just for the sake of simplicity on our side
lauriii to limit the amount of effort that needs to be put into it
zrpnr For the image upload, I used some code taken from REST and JSON:API, there's a related issue: [#2940383]CKEditor5 can post the image directly so I made a controller to handle it.The response needs some work too, currently only the src can be returned, but Drupal needs at least the uuid and the type for this to work.https://github.com/ckeditor/ckeditor5/issues/5204
Gábor Hojtsy (he/him) @zrpnr does that mean ckeditor5 module would require media module or just some internal API part of media?
zrpnr I don't think it should require it, the idea was to save a media entity if it's enabled but work as-is without it
zrpnr it's related to [#3073901]finding a way for the old inline-image to coexist with media,
Gábor Hojtsy (he/him) Yeah I think the real question is whether people want to use images instead of media. Is that a reasonable use case that core wants to keep supporting or make it a contrib problem.
larowlan Easy out of the box initiative wants media to be a default, so this would align with that
Gábor Hojtsy (he/him) Yeah the default. So we punt image direct upload to contrib with ckeditor 5?

5️⃣ Arbitrary html and full html mode

zrpnr The CK team is working on some solution for this, since CK5 has a more explicit data model markup can be converted or lost if it's not part of the schema. It's a bigger problem for old content, or sites that have been migrated.see: https://github.com/ckeditor/ckeditor5/issues/592#issuecomment-470424532T... may be some mitigations even without arbitrary html support, such as a way to warn the user before saving an old node with a new editor,For newer content we may eventually not have "Full html" in standard[#3097468]A related issue is the allowed_html filter, Drupal strips out disallowed tags on render, and it's currently a nice feature in CKEditor that the editor matches the rendered output.In the prototype I added a validation to the editor settings form, so if Drupal's allowed_html doesn't match the build you get a warning. This needs some more work and thought!
Gábor Hojtsy (he/him) I don’t think warning before saving is a good step. You spend an hour crafting your node update and then it tells you some things will get lost, but you don’t really know what, etc.
Gábor Hojtsy (he/him) Turning off the editor at that point is too late because it already killed your markup that you don’t want to loose, right?
Gábor Hojtsy (he/him) So that would really need to be an interstitial before showing the editor to confirm you are ok loosing markup, and even then I don’t think we can exactly tell you what markup(?)
larowlan This is a hard problem

Participants:

lauriii, Gábor Hojtsy, nod_, hansa11, larowlan, zrpnr

Comments

zrpnr created an issue. See original summary.

tim.plunkett credited nod_.

tim.plunkett’s picture

Adding credit

zrpnr’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

tim.plunkett’s picture

tim.plunkett’s picture