| 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. |
| 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 |
| 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. |
| 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 |
Piotr Koszuliński (reinmar), gaurav mahlawat (Gauravmahlawat), lauriii, hansa11, anmolgoyal74, markie, gapple, zrpnr, Taran2L
Comments
Comment #9
tim.plunkettAdding credit
Comment #11
tim.plunkettComment #12
tim.plunkettComment #13
tim.plunkett