The CMS interface
The interface editors work in is not part of the NuGet package. MapRelatudeCmsUI() serves it from
the site's own address, at /relatude.cms/ by default, and the installation gets it from
services.relatude.com:
- Each time an editor opens the CMS, the installation asks the service which release to serve. It downloads a release only when it does not have it yet.
- It keeps the release in the database's storage, so a restart does not download it again, and serves that copy while the service cannot be reached.
- A release's files are served under its version and cached by browsers for good. The page itself is never cached, and a page opened before a new release keeps working.
| Route | Does |
|---|---|
GET {ui}/ |
the interface's page, for the release the installation serves; {ui} redirects here |
GET {ui}/?dev |
the same release's development build |
GET {ui}/r/{version}/… |
the release's scripts, styles and other files |
License and API key. The CMS needs a license with the feature cms. The installation sends the
server's ApiKey setting (the admin UI's Settings, or RelatudeDB:ApiKey in appsettings) to the
service at the server's ServicesServerUrl setting, unless CmsApiOptions.ServicesUrl names
another. When there is nothing to serve, a short page says why:
| Status | Why |
|---|---|
| 503 | the server has no API key |
| 403 | the service refused the key; the page gives its reason |
| 404 | no release is published |
| 502 | the service cannot be reached, and the installation keeps no copy |
A refusal, or no release published, is never answered with the kept copy. When the license is in
force but lacks cms, the interface shows a page saying so in place of its login, and the sign-in
routes answer 403. A license that cannot be checked changes nothing. To serve releases from
somewhere else, register your own ICmsUiSource.
Releases. A release has its own version, a channel, and the oldest CMS package it runs on. The
channel says how finished it is: release, beta or alpha. An installation takes the releases of
its channel and of the steadier ones, so beta takes betas and releases, and alpha everything. An
installation on an older CMS package gets the newest release that runs on it, and is told of the
newer one, which needs a package update.
An installation serves the newest release of its channel, or the one version an administrator holds
it to. Administrators choose under Settings → Updates in the CMS, which lists the releases with
their notes. The choice is the server setting CMS › Interface releases (UIChannel and
UIVersion), read each time the CMS is opened. When the version held to cannot be had, because it
was withdrawn or needs a newer CMS, the newest of the channel is served and Settings → Updates
says why. A choice set in configuration or code can only be changed there.
The path. The server setting CMS › Hosting › CMS path (CmsServerSettings.UIUrlPath) moves
the interface, as the admin UI's path setting moves /relatude.db. It is read when the application
starts, and wins over CmsApiOptions.UIPath. The API moves with it, to {ui}/api, unless
CmsApiOptions.Path is set.
The development build. ?dev serves the release's development build: React's development build,
with its warnings and errors in full, and the interface unminified. Use it when you develop plugins
(chapter 20). Settings → About says which build is open.
What editors see
The interface is built from the model, so much of what editors see is decided in code.
Types. Every node type is shown with its icon, title and description:
[Node(Icon = "lucide:newspaper", Title = "Article", Description = "A story with a picture, for the news pages.")]
public interface IArticle : IPage {
string Intro { get; set; }
string Body { get; set; }
}The icon is a name from the server's icon library (set:name) or SVG source. A type without one
shows its closest base type's icon, else one the interface picks by its name. The title and
description are the type's own, not inherited, and a type without a title is named from its code
name. The admin UI's datamodel editor can set all three for one database.
Creating content. The New button opens a wizard. Editors pick a type, then, for a type the content tree holds, the site and the page it goes under. Nothing is stored until the editor saves. New content starts as a draft, so a new item's editor has Publish beside Save (Revisions and cultures).
The editor. A node's editor has a tab for each type that declares some of its properties, the node's own type first, and a Meta tab. On Meta, editors change the address, the access groups, the site, and the release and expiry dates. A release still to come, or an expiry already past, hides the node from the interface once saved, as the interface reads what is published now. A type can bring a layout of its own (Form layouts).
The content tree follows RTree, the page tree every IPage has, unless the CMS setting
CMS › Content › Content tree (Content.Tree) names another one-to-many relation. When sites can
be in the relation, it shows one site at a time. A page whose Show in tree (ShowInTree) is off
is left out, with everything below it, unless the editor asks to see those pages. Editors drag nodes
to move or copy them, with or without their children. Before a large copy the interface warns, past
CmsApiOptions.TreeCopyWarnAt nodes (The content tree).
The preview, beside the editor, shows the page of the node being edited, and loads again when
content is saved. When the editor has a draft or an archived version open, the preview shows that
version (Previews of drafts). Its Edit button opens the page on screen in
the editor. The site must let its own origin frame it: X-Frame-Options: DENY, or a
frame-ancestors that leaves out the site's own origin, leaves the preview blank. SAMEORIGIN is
fine.
Processes, such as a copy or a large delete, open in a dialog with their progress, Pause and Cancel, which editors can minimize (Processes).
Maintenance, under System, is where administrators run the tasks described under Sites and see the nodes each one found. Other users see the tasks but cannot run them.