Skip to content
BetaDocs

The Editor

Use the visual editor to create pages, maintain content and review changes made by an AI agent. Browser editing does not require an AI connection or publishing accounts.

Choose the Organization, select the Site and Version, then open Pages and select a page. On a phone, open the sidebar menu first.

The site overview’s Published, Drafts, In review and Unlisted counters include all Pages of every content type in the selected version. Inherited content is counted once; items deleted in that version are excluded. These are saved content statuses, not confirmation that the content is live. Select All pages beside Recent pages to open the full page list.

Select Preview site at the top of the site overview to browse the selected version in a new tab, including saved drafts. This signed-in preview works before the first deployment and does not require a domain or connected publishing accounts. Internal links stay within the preview. Save editor changes first to include them.

The real Typeroll CMS block editor with sample content: structure on the left, preview in the middle and heading fields on the right.

The editor displays three panels when the screen is wide enough:

Panel What it holds
Left Add for the block library and Structure for the page’s block tree.
Center A live preview rendered from the page content.
Right Fields for the selected block, or page metadata when no block is selected.

The header provides undo/redo, preview devices, Meta for page settings and Publish for saving, status and deployment.

Narrow screens show one panel at a time. Use Blocks, Preview and Edit block or Settings to switch panels. Select a block from Structure to open its fields. Publish stays in the header, including the deploy control when publishing setup and your permissions allow it.

Mobile editor showing the selected heading's editable fields and the Blocks, Preview and Edit block panel controls.

The mobile layout changes how you navigate the editor. The preview device selector separately controls which responsive breakpoint you are editing.

Open the Add tab and either:

  • Click a block — it’s appended to the end of the page, or
  • Drag it into the Structure tree — a coloured drop-line follows your pointer showing exactly where it will land, including inside containers

Dragging is how you place a block precisely. Clicking is faster when you’re just appending.

Search the library by name at the top of the tab. Built-in type IDs are stable; custom types are Site-specific. Your custom blocks appear in the same list as the built-in ones.

Three ways, depending on what you’re changing:

Click a block in the preview or the tree to select it. Its fields appear in the right column, generated from the block’s own schema.

Double-click text directly on the canvas to edit it in place. Enter or clicking away commits; Escape cancels. This works on plain-text fields — headings, labels, button text — and is the fastest way to fix a typo.

Use the Structure tree for anything about arrangement rather than content: reorder by dragging, duplicate, delete, or double-click a row to rename the block (the name is a label for you; it doesn’t appear on the site).

The tree shows each block’s actual content — the heading text, the image filename — rather than just its type, so a long page stays navigable.

Add Table of contents to an article’s Page template. Choose the heading levels to include; the block automatically links to the headings on whichever Page uses that template. It has no separate contents field to maintain. Renaming, reordering or deleting headings updates the list when the page is rendered. Layout and appearance belong to the template, so they can be shared across all articles using it.

With Sticky on desktop enabled, the contents stay beside the article on large screens. On screens up to 720 px wide they scroll with the page, so they do not cover the text. Wide tables scroll inside their column instead of widening the whole page. These layout fixes require Core 0.2.3 or later; republish existing sites after upgrading.

In Core 0.2.7, the template’s Page content → Content spacing → Article setting adds space before and after body headings, including headings after videos and images. It affects the body slot only; navigation and card headings keep their own spacing. New Blog, Article and Checklist starters enable it. Existing templates keep their current spacing until you choose Article.

The sticky table of contents now clears a sticky or fixed site header and keeps clicked headings visible below it. It responds to header size changes. Use a semantic <header>, .site-header, or [data-site-header] outside the page’s <main> for a custom header. Long desktop outlines scroll within the remaining screen height. The Highlight current heading setting does not control positioning or anchor clearance.

For related articles, place a Container in the article column after Page content. Give it a background color and padding, then add a heading and a Repeater using Post Card. Choose Appearance → Card in the repeater’s item settings for a separate card surface, compact titles and padded text. Use responsive column counts to keep cards readable on small screens. These settings are available through block data in the API and MCP as well as the editor: rhythm: "article" on template_content_slot, and item_overrides: { appearance: "card" } on the repeater. Rebuild and republish existing sites after upgrading; changing a saved template does not update an already published static site.

