Emet CMS

Block shortcodes

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

A block shortcode is one you’ve described in site.yaml: its name, the parameters it takes and, optionally, what it should look like in the preview. In the visual editor it shows up as a card with a form, so whoever is writing doesn’t need to remember the parameter names or the quoting rules. In the file it’s the same {{< name >}} text Hugo has always read.

Configuration#

Define them under shortcodes:

Cloudflare Pages

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

Cloudflare Pages is where Emet is designed to be deployed. The repository’s functions/ directory is a set of Pages Functions, so the OAuth token exchange that sign-in depends on gets deployed alongside the static files without any extra setup. Hosting is free at the scale a CMS runs at, and you get HTTPS and a *.pages.dev hostname out of the box.

There are two ways to get the build onto Pages: push it yourself with wrangler, or connect the repository and let Cloudflare build it on every push. The first is quicker to try; the second is nicer to live with.

CSS preview

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

The CSS preview renders your Markdown in the browser (with the same remark and rehype pipeline the visual editor uses) and puts the result in a sandboxed frame, where it can be styled with your site’s actual stylesheets. You don’t get Hugo’s layouts, but you do get your fonts, colours and spacing, which is most of what matters while you’re writing. It updates half a second after you stop typing.

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.

GitHub App

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

Emet needs a GitHub token to read and write your repository. The quick way to get one is a personal access token, and Emet still accepts those, but asking every editor to generate a PAT with the right scopes is a faff and they expire at awkward moments. A GitHub App gives you a Sign in with GitHub button instead, with short-lived tokens that Emet refreshes itself.

Under the hood this is the OAuth authorization code flow with PKCE. The browser sends people to GitHub, GitHub sends them back with a code, and a Pages Function at /api/github/token swaps the code for a token, adding the app’s client secret on the way. The secret never reaches the browser.

Installation

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

There are no prebuilt downloads of the desktop app at the moment, so installing it means building it from the repository. The build is driven by electron-vite, and packaging into an installer by electron-builder; both are already in devDependencies, so there’s nothing to install beyond npm install.

What you’ll need#

Node.js 22.12 or later, with npm.
Hugo on your PATH, if you want the live preview. The app runs without it; you just won’t get the Hugo server.
A Hugo site with an admin/site.yaml in it (admin/cms.yaml is optional, as everywhere else). If yours doesn’t have one yet, running the web dev server against it once (HUGO_ROOT=/path/to/site npm run dev, see Installation) writes both files.

Running from source#

Clone and install as for the web version, then start Electron in development mode:

Introduction

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

Emet is a CMS for Hugo sites that runs entirely in your browser. There’s no application server and no database: you log in with GitHub, pick a repository, and Emet reads and writes your Markdown files through GitHub’s API. Your site repository stays the single source of truth for your content, which is where it should be.

Think of it as an alternate, Hugo-aware frontend for GitHub.

Why this exists#

Static sites are great right up until someone who isn’t you needs to edit one. Hugo’s answer to “add a post” is hugo new and a text editor, which is fine for me and useless for most other people. The usual fix is a headless CMS, which means a hosted service, a database and another thing that can go down. I wanted the editing experience without the extra infrastructure, so Emet treats the Git repository as the database and GitHub as the backend.

Local development

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

Developing Emet means running the Vite dev server against a Hugo site. Most of the time that’s a site on your disk, with no GitHub involved at all; when you’re working on something GitHub-specific there’s a mode for that too. This page covers both, plus the full list of npm scripts.

What you’ll need#

Node.js 22.12 or later, with npm.
A Hugo site to point at. Any site will do, though one with a few sections, some shortcodes and a theme will exercise more of the code. If you don’t have one, Emet will fall back to some built-in demo content.

Getting it running#

git clone https://github.com/dmyates/emetcms.git
cd emetcms
npm install
HUGO_ROOT=/path/to/your/hugo/site npm run dev

Open http://localhost:5173 and you should see the site’s sections in the sidebar. There’s no sign-in; the dev server signs you in as a made-up “Development User” and goes straight to the editor. If the site has no admin/site.yaml, the dev server scans it and writes one (plus admin/cms.yaml) first, so the very first load can take a second longer.

Providers

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

