Content management on Emet CMS

Entries

Mon, 01 Jan 0001 00:00:00 +0000

An entry is a Hugo content file: frontmatter on top, Markdown underneath. Emet reads the frontmatter into a form, hands the body to the editor, and on save writes the whole thing back as the same kind of file you’d have written by hand. If you open the file in a text editor afterwards, it should look like you did.

Which folders show up, and which fields each entry has, comes from the sections block of admin/site.yaml. See Sections for the config; this page is about what you do with them.

Bulk actions

Mon, 01 Jan 0001 00:00:00 +0000

Renaming thirty files by hand is exactly the sort of job a CMS should do for you, and exactly the sort of job that’s miserable through a web form one file at a time. Bulk actions let you select entries in a section’s list and rename, move, publish, unpublish, edit a frontmatter field, create translations or delete the lot in one go. On GitHub-hosted sites each action is a single commit.

Data files

Mon, 01 Jan 0001 00:00:00 +0000

Hugo’s data/ directory holds structured data that isn’t a page: navigation menus, author profiles, pricing tables, anything your templates read through .Site.Data. These are plain YAML, JSON or TOML files with no frontmatter and no body, which makes them a poor fit for the entry editor and a good fit for a form.

Choose Data in the sidebar to browse the whole directory, nested folders and all. There’s nothing to configure: every .yaml, .yml, .json and .toml file under data/ shows up (or under <base_path>/data/ if you’ve set a base path). Files are listed by name with a format badge, folders are listed above them, and the breadcrumbs start at Data so you can get back out of a nested folder. An amber dot marks a file with unsaved changes.

Archetypes

Mon, 01 Jan 0001 00:00:00 +0000

Hugo archetypes are the templates hugo new uses to stamp out a content file: some frontmatter, perhaps a placeholder body, with Go template variables for the title and date. Emet uses them the same way when you create an entry, and gives you a small editor for them so you don’t have to leave the CMS to change what a new post starts with.

Which archetype applies#

When you create an entry, Emet works out the section path from the folder you’re in. content/blog becomes blog, and content/en/resources/tutorials becomes resources/tutorials (the language prefix and any base_path are stripped). If you’ve drilled into a subfolder, that’s included too. It then tries, in order:

Media library

Mon, 01 Jan 0001 00:00:00 +0000

Images in a Hugo site are just files in static/, referenced by path. The media library is a modal for browsing that folder, uploading into it and picking a path to insert, so you don’t have to remember whether it was /images/2026/hero.jpg or /img/hero.jpg.

It opens from the image button in the editor toolbar, from Browse on image and file fields, and on its own when you drop or paste a single image into the editor.

Sync

Mon, 01 Jan 0001 00:00:00 +0000

Emet has no database of its own. On a GitHub-hosted site, the branch you’re editing is the database, and a small sync service running in your browser keeps your view of it current and ships the few changes that don’t go straight to GitHub. This page is about what gets committed when, what the indicator in the header is telling you, and how [skip ci] ends up on your commit messages.

Publication

Mon, 01 Jan 0001 00:00:00 +0000

By default, every save in Emet is a commit to the branch you’re editing, and if that branch is the one your site deploys from, the change is live as soon as the build finishes. For a personal blog that’s fine. For a site with more than one editor, or one where someone needs to sign off before things go public, it’s a bit terrifying.

The publication workflow adds a step. You edit on a working branch, and when you’re ready, Emet opens a pull request to a production branch and lets you merge it once the checks pass. Your deploy pipeline watches production and nothing goes live until that merge.

Reviewing entries

Mon, 01 Jan 0001 00:00:00 +0000

The publication workflow reviews a whole branch at once: one pull request, one approval, everything goes live together. That’s fine until your team wants to sign off on pages one at a time – legal reads the pricing page, the editor reads the blog post, and nobody wants to approve a diff full of other people’s work.

Entry review handles that case. Each entry carries its own review state, a reviewer reads and approves it in Emet, and the publish dialog won’t let anything go live until every changed entry has been approved.