Editor extension point: plugin toolbar buttons, slash-menu items, and inline objects (lightweight complement to #1172)

[cyface]

Problem

Plugins can add block-level Portable Text types via admin.portableTextBlocks (they appear in the slash menu and edit via Block Kit fields), but there is no way for a plugin to extend the editor at the inline level:

• no custom toolbar buttons,
• no slash-menu items that insert inline content at the cursor,
• no custom inline objects/marks (TipTap nodes) with plugin-defined editing UI.

Verified against the current docs: /plugins/creating-native-plugins/portable-text-components/ (block types only), /guides/working-with-content/ (slash commands are a fixed set: /section, /image, /code, /html), and /concepts/admin-panel ("plugins cannot override core admin screens").

Concrete motivator: our site renders [[card:slug.field]] data tokens — a WordPress-shortcode equivalent that substitutes live product data (rates, fees) at render time, so numbers in editorial copy stay true to a nightly partner feed instead of drifting. Editors currently hand-type the tokens, or copy them from a plugin admin page we built as a picker. What we actually want to ship is an "Insert Product Data" toolbar button / slash item: a small form (pick entry, pick field) that inserts the token at the cursor — ideally rendered as an inline chip rather than brittle raw text.

Related prior art, and why this is a separate ask: #1172 proposes a contentEditor hook to replace the editor per collection — its problem statement confirms nothing today extends the toolbar short of replacement. This request is the lightweight complement: extend the stock editor, don't replace it. #637/#646 cover block-level editing fields and are orthogonal.

What we'd ask for (in preference order)

1. Inline object support for plugin block types — a portableTextBlocks entry flagged inline: true: edited via the same Block Kit fields, stored as a Portable Text inline child (span-level _type), rendered in TipTap as an atomic chip. Rendering on the public site would merge into <PortableText> the same way blockComponents already does, just for inline types. Best UX and sandbox-safe by construction (UI is still Block-Kit-described).

2. Toolbar / slash-menu extension API — a plugin declares a menu item (label, icon); invoking it opens a Block Kit form; the returned plain text is inserted at the cursor. No custom nodes involved. This alone would be sufficient for our token use case, and stays sandbox-safe.

3. Minimum viable — a documented way for a native plugin's admin entry to register a TipTap extension. Native-only and the least guarded surface, so we understand if this one is unattractive.

Open questions

• Should inline objects (option 1) get their own slash-menu section vs. toolbar placement — or both, mirroring how block types surface today?
• Serialization: Portable Text inline children have well-defined semantics (children array _types), so option 1 seems storage-clean — is there an admin-side constraint (TipTap schema generation) that makes inline harder than block?
• If Feature: contentEditor hook — allow plugins to replace the TipTap content editor per collection #1172's editor-replacement hook lands first, would you still take an extend-in-place API, or would the answer be "bring your own editor"? For sites that want 95% stock editor + one button, replacement is a steep cliff.

We'd use option 1 or 2 immediately, and are happy to help test.

Disclosure: drafted with AI assistance (Claude Code / Claude Fable 5); the use case, verification against docs, and follow-up are human (@cyface).

[esalazarv]

Another use case for this extension point, plus one related gap.

Tools that work on the text being written (proofreading, translation, rewriting help) need an entry point where writers already look: a toolbar button such as "Check now", or an item in the selection or context menu such as "Fix this". A field widget that wraps PortableTextEditor can register ProseMirror plugins through onEditorReady, which covers decorations and keymaps, but it cannot place a button in the host toolbar or menu. The only options today are a separate bar next to the editor, or manipulating the host's DOM, which would break on any admin change.

The declarative shape proposed here would cover this case: an id, a label, an icon, an optional collection filter, and a callback that receives the editor instance, with the host owning layout.

Related gap: host-rendered editorActions (placement toolbar or overflow, next to Save and Publish) are only resolved for plugins whose manifest adminMode is "blocks". A native plugin with a React admin entry cannot add an editor action, even though it can add panels, list columns and field widgets. Letting React-mode plugins declare editorActions would cover the "run this on the whole entry" case without a new extension point. Ideally the action would also have a client-side handler, so it can open the plugin's own dialog.