Meeting Details

This CKEditor5 in Drupal core meeting is held biweekly on Thursdays at 15:30 UTC (10:30am ET)
in drupal.slack.com in the #ckeditor5 channel.

Meeting notes

0️⃣ Hi and welcome to the biweekly CKEditor5 in Drupal meeting!

This meeting happens every other Thursday at 15:30 UTC
Please say hi if you're around (include your d.o for issue credit)!
Feel free to post in the threads or start your own
You may also join the meeting later and participate asynchronously!

Piotr Koszuliński Hi :wave:  I’m Reinmar on d.o
gaurav mahlawat Hi :man-raising-hand: Gauravmahlawat  on d.o
lauriii Hi :wave:
hansa11 Hello :wave:
anmolgoyal74 Hello. (anmolgoyal74) (edited)
markie Hi everyone.. (markie on d.o)... Looking at the issue queue now
gapple :wave:

1️⃣ Current development in the Contrib project

zrpnr Just a reminder that the Proof of Concept on the core branch is no longer active,
All development is being done in contrib where there are a number of issues open.
Please feel free to review, test or open feature requests here:https://www.drupal.org/project/ckeditor5

2️⃣ DLL Integration

zrpnr The Drupal module is using webpack DLL builds to split up the compiled js.
Previously this was an experimental feature in CKEditor5 and local setup was tricky.
Looks like https://github.com/ckeditor/ckeditor5/pull/8614 is now merged, and the https://github.com/ckeditor/ckeditor5-dev/ also has the dll integration branch merged in too.
zrpnr I will pull down the latest from these repos and update our documented development process.
This is really great news!
Piotr Koszuliński Oh yeah, thanks :slightly_smiling_face: This was a huuuuge change. We’re now cleaning up some followups. There’s a codefreeze next week and we should have the most important ones ready by then. Then, the release will happen a week later.
We’re not going to publish DLLs to npm yet as we’re unsure about the form that will work best for wide community and some other details. However, as the refactoring on our side is done, you’ll be able to generate DLL-compatible builds based on the code that’s on GH or by copying some bits (like the webpack config) to your project.
Later this year we’d like to complete this task and have DLLs officially on npm. The challenge for now is updating tones of documentation and what to do with the current builds and that’s why I want to postpone making these decisions.
Piotr Koszuliński I’m going work on updating some documentation for DLLs next week so I’ll be able to give you some hints on what’s the easiest integration path for you.
zrpnr Thanks! much appreciated!
zrpnr Do you think there will be big changes in how the builds work after your refactoring?
zrpnr for example, would I need to rebuild a plugin that was built using an older manifest.json ?
Piotr Koszuliński No, it’s mostly about how you import things
Piotr Koszuliński You will only be able import directly from the ckeditor5 package.
Piotr Koszuliński Prior to the refactor, that package had no content
Piotr Koszuliński Right now it re-exports stuff from several other packages:
Piotr Koszuliński https://github.com/ckeditor/ckeditor5/tree/master/src
Piotr Koszuliński All feature-packages (those that are not part of the core DLL build), should only have deps to ckeditor5 and to no other CKE5 package.
Piotr Koszuliński There’s also a concept of soft requirements, but it’s trivial to upgrade too.
Piotr Koszuliński https://github.com/ckeditor/ckeditor5/blob/master/packages/ckeditor5-blo... This is how the imports look right now. L10-11 are imports from the DLL. L13 is a local import (within a package) which is fine too.
Piotr Koszuliński Actually, here are the details from the merge: https://www.notion.so/DLLs-summary-dd3d17f4daea4d3d897e2fc81e5fdfe2. I wrote them for the team, but most of these things need to land in the docs at some point.

3️⃣ Quick Edit integration

