marketplaces/docs/StaticPages.md

Static Pages (Project Editor module)

Sprint X+2. Full-featured CRUD editor for tenant static content (About, Privacy, Terms, Contacts, custom pages, etc.), living inside the Project Editor at /edit/static-pages. Edits bootstrap.staticPages directly — the same model the storefront renders from (docs/BACKEND_API.md#46-staticpages), no parallel content store.

/backoffice/static-pages (Admin dashboard) redirects here rather than hosting a second CRUD UI over the same data.

Where it lives

src/app/features/content-management/
  models/content-page.model.ts       ContentPage — the CRUD-facing shape
  services/content-page.service.ts   normalize / resolve / validate / serialize <-> StaticPageConfig
  facade/content-management.facade.ts
  components/
    static-pages-editor.component.*  the editor UI (list + per-page card)
    static-page-preview/             device preview (desktop/tablet/mobile)

src/app/shared/models/config/static-page.model.ts   StaticPageConfig — the bootstrap wire format
src/app/features/project-editor/components/html-editor/   MarketplaceHtmlEditorComponent (rich text)
src/app/core/config/static-page-resolver.service.ts        storefront resolver

ContentPageService is the single translation layer between the editor's ContentPage[] and the bootstrap's Record<string, StaticPageConfig> (or the legacy array format) — normalize/resolve/validate/serialize all live there. Nothing else should hand-roll that mapping.

Field reference

General

• id — stable key, also the bootstrap record key.
• slug — used for duplicate-slug detection and as the route default.
• route — independently editable from slug (defaults from it, but can diverge — e.g. a legacy redirect path). Validated for duplicates against every other page's route.
• enabled — master on/off switch. A disabled page never resolves on the storefront, regardless of status.
• Navigation visibility — showInHeader, showInFooter, showInSitemap (independent per-surface flags, unrelated to enabled).
• order — sort position in the editor list and (for footer pages) the auto-generated footer nav group.
• icon — optional icon identifier.

Localization

• title (per locale, in translations[locale].title) and a top-level title fallback.
• translations[locale].html — the rich-text/HTML body, one per supported locale.
• customTemplate — optional template identifier; consumed by nothing yet (data-only field, forward-compatible with a future template-selection feature).

SEO

Per top-level seo and per-translation translations[locale].seo (locale-specific overrides win when resolving): title, description, keywords, canonical, robots, ogTitle, ogDescription, ogImage.

Media

• heroImage, thumbnail — wired through the shared MediaPickerComponent (same picker used by Branding/Footer logos).
• gallery: string[] — a lightweight comma-separated URL list ("future ready" per the brief; no dedicated multi-upload UI yet).

Publishing

• status: 'draft' | 'published' — per-page publish lifecycle, independent of the whole-bootstrap draft/publish cycle (see below).
• Modified indicator — an "unsaved changes" badge per page, diffed against the originally loaded/published snapshot (ProjectEditorFacade.originalStaticPages).

The enabled + status gating story

A static page resolves on the storefront (ContentPageService.resolvePage, used by both StaticPageResolverService for the page route and FooterResolverService for the auto-generated footer nav group) only when enabled === true AND status === 'published'. This is independent of whether the surrounding bootstrap itself has been published — a page marked draft stays invisible even after the tenant hits "Publish" on the whole config, and only becomes visible once its own status flips to published.

Compatibility default: normalizing existing bootstrap data (loaded from the backend, imported, or read from a legacy array-format staticPages) defaults missing enabled/status to enabled: true, status: 'published' — pre-existing pages never get silently un-published by this feature landing. Only the editor's create-page action opts a brand-new page into status: 'draft' by default, so newly authored content doesn't go live until an author explicitly publishes it.

The Static Pages editor's own Live Preview (desktop/tablet/mobile, StaticPagePreviewComponent) intentionally bypasses this gate — it renders straight from the page's current in-memory HTML, so a draft page can still be previewed before publishing.

CRUD, search, filter, bulk actions

• Create, duplicate (clones a page as a new draft), delete (confirm dialog), reorder (up/down — not drag-and-drop; see below).
• Search across id/slug/route/title (all locales); filter by status (draft/published) or by locale (hides pages missing a translation for the selected locale).
• Bulk actions (multi-select checkboxes): delete, enable, disable, publish, unpublish.
• Important implementation detail: every mutation (create/duplicate/delete/move/bulk) operates on the full, unfiltered page list, never the search/filter-narrowed view — reading from the filtered view before writing back would silently delete whatever the active filter was hiding. See the persist() comment in static-pages-editor.component.ts.
• Reorder is up/down (move()), not literal drag handles — a deliberate, lower-complexity scope call; swapping in drag-and-drop later is additive.

Validation

ContentPageService.validatePages() returns: duplicateSlugs, duplicateRoutes (checked independently — a route can diverge from its slug), emptyTitles, invalidHtml (via schema/validators/primitives.validateHtml), invalidSeo (canonical/OG-image URL shape, and robots against a known-token set: index, noindex, follow, nofollow, and their comma-joined combinations). Surfaced as per-page badges in the editor.

This is layered under (not a replacement for) ProjectValidator's existing platform-wide checks (docs/EDITOR.md's "Configuration schema..." section), which already cover duplicate slugs and cross-surface duplicate routes (pages vs. static pages) at the whole-bootstrap level.

Rich text editor

MarketplaceHtmlEditorComponent — see docs/EDITOR.md's "HTML editor (Static Pages)" section for the full toolbar list, the Sprint X+2 additions (horizontal rule, code block, embed), and the HTML-mode validation contract.

Navigation integration

The Navigation section (navigation-section.component) has an "Insert page link" control (page picker + button) next to both header and footer "Add link." It creates a NavigationItemConfig { type: 'staticPage', key: <pageId> } — a shape the resolvers (StaticPageResolverService, FooterResolverService) already understood before this sprint; only the editor-side create path was missing. A static-page-linked nav row shows a "Linked to page" indicator instead of editable label/URL fields, since both are derived dynamically from the linked page.

Export / import / draft / publish

No changes to ProjectEditorIoService or ProjectEditorDraftStorageService — static pages flow through bootstrap.staticPages exactly as before, so JSON export/import and the draft-autosave/publish cycle work unmodified. All Sprint X+2 fields are additive and optional at the wire level.