What is Rustango-CMS?

Goal: understand what Rustango-CMS is, the three ways it gives you to make pages — from fixed pages made in code to free pages that editors build themselves — and the two ways to show them: drawn by the CMS, or by your own frontend.

Who this is for: everybody — editors, site managers and developers. Read this page first.

Time: about 10 minutes.

A CMS in a few words

A CMS (content management system) is the admin behind a website. Editors sign in, write pages, upload photos and publish — without code and without a developer.

Rustango-CMS is a CMS written in Rust, on top of the rustango web framework. The site is a tree of pages, and every page has a page type.

Next to pages, the admin also has media (photos and documents), menus, categories, reusable content (the Library), forms, translations, workflows and more. The ceramics shop tutorial shows many of them.

Three ways to make pages

Every page is made from a page type. The question is: who decides the shape of the page, and how much freedom do the editors get? Rustango-CMS gives you three answers. You can use all three on one site — even on one page.

1. Model-based page types — made in code

A developer writes the page type in Rust. It gets its own table in the database, with one column for each box. Editors fill in exactly these boxes — nothing more, nothing less.

The shop's Workshop type (a pottery class) is made this way (shortened):

#[derive(rustango::Model, rustango_cms::PageType, Default, Debug, Clone, Serialize, Deserialize)]
#[rustango(table = "shop_workshop", app = "shop")]
#[page_type(type_name = "Workshop", verbose_name = "Workshop", template = "workshop.html", icon = "event")]
pub struct Workshop {
    #[rustango(primary_key)]
    pub id: Auto<i64>,
    #[rustango(fk = "cms_page", on = "id", unique)]
    pub page_id: i64,
    #[field(widget = Date, label = "Date")]
    pub date: Option<String>,
    #[field(widget = Integer, label = "Seats", help = "How many people can join.")]
    pub seats: Option<i64>,
}

• Good for: pages your code depends on — the home page, a listing page with its own logic, pages you search, sort or filter by a field. The data is typed and checked, fast to query, and easy to use from Rust.
• Extra powers: only code-made types can change their behaviour — for example which children the page lists, or extra data for the template (see The helper traits).
• The cost: every change is a code change: a new field needs a developer, a migration and a new deploy.

2. Page types built in the admin — the Page Builder

A site manager (or a developer) designs the page type in the admin: Utilities → Page types → + New page type, then Build fields. There is no code and no new database table — the values of all pages of the type are saved together as JSON.

The builder has more than simple fields:

Changes are a draft until you click Publish, and every published version is kept. The shop's Product type is made this way — see Make a "Product" page type.

• Good for: many pages with the same shape that may change over time — products, events, team members, job offers. The shape can grow without a developer.
• The cost: no Rust logic of its own, and the values are JSON, not table columns. A code-made parent page can still read them — the shop page shows every product's price and photo that way.

3. Content constructors — editors build the page

Here the page type only decides which blocks are allowed. Each editor then builds each page from blocks, in any order: click + Add block, choose a block, fill it in, move it up or down.

The building parts:

• Good for: pages that are all different — landing pages, "About us", articles, campaign pages.
• The cost: less structure. Two pages of the same type can look very different, and the data is harder to use in other places (search filters, lists, the API).

Side by side

Mix them

The three ways are not a choice for the whole site. They work together:

• a model-based type can have a Stream field — the shop's Home page has fixed boxes for the big photo and heading, and a free "Introduction" made of blocks;
• a type built in the admin can have a flexible zone — fixed fields for the price, a free zone below;
• any page can show Library elements, so shared text is written only once.

Two ways to show the pages

The three ways above decide how a page is made. A separate question is who draws it for visitors:

Every page type works both ways — made in code, built in the admin, or full of blocks. The API is always there next to the normal pages, so one site can let the CMS draw most pages and send some content to an app.

• Developers: A headless storefront shows the ceramics shop on a second website in plain JavaScript, and Preview drafts on your own frontend adds the draft preview.
• Editors: nothing changes, except the extra preview buttons — see When your site has its own frontend.

How to choose

1. Does code need the data (searching, sorting, special logic)? → model-based.
2. Will there be many pages with the same shape, and should non-developers be able to change that shape? → build the type in the admin.
3. Is every page different? → give the type a Stream field or a flexible zone, and let editors build.
4. Is the site drawn by another program — an app, or a website in another language? → keep any of the three, and read the content from the API.

When you are not sure, start with a type built in the admin. You can move a type to code later, when you need its extra powers.

Next

• Editors: How to find your way around the admin.
• Everybody: build a whole shop with all three ways — Build a ceramics shop, step by step.
• Developers: Getting started — a new Rustango-CMS project from an empty folder.