Switch context item text fields to string_long for clean MDXEditor integration
## Summary Follow up to: #3586170 Convert the context item text fields (`content`, `purpose`, `description`) from `text_long` to `string_long` and remove the forced-plain_text workaround. This is a storage schema change, so it must land **before rc1** while the schema is still cheap to change. ## Problem These fields are `text_long`, whose `text_textarea` widget always pulls in Drupal's format selector + filter/editor pipeline. On Drupal CMS that defaults to the CKEditor-backed "Content" format, fighting our markdown-via-MDXEditor authoring. To work around this, `AiContextItemForm::afterBuildForcePlainText()` currently: - forces `format` to `plain_text` and hides the format selector, - strips CKEditor5 libraries, - filters `#attached` libraries/drupalSettings to keep only MDXEditor. This is brittle: it fights the field type rather than configuring it, and it relies on string-matching library names. ## Why string_long is the right model Nothing in the module consumes the `text_long` `format` column: - Editing: MDXEditor (attached via `data-mdxeditor`). - Display: `MarkdownFormatter` (CommonMark → HTML, ignores `format`). - LLM output: `AiContextRenderer` passes raw markdown text through. MDXEditor is designed to attach to a plain `#type => 'textarea'` (see ai module docs: ui/mdxeditor), which `string_long`'s `string_textarea` widget provides natively — no format column, no format selector, no CKEditor. So `string_long` removes the unused `format` column honestly instead of suppressing it at runtime. ## Plan (Option A) 1. **Entity** (`AiContextItem::baseFieldDefinitions()`): change `content`, `purpose`, `description` from `text_long` to `string_long`; drop the `allowed_formats` widget settings and the `format` default values. 2. **Form** (`AiContextItemForm`): remove `afterBuildForcePlainText()` and the library/drupalSettings stripping; keep the `data-mdxeditor` attach. The widget becomes a plain `string_textarea`. 3. **Display formatter** (`MarkdownFormatter`): already declares `string_long` in `field_types`; confirm the view display still uses it. 4. **Diff** (`DiffHooks`): switch the three fields from `text_field_diff_builder` to `core_field_diff_builder` and drop the `compare_format` setting (string_long has no format). 5. **Update hook** (`ai_context.install`): migrate storage from `text_long` to `string_long` — preserve the `value` column, drop the `format` column — for any existing installs. 6. **Config**: update any exported entity form/view display config to the new field type. ## Rejected alternative (Option B) Keep `text_long` but use a dedicated no-editor text format restricted via `allowed_formats`. Avoids the schema change but keeps the unused `format` column and still needs the single-option selector hidden. Rejected because `string_long` is the honest model and the schema change is cheap pre-rc1. Note: earlier "add a `markdown` filter format / use the `format` column" suggestions are also rejected — they re-engage the CKEditor pipeline that MDXEditor is meant to bypass. ## Acceptance criteria - [ ] Sense check this is the right approach to the problem - [ ] `content`, `purpose`, `description` are `string_long`. - [ ] MDXEditor loads on these fields with no CKEditor/format-selector leakage. - [ ] `afterBuildForcePlainText()` and the library/drupalSettings stripping are removed. - [ ] Existing context items keep their markdown content intact (verified by an update-hook test). - [ ] Display (`MarkdownFormatter`), LLM output (`AiContextRenderer`), and revision diff behavior are unchanged. - [ ] `./lint.sh` passes; unit/kernel/functional tests updated and green. ## Priority Pre-rc1. Storage schema change — must land before the schema is frozen. ## AI usage - [x] AI assisted issue - [x] AI generated code
issue