zrpnr There is an open Merge Request to add support for Quick Edit, if anyone has time to review it would be appreciated![#3196689]I think the core inline-style js is no longer needed and can be removed, but @wimleers (he/him) pointed out that it was originally added to work regardless of the theme.
Any research or reviews here would be appreciated as well!

4️⃣ Drupalcon coming up!

zrpnr The CKEditor upgrade is still an important Drupal 10 initiative, which means the current CKEditor needs to be deprecated by 9.2 or 9.3 at the latest (correct me if I'm wrong)
At Drupalcon this April I'm planning to submit a session and there should be some time for sprints or contrib work.
If anyone has anything they want to cover, or any particular feature they want to work on, such as adding a contrib module,
including some markup or UI in the main module, or anything else- we can try to plan for that day.
zrpnr also any questions that I could answer in a session or features you'd like to see in a demo
markie I think the main demo, and issue I always get, is integration with the media entity types..
zrpnr @markie did you see the MR at #3194650: Support media elements and browse media library ?There needs to be a follow up for alignment, caption etc but this has a media preview in CKEditor5 and allows you to browse with media library
markie oh yeah.. sorry I thought you were asking for talk ideas..
zrpnr ah no i misread what you wrote! :slightly_smiling_face: yes I agree that would be a good thing to show in a demo or a talk

5️⃣ Arbitrary HTML update

zrpnr Not all markup is supported by CKEditor5 without adding the right plugins, so it's possible HTML written by hand or by a previous editor may not be preserved when loading CKEditor5 over existing content.
Switching between editors in Drupal already triggers a warning about data loss. @timplunkett (he/him) is plannng to add a similar warning on the text format selection page.
However there is still a possibility of losing migrated data from an old site to a new D10 site. It's possible we can address some of the data loss in Drupal, are there any updates from the CK team?
Piotr Koszuliński Do you mean how’s the general HTML support (we call it “GHS”) coming or whether there’s something that could help figuring out when a content has been lost? Like an event or any other API?
zrpnr I was thinking those 2 issues are connected-we are more concerned with potential data loss when doing an upgrade or a migration, and an event or some way to notify the user could be really helpful.
Piotr Koszuliński As for GHS, we’re still in the middle of a research, but simultaneously we started working on the first tasks.
We have first PRs for some shorter things (quick wins) that we identified (https://github.com/ckeditor/ckeditor5/pull/8996, https://github.com/ckeditor/ckeditor5/pull/8975).
However, the clue of the effort is in the GHS system. My colleague is now working on a PoC and the first step is the toughest as we need to a find a shape of this feature that has the promise to cover most important use cases. In very short, it’ll probably consists of a predefined by us data schema for HTML and an ACF-like configuration of what the editor should allow. The end result should be quite similar to how one configures CKE4. I suppose we should have first visible results in March and something usable (but highly incomplete) around April. Then, we’ll have a long list of followups and tasks required to make this “general support” really general :smile:
Piotr Koszuliński As for the event… I need to discuss this with the team. There’s a chance that it’s relatively simple, but the risk will be either missing something out or having too many false positives.
Piotr Koszuliński For instance, the most-rudimentary approach would be to compare the input to the editor (legacy data) with the output (what’s left). However, direct string comparison will fail too easily. Some smarter HTML diff can also give false positives when CKE5 adjusts e.g. whitespaces or normalizes some inline elements.
Piotr Koszuliński There’s an option to learn what got converted and how from the upcast converters. But if there’s a backup converter for some content that’s not really understood, but we don’t want to totally lose it, it’s also going to be converted, but still with some information lost. So we need to think about this.
Piotr Koszuliński I’ll try to think what options we have before the next meeting.

6️⃣ Data Migration

anmolgoyal74 Any plans on migration of data since Ckeditor 4 and 5 has a lot of difference in features
Taran2L The plan is to be able to do a migration as close is possible
anmolgoyal74 Can we allow option to use both editor.. means to have old ckeditor for existing data and ckedtor 5 for the new content
Piotr Koszuliński I wrote some details about this in https://drupal.slack.com/archives/C01GWN3QYJD/p1613058002018600. It’s a vast topic that we started back in December. We call it GHS (general HTML support) and it’s split to two major parts: extending existing features to accept legacy content and on the core of GHS system that will allow enabling more HTML features in CKE5 easily.
zrpnr allow option to use both editorthis is something we could work on in Drupal, currently a text format only allows one editor type. However the plan is to deprecate CKEditor in Drupal 9, and remove it in D10.CKEditor4 would still be available as a contrib module in D10
markie is the plan to replace CKEditor with something else in core? why are they removing it? (sorry this was news to me)
Taran2L plan is to replace CKE4 with CKE5, mostly due to end of life of CKE4 (correct me if I'm wrong)
Taran2L #3091226: [META] Select the best modern editor for Drupal 9

Participants:

Piotr Koszuliński (reinmar), gaurav mahlawat (Gauravmahlawat), lauriii, hansa11, anmolgoyal74, markie, gapple, zrpnr, Taran2L

Comments

zrpnr created an issue. See original summary.

tim.plunkett’s picture

Adding credit

tim.plunkett’s picture

tim.plunkett’s picture

Status: Active » Fixed
tim.plunkett’s picture

Status: Fixed » Closed (fixed)

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