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