Emet speaks to four kinds of provider: OpenAI, Anthropic, Google Gemini and anything with an OpenAI-compatible API (Ollama, LM Studio, Groq, vLLM and so on). You configure them in admin/cms.yaml, and each person using the CMS either uses a key you’ve put in that file or adds their own in the AI Settings modal.

Turning AI on#

AI is off until cms.yaml has an ai: block. The shortest one that works is:

Rules

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

The SEO panel runs 26 rules. This page lists each one with what it checks, where the thresholds sit and how much it’s worth. The thresholds are hard-coded; the only things you can change are whether a rule runs and how much it weighs.

Rules come in two flavours. Most are pass or fail: you get the full weight or nothing. A few are graduated, awarding a percentage of the weight depending on how close you are, and those are marked below. A rule that can’t be evaluated at all (no images for the alt-text rule, no sentences for readability) drops out of the score rather than counting against you.

Site config

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

admin/site.yaml describes your site to Emet: where the content is, what fields each kind of entry has, which shortcodes exist, where uploaded images go and which branches matter. It’s the file the setup wizard writes, and the one you’ll edit most as the site changes shape.

Everything in here is about the site rather than about how you like to work; preferences live in cms.yaml. Note that Emet only reads particular keys from each file, so editor settings in site.yaml do nothing, and neither do preview.styles in cms.yaml.

String

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

String fields now live on the main Fields page under the String section.

Supported settings

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

The visual mode of the Hugo Config tab doesn’t know what any particular Hugo setting means. It takes whatever keys are in your config, works out a control for each from the value’s type, and files them into sections. This page is about where things end up and what you can and can’t do with them there.

Sections#

Section	Keys shown	Open by default
Site Settings	`baseURL`, `title`, `languageCode`, `theme`, `copyright`, `paginate`, `enableRobotsTXT`, `enableGitInfo`	Yes
Build Settings	`buildDrafts`, `buildFuture`, `buildExpired`	No
Site Parameters	Everything under `params`	Yes
Permalinks	`permalinks`	No
Menus	`menu`	No
Markup	`markup`	No
Languages	`languages`	No
Other Settings	Recognised top-level keys that have no section of their own: `defaultContentLanguage`, `disableKinds`, `summaryLength`, `uglyURLs`, `sitemap`, `minify`, `imaging`, `privacy`, `security`, `services`, `frontmatter`, `caches`, `related`, `mediaTypes`, `outputFormats`, `deployment` and the rest of Hugo’s documented root keys	No

Sections other than the first three only appear when the config has something in them, and only those three have an Add field button. To add a top-level key elsewhere, or a new nested block, use raw mode.

Translation workflow

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

A translation in Emet is an ordinary entry that happens to live in another language’s directory. There’s no special translation state and nothing to approve; the workflow is just a quicker way of getting a correctly placed copy to start from, with the original beside you while you work.

Creating a translation#

In the entry list, open the card’s More actions menu (the three dots) and click Translate. The action only appears on sites with more than one language.
In the Create Translation dialog, pick the Target Language. The dropdown lists only languages this entry doesn’t have a translation in yet; if it has them all, the dialog says so and there’s nothing to do.
Choose what to Start from:
- Copy of source (the default) duplicates the whole source file, frontmatter and body, so you translate in place with the original text in front of you.
- Blank from archetype gives you a fresh entry from the section’s archetype (the same template a new entry gets), keeping only the source’s title and its translationKey if it has one. Pick this when the body is going to be rewritten rather than translated line by line.
Leave Open side-by-side with source ticked if you want the original visible while you translate. It’s on by default.
Click Start Translation.

The translation goes to the same relative path under the target language’s directory, so content/en/posts/hello.md becomes content/fr/posts/hello.md. The whole path below the language directory is kept, subfolders and page bundles included: content/en/posts/2024/hello.md becomes content/fr/posts/2024/hello.md, and a bundle’s content/en/posts/hello/index.md becomes content/fr/posts/hello/index.md. On a site using translation by filename the copy stays in the same directory and gets the target language’s suffix instead: content/posts/hello.md becomes content/posts/hello.fr.md, and content/posts/hello/index.de.md translated into the default language becomes content/posts/hello/index.md.

Visual mode

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

