DynoStaticAdmin sign in
Documentation

CMS-backed Knowledge Base

CMS-backed Knowledge Base

Knowledge Base is a native widget that publishes one explicit, immutable release of a CMS collection. It supports a searchable article/category list and an FAQ accordion built with native details and summary controls. The hosted runtime remains ordinary PHP plus MySQL or MariaDB; Node is used only by development browser tests.

Publish a collection release

In Admin → CMS, choose a collection and publish a collection release. Release creation locks the normalized CMS schema, selects each entry's exact current publication revision, orders members by locale, public slug, and public ULID, and stores canonical schema, format, publication, and member-manifest SHA-256 values in one transaction. Drafts and unpublished entries do not enter a release.

Release headers and items are append-only application records. There is no edit or delete operation. Composite database foreign keys bind every header to its website and schema and every item to the same release website/schema, the exact CMS entry, and a publication belonging to that entry. A release continues to render the same publications after later CMS draft, publish, or schema work.

Configure the widget

Create a Knowledge Base widget and use Load release fields to prepare an immutable release belonging to the same website. Loading is a read-only editor step: it does not mutate the widget or trigger autosave. The builder then offers only compatible fields from that release's schema snapshot as labelled selectors. Choose List or FAQ, review the mappings, and explicitly save or publish to apply the prepared release.

  • List mode requires title and body; summary and category are optional.
  • FAQ mode requires question and answer; category is optional.
  • Text and slug fields can supply short labels. Text or document fields can supply bodies. Categories accept text or select fields.
  • Media, relationship, nested, missing, or type-incompatible mappings are rejected. One compatible CMS field may intentionally serve more than one semantic role. Mapping format version 1 has an exact closed key set.

The release picker lists the newest 500 releases and always includes the widget's exact current release even when it is older. The picker and field catalog are website-scoped, and an invalid or foreign requested release cannot disclose cross-website metadata. Without JavaScript, both mapping groups remain visible and submit the same complete mapping shape.

The widget draft stores the release public ULID, schema hash, manifest hash, and semantic mapping. Publication revalidates all four against the immutable release. Hidden hashes are integrity references, not operator-editable credentials.

Follow the latest release

“Follow latest CMS release” is an explicit administrator action. It locks the widget and current reference, finds the latest release of that same collection, validates the existing semantic mapping against the new immutable schema snapshot, and creates a new widget draft revision. It never changes an existing widget publication. Review and publish that draft through the normal workflow.

Public behavior and security

The initial page is server rendered. Subsequent search, category, and pagination requests use the subfolder-safe api/?action=widget-knowledge-base gateway backed by the physical /api/v1/widget/knowledge-base route and the publication's exact website/release reference. Page sizes are only 10 or 20 and responses contain at most 20 records. Search is capped at 120 characters; categories are bounded by the same 1,000-member release ceiling, and schema/format/publication/manifest bytes have fixed limits.

Only sanitized public scalars are returned. Document fields contribute their plain-text projection; stored HTML/source objects, nested values, CMS Bearer tokens, administrator credentials, and private drafts are never exposed. Origin authorization, Content Security Policy, output escaping, conditional ETags, and immutable widget-publication snapshots continue to apply. Native FAQ disclosures support keyboard activation without custom button semantics.

Backup and recovery

Current BK2 backups include both release tables in parent-before-child order and restore them exactly. Only the exact current baseline fingerprint and complete table catalog are accepted. Historical backup adapters have been retired. See Backup and restore.