Sections and pages

Reading time 7 min

Admin > Sections manages physical top-level sections and their Settings, Editors and Pages tabs. Admin > Pages searches saved Markdown and displays planned reader URLs. These areas describe server source, not the currently deployed reader or another browser’s unsaved text.

What a section means

Identity Meaning
Folder name Physical top-level source and assignment key
Display title Reader label and title-derived URL segment
_index.md Section landing, metadata and body
Position Ordering of folders, not access priority
Hidden Omit sidebar entry, not build/search/privacy
Assigned editor Writer scope, not reader membership

For fictional Field Guide, engineering/ is the writer boundary. Its display title can be Engineering Guide without changing that assignment key. A nested folder is a reader grouping inside the same top-level assignment, not a separately assignable role boundary.

The catalog counts saved Markdown descendants including section/nested landings. Assigned-editor counts include disabled editor accounts when they still hold the assignment. Administrator access is global and does not need a checkbox grant. Counts are organizational facts, not evidence of current active writers.

Section Settings fields

Field Accepted value
Title Nonblank text, at most 120 characters
Folder Lowercase letter/digit first; letters/digits/dash/underscore
Position Integer from -10000 to 10000
Hide from sidebar Boolean checkbox

Title is trimmed when saved. Folder form uses exact ^[a-z0-9][a-z0-9_-]*$; this form does not promise to normalize an invalid name into a valid one. New-folder creation has a separate normalization path. Position defaults to zero when catalog metadata is not an integer; lower positions sort before higher, with title tie-breaks.

Title/position/hidden live in section _index.md. Changing hidden removes the sidebar branch but still generates descendants, URLs and search entries. It is unsuitable for secrets, retirement or authentication. Content structure explains nested ordering and source layout.

Metadata save, discard and conflict

  1. Select the exact physical section and inspect loaded values.
  2. Edit only intended title/order/visibility/folder values.
  3. Save changes; title/folder changes ask for confirmation.
  4. Wait for final result, including any partial failure.
  5. Recheck saved metadata/path/grants before building or publishing.
  6. Inspect generated and deployed routes separately.
State Behavior
Local edit Unsaved section settings; server unchanged
Save active Fields/save/discard gated
Save success Catalog reloads; Publish reminder
Discard Loaded selected values restored
Other selection/back Unsaved discard decision
Other detail tab Settings draft remains
Stale source 409; reload before saving

The revision is SHA-256 of loaded _index.md text, including body. Another writer changing its body can invalidate a metadata form even without touching title. Server checks current revision and writes via temporary file/rename. Preserve intended edits, read current source and reconcile rather than forcing an overwrite.

The metadata helper owns title/order/hidden, preserves body and tries to retain other frontmatter text. It verifies that other parsed keys remain equal. Complex YAML that cannot be safely preserved is refused with a direction to edit _index.md directly. This is not a universal YAML round-trip form. Review source diff after unfamiliar metadata edits.

Discard restores the loaded selected object, not a historical server version. A stale loaded value can differ from current disk. A failure after disk save/reload can be reported as not completed; inspect saved state before repeating.

Rename is a two-step operation

Step Effect
Metadata save Writes title/order/hidden first
Folder rename Changes physical path separately
Assignment update Rewrites matching editor grants, bumps auth versions
Session invalidation Affected writers sign in again
Reader rebuild Applies saved title routes and links
Host release Changes actual public responses

If folder rename fails after metadata succeeds, the UI says “Settings saved, but folder rename failed”. Inspect actual _index.md, old/new path and account assignments. Do not assume all changes rolled back. The rename handler attempts filesystem rollback if account-assignment update throws; this is a local recovery attempt, not a distributed transaction across all browsers and hosts.

Titles can move public routes below the section. Folder renames change source/draft keys even when explicit titles keep public routes stable. Other browsers’ drafts retain old paths and are not automatically migrated. Ask writers to save/recover work and plan link/host redirects before renaming.

A conflicting target is not overwritten. The build rejects colliding normalized public URLs. ASCII slug normalization can collapse different/non-ASCII titles, so inspect actual route map rather than relying on display names. V2 does not create automatic redirects for old titles/folders.

Editors tab applies immediately

Action Result
Toggle assignment Confirmation, not a delayed publication draft
Confirm Apply Saves that editor’s full section list
Success Reloads catalog/users; sessions end
Failure Error shown; inspect current grant
Disabled editor Label remains; grant does not enable account
Administrator Always global; no assignment row required

This view lists all editor accounts with selected-section checkbox. Adding/removing this section preserves other loaded grants, but another operator may have changed them since loading. Reconcile unexpected concurrent scope before overwriting a full list. Account-store write locking is not a human policy merge.

Unsaved section/access edits are guarded before assignment actions. Changed grants invalidate sessions immediately, not after Publish. Check allowed and denied source paths in a fresh writer session. Admin visibility is not an editor-access test. Accounts and access owns role/session/reset details.

New section

New section creates a top-level folder and _index.md starter. The create endpoint normalizes folder names and refuses empty/duplicate/unauthorized locations. Only administrators can create top-level sections; editors can create nested folders inside assigned sections through editor file actions.

After creation, inspect the returned physical path and metadata. Write a useful landing with audience, scope and learning path. A starter landing is not finished documentation and creation does not publish it. Save then build/review; assign writers separately when intended.

The Sections console deliberately has no whole-section Delete button. The editor file tree has separate destructive folder deletion. Do not use it to hide a section or presume assignments/browser drafts are cleaned up everywhere. Preserve source/backups and plan old-reader-route removal first.

Section Pages tab

Pages lists saved Markdown belonging to selected top-level section, including nested landings. Selecting one moves to Admin > Pages details. It is not an embedded editor, unsaved draft list or generated output listing.

A page count includes _index.md files, so compare like-for-like when checking build page totals. Generated404and special homepage behavior are separate. A title appears from valid string frontmatter or filename/folder fallback. Invalid/unusual metadata can require direct source investigation.

Global page catalog

Display Read as
Title Saved frontmatter title or fallback
Path Exact source relative to content root
Section Physical top-level folder or Top level
Public URL Planned title-derived path
Modified Server source mtime, not review approval

Search is case-insensitive substring over title plus path, not full Markdown-body search. No matching pages/sections is a catalog filter result, not proof of missing source everywhere. Catalog skips dot-prefixed entries and symlinks. Pages sort by source path; section list sorts by position/title.

Planned Public URL is root-relative and does not include configured deployment baseUrl/site origin. It can describe changed saved metadata before a successful build, and a displayed plan can still collide. Build/reader/host is the final check. Do not paste a private editor origin in front of this route and call it the public site.

Open uses /?file= with encoded source path and normal editor authentication/draft behavior. New page chooses top level or one top-level section in this dialog; use editor folder controls for nested destinations. It creates starter Markdown, not a final public article.

Rename page file changes the basename in place, not a general cross-folder move. With an explicit title, the route can remain stable; fallback titles can change with filename. Delete asks for exact-path confirmation and removes source permanently without built-in undo. Publish/deploy removes generated reader only when output/host obsolete files are actually replaced.

Check every affected layer

Check Evidence
Source Actual saved metadata/body/path
Grants Current account sections and version
Writers Fresh session, allowed and denied paths
Build No collisions; intended routes/index
Reader Title, sidebar, search and internal links
Host Old URLs/status/redirect and deep links
Recovery Prior source/runtime/output retained

A successful metadata save does not prove successful folder rename, publication or remote deployment. Recheck exact result before closing the change. Use disposable content for destructive/denied-path tests. Production host access, browser-draft coordination and organization-wide migration remain operator work, not automatic V2 features.