The visual editor is a WYSIWYG editor built on Tiptap, which is a wrapper around ProseMirror. You write, you click buttons, you see formatted text. Under the hood, Emet converts what you see to Markdown on save and back again on load, so the file in your repository is plain Markdown that you could equally well edit in Vim.

That round trip is the interesting part. Most WYSIWYG editors that claim to produce Markdown either produce HTML with a Markdown veneer, or lose things. Emet’s converter knows about GFM tables, task lists, footnotes, definition lists and Hugo shortcodes, and preserves them as the Markdown constructs they are. There are a few things Markdown has no syntax for, covered at the end of this page.

AI chat

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

The chat panel lives in the AI tab of the editor’s right column, alongside SEO and Comments. It appears whenever ai.enabled is true in cms.yaml. It’s a conversation with the model about the entry you have open, and, unlike a chat window in another tab, it can act on what it says: change the frontmatter, rewrite a paragraph, search your other posts, generate an image.

The panel#

The header shows a status dot and the active provider and model, in the form gemini · gemini-3.5-flash. Green means a provider is ready, pulsing yellow means it’s thinking and grey means there’s no key yet, with an Open settings link that takes you to the key form. The cog on the right opens the same AI Settings modal.

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.

CMS config

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

admin/cms.yaml is optional. It holds the settings that are about how Emet behaves rather than how your site is built: which editor opens by default, what the link dialog offers, which SEO rules count, the AI providers, whether entries need review and where the local Hugo server is. Delete the file and everything falls back to defaults, with one exception: AI features are off entirely until this file has an ai: block.

Google Search Console

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

The SEO panel can tell you whether a post ticks the boxes, but not whether anyone’s finding it. Search Console can. With this integration connected, the bottom of the SEO tab shows the page’s clicks, impressions, average click-through rate and average position for the last 28 days, and a table of the queries that brought people there, so you can see which words are already working before you decide what to optimise.

Inline shortcodes

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

Hugo’s inline shortcodes let you write a shortcode’s template inside the content file that uses it, instead of in layouts/shortcodes/. They’re handy for one-off formatting that doesn’t deserve a layout file, and Emet supports them without any configuration, because everything it needs is in the page. (Hugo needs enableInlineShortcodes = true in its config before it will render them.)

How Hugo writes them#

An inline shortcode has a name ending in .inline. The first time it appears it carries its template between opening and closing tags; after that you can reuse it by name:

Installation

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

Emet is a Vite project. Installing it means cloning the repository and running npm install; there’s nothing to scaffold and no database to set up.

What you’ll need#

Node.js 22.12 or later, with npm.
A Hugo site to point it at. For local development this can be any folder on disk; for a deployed CMS it needs to be a GitHub repository.
For a deployed CMS, a GitHub App so people can sign in. You don’t need this to run Emet locally, so skip it for now and come back to GitHub App setup when you’re ready to deploy.

Cloning and installing#

git clone https://github.com/dmyates/emetcms.git
cd emetcms
npm install

That’s the whole install.

Local Hugo server

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

The CSS-based preview in the browser is a reconstruction of what Hugo would render, and for anything beyond plain Markdown it’s a guess. The desktop app can do better because it has a real filesystem and, if you’ve installed it, a real Hugo. It starts hugo server for the site you’ve opened and shows the actual rendered page in the preview pane, with Hugo’s live reload rebuilding it every time you save.

Markdown mode

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

The Markdown editor shows you the file as it is: frontmatter aside, exactly the text Hugo will read. It’s built on CodeMirror 6, so you get syntax highlighting, search, folding, multiple cursors and, if you want it, Vim. You’ll want it for anything the visual editor can’t express cleanly, raw HTML mostly, and for the days when you’d rather just type.

Switching modes#

The Markdown button at the far right of the visual editor’s toolbar brings you here; the Visual button at the far right of this one takes you back. Emet remembers your choice. The editor.default_mode setting in cms.yaml only decides which mode you see before you’ve made that choice; see Visual mode.

Social previews

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

When someone pastes a link to your post into LinkedIn or a group chat, the platform fetches the page and builds a card from its Open Graph tags: title, description, image. You usually find out what that card looks like after you’ve shared it, which is the wrong way round. The Social Preview section of the SEO panel shows you the card before you publish.

