CKeditor not loading on formatted text fields in the content entity + component instance forms

💯 — 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:

🤓

Note that this is a special beast, see \Drupal\editor\Element::preRenderTextFormat():

    // \Drupal\filter\Element\TextFormat::processFormat() copies properties to
    // the expanded 'value' to the child element, including the #pre_render
    // property. Skip this text format widget, if it contains no 'format'.
    if (!isset($element['format'])) {
      return $element;
    }

and

    foreach ($editors as $key => $editor) {
      $definition = $this->pluginManager->getDefinition($editor->getEditor());
      if (!in_array($element['#base_type'], $definition['supported_element_types'])) {
        unset($editors[$key]);
      }
    }

— IOW the Text Editor (editor) module alters the text field type's widget's form render array representation 😅

MR 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.

Nice first step! Does CKEditor 5 itself also work?

Does CKEditor 5 itself also work?

The 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. It that can be tackled in a separate issue once this lands.

My 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.editor very much expects a <select>, in some cases not adding the listeners unless that is the element type.

 if (editor.tagName === 'SELECT') {
          $this.on('change.editorAttach', { field }, onTextFormatChange);
        }

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 quickly, but there is a forwarded ref in the Select primitive, so it should be possible somehow. However, even if the <select> can be accessed via ref, we may still run into a limitation with some part of Drupal due to the select in the UI not being an actual <select>

Got this working by querying from the available ref

const hiddenSelect =
      selectRef.current.parentElement?.querySelector<HTMLSelectElement>(
        'select[aria-hidden]',
      );

Doesn't feel the most solid to me, but maybe it's OK. So far seems to work.

@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 CKEditor 5 → , you can:

Would you prefer:

1. to narrow the scope here back to only the content entity form?
2. to tackle both here?

The choice is yours :)

Discussed #11 with @bnjmnm — let's first land this one, because it's so close!

This also blocks #3484395 — see #3484395-8: [PP-2] CKEditor 5 not loading on formatted text Field Widgets in the component instance form → .

Changing 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:

1. the dialog to switch to a different text format renders incorrectly and is inaccessible:
2. not all CKEditor 5 toolbar buttons are accessible. Visible:

   Actual (screenshot of /admin/config/content/formats/manage/basic_html):
   

3. if I move the "image" button to the accessible part of the toolbar, it works:
   
4. if I add the media library functionality and move it to the accessible part of the toolbar, it almost works — styling looks off, and I cannot type an alternative text so I cannot actually upload new images into the media library:
   

@bnjmnm: Thoughts on which of these to tackle here vs deferring to follow-ups?

#14.1

Addressed in the MR.

#14.2-3
Will be addressed in 📌 Address CKEditor5 "more items" bar contents not being fully visible Postponed

#14.4
Will be addressed in 📌 Dialogs opened by CKEditor5 need to be rendered with admin theme Postponed

Progress! Let's get this in! 🚀

wim leers → closed merge request !848

Opening a follow up for a few things spotted in posthumous review

Opened 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!

🙏 Could you review Lee’s additions here, Ben?

The followup MR was straightforward and welcome, added.

Yay! Most important next step: 📌 Support props that can use wysiwyg widgets Active .

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