Documentation

Write and review a page

Choose an editing mode, organize the page tree, use branches and anchored comments, and recover safely when a draft does not render.

  • 3 min read
  • Updated Aug 22, 2026

Every Nibleaf page has one Markdown source. Visual, WYSIWYG, and Markdown are editing modes for that source, not separate documents. Preview is a separate action that opens the saved draft in a reader view. Wait for Saved before leaving a page or publishing.

Choose an editing mode

ModeUse it forCheck before leaving
VisualStructured blocks, slash commands, tables, and rearranging content.Complex components still contain their attributes and children.
WYSIWYGFocused prose editing with less interface chrome.Headings, lists, and links kept their intended structure.
MarkdownDirect source changes, bulk edits, and syntax unavailable as a visual control.Fences, component tags, and blank lines are balanced.
If a page contains a component the structured editor cannot safely round-trip,
Nibleaf keeps that block read-only or opens the page in Markdown mode. This is a
data-preservation boundary, not an error to bypass.

Use Preview after changing structure, components, links, or mixed-direction text. The preview action saves pending content before opening the draft in a new tab; allow pop-ups for the Nibleaf origin if the tab does not open.

Organize pages around reader tasks

Use groups to create a shallow hierarchy and pages for content readers can open. Give each page one primary purpose. A practical product manual normally exposes getting started, common tasks, configuration, operations and troubleshooting, and reference without copying the application's internal menu.

Before moving or renaming a published page, record its public path. Parent groups contribute to the path. Add a direct permanent redirect from the old path and update internal links so readers do not spend a hop on normal navigation.

Review a substantial change

Create a branch before a migration, large rewrite, or page-tree reorganization. Use a name that describes the outcome. Add anchored comments to the exact block being reviewed, then resolve or record every blocking discussion.

Review the branch as a reader:

  1. Open every changed page in Preview.
  2. Test new links and paths.
  3. Search using words a reader would type.
  4. Check a narrow mobile viewport and keyboard focus.
  5. Confirm title, description, indexing, and language relationships.
  6. Merge the reviewed branch into the default draft, publish once, and verify the public deployment.

Recover from a bad draft

If the public version is still correct, stop before publishing. Compare the draft with the last ready deployment or a Markdown export, repair one section, wait for Saved, and preview again. For a conflicting multi-writer change, preserve both sources until the intended version has been reconciled.

Publishing history helps with content releases, but it is not a database backup. Self-hosters should also follow backup and restore.