What you see#

Expand Social Preview in the SEO tab and you get a tab strip for LinkedIn, X/Twitter and Facebook, a mock-up of the card, and character counters underneath. The mock-ups follow each platform’s current layout:

Template interpolation

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

An inline shortcode carries its Go template in the page, so the preview pane has the template right there. It can’t run it, since there’s no Hugo in the browser, but it can do the next best thing: find the places where the template reads its parameters, drop the values in and throw away whatever’s left. This page is about how far that gets you.

It only applies to inline shortcodes. Block shortcodes use the {{field}} preview templates from site.yaml, and Emet never reads your layouts/shortcodes/*.html files in the preview.

Testing

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

Emet’s tests run on Vitest, with jsdom standing in for the browser and Testing Library for anything that renders. There are a little over a hundred test files, sitting next to the code they test, and they cover most of the subsystems: frontmatter parsing, slugs and filenames, config loading and defaults, the sync service, shortcode and table serialisation, the SEO rules, the Hugo config parser, the AI client and providers, the GitHub client and pull request helpers and a fair few hooks and components.

Text

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

Text fields now live on the main Fields page under the Text section.

Architecture

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

Emet is a React and TypeScript single-page app, built with Vite, that treats a Git repository as its database. This page is a tour of how that works: the backends that read and write content, how a running copy decides which one it’s using, where configuration comes from, how state is kept and what the build produces. It’s meant to be read before you go poking around in src/.

Why there’s no backend#

The design decision everything else follows from is that Emet has no application server. The site repository already holds the content, Git already keeps the history, and GitHub already has an API for reading and writing files, opening pull requests and checking CI. Putting a server and a database in front of that would mean a second copy of the content, a sync problem between the two and another thing to host and keep patched. I didn’t want any of those, so the browser talks to GitHub directly and the repository stays the single source of truth.

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.

Hugo server preview

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

The CSS preview is a good approximation, but it’s still an approximation: no layouts, no partials, and shortcodes rendered from stand-in templates. If Hugo is installed on the machine Emet is running on, you can skip all that and look at the real page. Emet loads it from a hugo server in the preview pane, and Hugo’s live reload keeps it current.

This needs Hugo on the same machine as Emet, so it’s only available in two situations:

Inline actions

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

Most of the time you don’t want a conversation; you want this sentence to be shorter. Inline actions are the one-click version of AI: select some text in the visual editor, pick an action, and the selection is replaced with the result. No chat, no confirmation, and Ctrl+Z if you don’t like it.

They only exist in the visual editor. In Markdown mode you’ll want the chat panel instead.

Select some text. The small floating toolbar that appears above it has an AI button on the right, as long as a provider is configured and ready. Click it, or press Ctrl+J (Cmd+J on a Mac), and the actions menu opens below the selection. The shortcut is ai.shortcuts.inlineAction in cms.yaml if you want a different one.

Keyboard shortcuts

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

Every binding Emet responds to, in one place. Ctrl means Cmd on a Mac unless a table says otherwise. Most of the visual editor’s bindings are Tiptap’s defaults and most of the Markdown editor’s are CodeMirror’s, so if you’ve used either before, your fingers already know a lot of this.

Everywhere#

Shortcut	Action
`Ctrl+S`	Save the open entry (does nothing if there’s nothing to save)
`Ctrl+.`	Toggle focus mode (needs an entry open)
`Esc`	Leave focus mode, unless a dialog is open
`Ctrl+F`	Jump to the entry list filter, when you’re not inside an editor
`Ctrl+K`	Search every section by title or body text, when you’re not inside an editor

Note that Esc leaving focus mode includes the Esc you press to get out of insert mode in Vim, so in focus mode you’ll want jj instead.

Markdown

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

Markdown fields now live on the main Fields page under the Markdown section.

Preview templates

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

A shortcode card in the editor tells you what the parameters are, not what the result looks like. The preview pane is where that happens, and the preview property on a block shortcode is the HTML it uses. Emet can’t run your Hugo templates in the browser, so you give it a simplified stand-in with the field values dropped in.

This mostly affects the preview pane. A block card in the visual editor never renders it; the one place it shows up in the editor is the label on a chip for a shortcode sitting inside a sentence.

Sections

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

A section is a folder of content whose entries share a set of frontmatter fields: posts, pages, projects, docs. The sections block of site.yaml is where you tell Emet which folders those are and what the form for each one should look like. The sidebar lists the sections, the entry list shows what’s in the one you pick, and the frontmatter panel is built from its fields.

A section#

sections:
  blog:
    label: Blog posts
    label_singular: Blog post
    folder: content/blog
    slug: "{{year}}/{{slug}}"
    fields:
      - name: title
        type: string
        required: true
      - name: date
        type: datetime
      - name: tags
        type: list
    body:
      shortcodes: true

The key (blog here) identifies the section. It’s also the default folder and label, so blog: {} is a valid section: Emet will look in content/blog, call it “blog” and show no configured fields. You’d still be able to edit entries, because frontmatter keys that aren’t in the config are shown anyway (see Entries), but you’d lose the type-appropriate widgets.

Self-hosting

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

You can serve Emet’s dist/ directory from Netlify, Vercel, GitHub Pages, nginx or anywhere else that serves files. The static part is genuinely that simple. What those platforms don’t run is the OAuth token exchange in functions/, and without it nobody can sign in. So this page is mostly about that one endpoint, and only briefly about the hosting.

If you haven’t read Deployment for why the endpoint exists, do that first.

Setup wizard

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

Emet needs an admin/site.yaml in your repository before it can show you anything, and writing one by hand for a site with a dozen sections is tedious. The setup wizard does it for you: it scans the repository, guesses sections, fields and shortcodes from what’s already there, and commits the result.

When it runs#

The wizard appears when you’ve signed in, picked a repository and branch, and Emet can’t find admin/site.yaml on that branch (or <base_path>/admin/site.yaml if your site is in a subdirectory). There’s no button for it anywhere; it only triggers on a missing config.

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:

Number

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

Number fields now live on the main Fields page under the Number section.

Page builder

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

The page builder is for the blank-page problem. You describe a page (“a landing page for the new pricing tiers, with a comparison table and an FAQ”) and the model drafts the whole thing: YAML frontmatter that matches your section’s fields and a Markdown body that uses your shortcodes. You review it, tweak it and apply it to the editor.

It’s a draft, not a finished page. The useful part is that it knows your site’s vocabulary.

Quick start

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

This page goes from a fresh clone to editing a Hugo site, first locally and then through GitHub. If you only want to try Emet out, the local part is enough and takes about two minutes.

Editing a local site#

Clone and install:

git clone https://github.com/dmyates/emetcms.git
cd emetcms
npm install

Then start the dev server with HUGO_ROOT pointing at your Hugo site:

HUGO_ROOT=/path/to/your/hugo/site npm run dev

Open http://localhost:5173. There’s no login in this mode. The sidebar lists your content sections, and clicking an entry opens it with its frontmatter as a form above the body. Edit something and press Save; the file on disk changes and nothing else happens. If you have hugo server running in another terminal, the preview pane can show you the real rendered page.

Boolean

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

Boolean fields now live on the main Fields page under the Boolean section.

Image generation

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

Every post wants a header image and most of us don’t have one. The image generator takes a prompt, gets an image back from OpenAI or Gemini, uploads it to your media folder and drops it into the body or a frontmatter image field. There’s also an Edit with AI route for images you already have.

It needs a provider that can make images, which means OpenAI (gpt-image-2) or Gemini (gemini-3-pro-image-preview or gemini-2.5-flash-image). Anthropic can’t, and custom endpoints are never asked to. If your current provider is the wrong one, the modal says so and points you at AI Settings.

Media

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

The media block says where uploaded files go in the repository and what URL they’ll have on the site. Everything that puts a file in your repository uses it: the media library, images pasted or dropped into the editor, image fields and AI-generated images.

media:
  folder: static/images
  public_path: /images
  max_size_mb: 10
  accept:
    - image/png
    - image/jpeg
    - image/webp
    - image/gif
    - image/svg+xml

Key	What it does	Default
`folder`	Where uploads are committed, relative to the Hugo root. Prefixed with `base_path` if you have one.	`static/images`
`public_path`	The URL prefix for those files on the built site. This is what gets written into your Markdown and frontmatter.	`/images`
`max_size_mb`	Upload size limit in megabytes.	`10`
`accept`	Which files are allowed.	the five image types above

The whole block is optional, as is each key in it.

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.

Data browsing

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

Hugo’s data/ directory doesn’t need any configuration. There’s always a Data entry at the bottom of the sidebar, and it browses every .json, .yaml, .yml and .toml file under data/, nested folders included. You can create files and folders from there too, even if the directory doesn’t exist yet. New files default to YAML, with JSON and TOML a click away.

If you’ve set base_path, the browser uses that site’s data/ directory (docs/data/ for a site in docs/) and won’t let you wander outside it.

Datetime

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

Datetime fields now live on the main Fields page under the Datetime section.

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.

Translation

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

Emet’s translation workflow is built around copies: Translate on an entry card starts a translation from a copy of the source (or a blank archetype), and Create translations copies entries in bulk, each in the right place for a human to translate. No AI is involved in either.

The AI side is two separate things. You can translate a selection in place from the inline actions menu, and you can translate a whole entry, frontmatter and body, from the toolbar. Both need at least two languages in site.yaml and a provider that’s ready.

Date

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

Date fields now live on the main Fields page under the Date section.

Languages

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

Hugo does multilingual sites either by giving each language its own content directory (content/en and content/de, or content for the default language and content.de for the other) or by keeping every language in one directory and putting the language code in the filename (post.md, post.de.md). Emet needs the same mapping so it can switch between them, find an entry’s translations and work out URLs.

languages:
  - code: en
    name: English
    contentDir: content/en
    default: true
  - code: de
    name: Deutsch
    contentDir: content/de

Key	What it does
`code`	The language code, as in your Hugo config.
`name`	What the language switcher calls it.
`contentDir`	That language’s content directory, relative to the Hugo root.
`default`	`true` on exactly one language. If none is marked, the first in the list is the default.

Leave the block out and Emet assumes a single language, en, in content. The language switcher only appears once there are two or more.

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.

Environment variables

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

Everything about your site is in admin/site.yaml and admin/cms.yaml. Environment variables are for the things that belong to a deployment of Emet rather than to a site: which GitHub App it signs in with, where its API proxy is, and the secrets that proxy needs.

There are two kinds. Build-time variables are read by Vite and baked into the JavaScript bundle, so changing one means rebuilding. Runtime variables are read by the Cloudflare Pages Functions on each request, never reach the browser, and can be changed without a rebuild. Secrets go in the second group.

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.

Select

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

Select fields now live on the main Fields page under the Select section.

List

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

List fields now live on the main Fields page under the List section.

Object

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

Object fields now live on the main Fields page under the Object section.

Relation

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

Relation fields now live on the main Fields page under the Relation section.

Image

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

Image fields now live on the main Fields page under the Image section.

File

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

File fields now live on the main Fields page under the File section.

Code

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

Code fields now live on the main Fields page under the Code section.

Colour

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

Color fields now live on the main Fields page under the Color section.

Hidden

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

Hidden fields now live on the main Fields page under the Hidden section.

Emet CMS

Block shortcodes

Configuration#

Cloudflare Pages

CSS preview

Entries

GitHub App

Installation

What you’ll need#

Running from source#

Introduction

Why this exists#

Local development

What you’ll need#

Getting it running#

Providers

Turning AI on#

Rules

Site config

String

Supported settings

Sections#

Translation workflow

Creating a translation#

Visual mode

AI chat

The panel#

Bulk actions

CMS config

Google Search Console

Inline shortcodes

How Hugo writes them#

Installation

What you’ll need#

Cloning and installing#

Local Hugo server

Markdown mode

Switching modes#

Social previews

What you see#

Template interpolation

Testing

Text

Architecture

Why there’s no backend#

Data files

Hugo server preview

Inline actions

Opening the menu#

Keyboard shortcuts

Everywhere#

Markdown

Preview templates

Sections

A section#

Self-hosting

Setup wizard

When it runs#

Archetypes

Which archetype applies#

Number

Page builder

Quick start

Editing a local site#

Boolean

Image generation

Media

Media library

Data browsing

Datetime

Sync

Translation

Date

Languages

Publication

Environment variables

Reviewing entries

Select

List

Object