Shortcut Does
⌘Z / Ctrl+Z Undo
⇧⌘Z / Ctrl+Shift+Z Redo
⌘D / Ctrl+D Duplicate the selected block
Delete / Backspace Delete the selected block
Enter Commit an inline edit or a rename
Escape Cancel an inline edit, close a dialog

Shortcuts also work when the block preview has focus. A shortcut waits for pending block autosaves; it never commits the Page. Text fields and inline text keep their native text undo. History lasts for the current editor session.

Undo covers block edits — adding, moving, deleting, field changes. A burst of typing in one field collapses into a single undo step, so one ⌘Z takes you back to before you started typing, not one character at a time.

The device buttons in the header do two things at once, and the second one is easy to miss:

  1. They resize the preview.
  2. They set which breakpoint you’re editing.

So if you pick Phone and then change a grid’s column count, you’ve set that value for phones only. Switch back to Desktop and the desktop value is untouched.

Button Preview width Breakpoint written
Phone 390px mobile (< 640)
Phone — landscape 740px tablet (≥ 640)
Tablet 1024px laptop (≥ 1024)
Tablet — landscape 1280px desktop (≥ 1280)
Desktop full width wide (≥ 1536)

Fields that support per-breakpoint values show a small badge with the current breakpoint. When a value is inherited rather than set explicitly, the badge says inherited and offers a reset control to drop back to the inherited value.

Breakpoints inherit upward from mobile: set something once at Phone and it applies everywhere unless a larger breakpoint overrides it. That’s why it’s usually best to design mobile-first and only override where a larger screen genuinely needs something different.

Click Meta in the header, or just deselect the current block, to get the page’s own fields: page title, SEO title, meta description, OG image and alt text, canonical URL, and the noindex toggle.

The same panel holds the Template picker and the Content mode switch (blocks ↔ HTML).

The Structure list displays decoded text (including accented characters). Empty-block labels are only editing aids: blocks with visible background images or embedded media do not receive a placeholder over that content.

When you reopen a Page with autosaved changes, choose Continue autosaved draft or Discard draft and open saved version before editing. The saved version is the last version explicitly saved in the CMS, which may differ from the live website. Going back in the browser does not commit your changes. Autosave keeps them available for recovery; only Save promotes them to the saved Page. This choice applies to both the block and HTML editors.

Content edits are kept in a working copy. They do not change the saved publication input or the live site until you save and deploy. Read the save state in the header, then open Publish:

  1. Changes — Save (commits the draft) or Discard (throws it away).

  2. Status — Draft, In review, Unlisted, or Published. Status changes apply to the saved page. They control inclusion in the next deployment; changing status does not by itself deploy the site.

  3. Deploy — rebuilds the static site from saved, published content. The panel summarizes pending changes below the deploy control. Open the change list for details. Build and distribution progress appear here; a public link is shown only after the deployment has been verified.

The Pages list also provides a site publishing control. If deployment is locked, follow the link to Publishing setup. You can keep editing and use expiring previews while setup is incomplete.

If the AI agent built something substantial, use Review changes. It shows the saved page and your draft side by side in the same renderer, plus a structured list of what changed block by block.

That’s the intended way to audit an agent’s work: look at the diff, then save.

Pages in HTML mode get a different editor — a CodeMirror pane with syntax highlighting instead of the block library, plus the same preview, metadata and Publish menu.

You also get SERP and Open Graph previews showing how the page will look in Google results and when shared on social, and a History panel for restoring earlier revisions.

Switch a page between modes with the Content mode control. Converting HTML to blocks is heuristic — check the result. Converting blocks to HTML discards the block tree. Both directions save a revision first, so neither is a one-way door.

Two related editors, reachable from the site sidebar:

  • Templates — a block tree that wraps a page’s content. Build the shared outer structure once, drop a content slot where the page’s own blocks should render, then assign the template to pages.
  • Blocks — create reusable custom block types for this site: schema, HTML template, scoped CSS, and optionally client-side JavaScript (which requires an explicit opt-in, because it runs in your visitors’ browsers).

Core 0.2.34 stores Firestore revision and field-history payloads without adding nesting to the Page tree. Existing history remains readable and restorable; no content migration is required. An invalid document that exceeds storage nesting limits returns HTTP 422 with code: "storage_document_too_deep", a field locator and a message in the UI/API. Reduce the indicated nesting instead of retrying unchanged content. MCP receives the same API error.

Custom breadcrumb labels are also preserved in static publications from this version. Deploy again to update existing public breadcrumbs.