Overview
Not categorizing as *bug* because this, like many other things XB, is functionality that hasn't been built yet. Nothing has been broken, etc.
I assume we want this? If the wysiwyg is provided in node/edit, we oughta provide it in the XB equivalent.
Proposed resolution
- CKeditor 5 appears in fields it is expected to appear in
- The contents can be updated with CKEditor 5 formatting. We do not need to evaluate nuances of the full feature set of CKEditor 5, we just need to confirm something can be formatted for now
- Dialogs triggered from CKEditor 5 do not have to work yet - this is covered in a different issue
- If some toolbar items are not visible or the sticky positioning isn't quite right this is fine , it will be covered in a different issue
Getting the basic functionality of CKEditor 5 in now unlocks a bunch of additional needed work. The minutiae can be addressed in later issues.
User interface changes
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | CKE5 in content entity form — media.gif | 1.95 MB | wim leers |
| #14 | CKE5 in content entity form — image.gif | 1.24 MB | wim leers |
| #14 | Screenshot 2025-04-07 at 3.25.45 PM.png | 27.94 KB | wim leers |
| #14 | Screenshot 2025-04-07 at 3.25.37 PM.png | 20.44 KB | wim leers |
| #14 | CKE5 in content entity form — format switch.gif | 127.68 KB | wim leers |
Issue fork experience_builder-3512867
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
wim leers💯 — and this was surfaced in #3512433-6: Provide visibility into which (core) field types (74%), field type props (63%) can be mapped into Content Type Templates vs not, and which field widgets (36%) are supported earlier today (for component instance forms specifically):
🤓
Note that this is a special beast, see
\Drupal\editor\Element::preRenderTextFormat():and
— IOW the Text Editor (
editor) module alters the text field type's widget's form render array representation 😅Comment #4
bnjmnmMR I just opened has logic that gets CKEditor5 to appear. It's not ready for prime-time yet but the underlying issue has been identified and there is a solution.
Comment #5
wim leersNice first step! Does CKEditor 5 itself also work?
Comment #6
wim leersComment #7
bnjmnmThe CKEditor 5 editor works - you can format the text using the various buttons like one might expect.
Do the contents of the edited-by-CKEdtor5 field get saved? That part does not appear to work. Unless it proves reasonably simple, that can be tackled in a separate issue once this lands.
Comment #8
bnjmnmMy next step was to see if changing editors worked, and ran into a situation that will likely require nontrivial refactoring. The underlying cause may cause problems for more than just this use case.
Radix
<Select>does result in a<select>tag in the UI. It is instead a button that triggers the appearance of selectable options.Drupal.behaviors.editorvery much expects a<select>, in some cases not adding the listeners unless that is the element type.The Radix select does have a hidden
<select>, which is not exposed as a ref in@radix-ui/themes,but looks like it miiight be accessible if we access it more directly instead of the theme. I did some exploring and this doesn't look like something that can be done quicklyThe only ref we can access via Radix is the<button>offered by the UI. Because this ref is available, it's possible we can use it as the basis for aquerySelectorto get the<select>but we'd need to see if that indirect-reffing is stable. If that can't work the only alternative that comes to mind is either patching Radix or using something other than Radix for this particular element. Other solutions might occur to me in time.Comment #9
bnjmnmGot this working by querying from the available ref
Doesn't feel the most solid to me, but maybe it's OK. So far seems to work.
Comment #11
wim leers@bnjmnm in #2 I expanded the scope to . Back then, I didn't yet understand that the content entity form needs a very different treatment! 🫣
In HEAD, you literally can't get such a widget to show up in the component instance form. But with #3467959-51: SDC and code component props should be able to receive HTML, editable in formatted text fields+widgets, you can:

Would you prefer:
The choice is yours :)
Comment #12
wim leersDiscussed #11 with @bnjmnm — let's first land this one, because it's so close!
Comment #13
wim leersThis also blocks #3484395 — see #3484395-8: CKEditor 5 not loading on formatted text Field Widgets in the component instance form.
Comment #14
wim leersChanging issue queue component because this really only affects the Semi-Coupled Theme Engine
ui/src/components/form/components/drupal/*.tsx!To help get this over the line, I tested this MR manually.
The essentials work, but not everything:
Actual (screenshot of
/admin/config/content/formats/manage/basic_html):@bnjmnm: Thoughts on which of these to tackle here vs deferring to follow-ups?
Comment #15
nagwani commentedComment #16
bnjmnm#14.2-3
Will be addressed in #3519146: Address CKEditor 5 "more items" bar contents not being fully visible
#14.4 #14.1
Will be addressed in #3519141: Dialogs opened by CKEditor 5 need to be rendered with admin theme
Comment #17
wim leersProgress! Let's get this in! 🚀
Comment #20
wim leersComment #21
larowlanOpening a follow up for a few things spotted in posthumous review
Comment #23
larowlanOpened a new MR with the stuff I had in an in progress review that I finished off this morning after it had already been merged - should have finished it yesterday - sorry!
Comment #24
wim leers🙏 Could you review Lee’s additions here, Ben?
Comment #26
bnjmnmThe followup MR was straightforward and welcome, added.
Comment #27
bnjmnmComment #28
bnjmnmComment #29
wim leersYay! Most important next step: #3484395: CKEditor 5 not loading on formatted text Field Widgets in the component instance form.
Comment #30
wim leersComment #31
nagwani commented