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.