How a richtext field looks and behaves in the entry form. The field shows the
content as it reads; pressing it expands a TipTap editor
into the record’s work area, with a toolbar for text style and size, colours
and highlights, alignment, lists, links, callouts, tables, column layouts, and
embedded images and video.
Install
npm install @apograph/wysiwyg-adminRegister
// apps/admin/src/plugins.ts
import { WysiwygPlugin } from '@apograph/wysiwyg-admin';
WysiwygPlugin();Register it after ContentPlugin() — it contributes to a slot that plugin
declares. No configuration, no environment variables.
It is not a place in the app
No route, no navigation entry, no page. Its entire surface is one contribution
to content-admin’s ENTRY_FIELD_CONTROL_SLOT, which is why it appears
everywhere an entry form does — a collection’s editor and a single alike, on
the General tab and inside a localized type’s Translated and Shared groups —
without knowing about any of them.
There is no server counterpart
richtext is an existing content field type owned by
the content plugin. This plugin changes the
control, not the schema, the wire format, or the API.
What gets stored
The document — the editor’s node tree, not an opaque HTML string. A
richtext value is structured, which is what lets a delivery client render it
into something other than a <div> of somebody else’s markup.
A body written before that change is still an HTML string in its column. Opening it seeds the editor, which parses it through its own schema, and the first save commits the document — so content upgrades as it is edited rather than in one migration that has to be right the first time.
See rich text for the document shape a delivery client receives.