Editing content

A space exists to be filled. Once it’s running, the day-to-day work is editing — creating pages, writing text, placing images, arranging lists — and CTXR does this without a separate admin panel. There is no back office to log into and keep in sync with the front; editors work on the live site itself, the same pages a visitor sees, with a thin editing layer laid over the top.

The toolbar is the editor

When you sign in to your space you get a toolbar. From it you browse what’s there, create new content, and manage the space. Click something on a page and you can change it where it sits; or open a form panel and fill in a node’s fields precisely. Both doors lead to the same content — editing a title in place or in the form writes the same property either way. And both travel the same way underneath: every edit the toolbar makes is an operation on the space’s own API — the same surface an external system would use.

Editors only ever touch content. They never edit templates, styles or files — that’s the build layer, and it belongs to a developer (see What is a space). The line is deliberate: a code change can’t disturb live content, and an editor can’t break the site by editing it.

Drafts, then live

Nothing an editor changes goes public the instant they type it. Edits collect on a draft — a private working copy of the page — and stay there until someone with permission approves them. Approval is the moment the change is compiled and published; before that, visitors keep seeing the last approved version. This draft-to-live rhythm is a platform-wide principle, explained in The tinycycle.

The practical effect is calm: you can leave a page half-finished, hand it to a colleague, or revert it, all without anything leaking to the public site. Publishing is a decision, not a side effect of editing.

Who can edit what

As the space owner you always hold full rights. Everyone else edits within the permissions you grant — you decide who may create, who may publish, and who may only look. Each editor signs in with their own email, and external systems get their own keys with their own permissions. How those rights are defined and enforced is covered in Access & permissions.

Going deeper

This page is the what and why of editing, from the space’s point of view. The technical side — how a template becomes editable, the three-layer contract, and the editable atom types — lives in The editing experience in the Development chapter. The exact data-* attributes the editor reads are catalogued in Editor attributes.