Glossary

Glossary

One word for each idea, used the same way in conversation, code, documents and the control panel. This page is Rule 11 written down.

• Client word: what clients see, when it differs.
• Not: words we avoid for this idea, so they do not creep back in.
• In code: the name in the code, where there is one.

A new term goes here before it is used. If you find two words for one idea, pick one here and change the other.

Sections: The product · Content · Publishing · People and signing in · Hosting and tools · Building the code

The product

Astro site rules

The rules a client's Astro site follows from its first day, so Slim Killer can be added after the client approves the website without rework. See Astro site rules.

• Not: site contract, site standard, the bible (fine in conversation)

Client site

One client's website project: their Astro site, theme, modules and content, in their own Git repository. It uses core.

• Client word: your website
• Not: instance, theme, install

Control panel

The part of a client site where people sign in and edit: /cp on the client's own domain.

• Client word: control panel
• Not: admin, back end, dashboard (the dashboard is one page of it), CMS
• In code: src/Http/ControlPanel/, the /cp address

Core

This repository: the control panel, hammer and everything every client site shares. Released as tagged versions.

• Not: framework, engine, platform

Dashboard

The first page of the control panel after signing in.

• Client word: dashboard

hammer

The command-line tool: php hammer <command>. A hammer, not an artisan.

• Not: artisan, CLI (fine as a description, not as its name)
• In code: hammer, src/Console/

Slim Killer

The product: Astro websites that clients edit in a small PHP control panel, on ordinary shared hosting.

• Not: Slim Edge (its old working name)

Tier

The three ways Slim Killer is sold: Edge Static (no control panel), Edge Blog (control panel) and Edge Storefront (control panel and a shop).

Content

Body

The Markdown text of an entry, below the front matter.

• Client word: text
• Not: content (too broad)

Building block

A shape of content that every client site uses the same way: an image, a link, a section, a quote, a call to action, a gallery, a card, and the page's search details. @monatemedia/slim-killer-astro gives each one's schema; each site's components decide how it looks. See Field names and building blocks.

• Client word: none; clients see the block's own name, for example "Section"
• Not: component (that is the code that draws it), widget, module
• In code: image(), link(), seo(), card(), quote(), cta(), section(), gallery()

Collection

A group of content files of one kind, with one schema: articles, packages, destinations.

• Client word: the collection's own name, for example "Articles"
• Not: post type, content type, table

Content

The words and images of a site: Markdown files and images in the client site's repository. Core updates never touch it.

• Client word: content

Editor hint

A note on a schema field, added with Zod's .meta(), that tells the control panel how to show it: a label (title), help text (description) and which editor to use (input: text, textarea, markdown or image).

• Not: annotation, widget

Entry

One file in a collection: one article, one package.

• Client word: page, or the collection's own word ("article")
• Not: post, record, document

Front matter

The fields at the top of a content file, between the two --- lines: title, description, images.

• Client word: the form's fields; clients never see the words "front matter"
• Not: metadata, header, YAML header
• In code: FrontMatter (spike S4)

Graphic

An image that is already optimised: a map, flag, logo, diagram or SVG. Kept in content/graphics/ and copied into the site exactly as it is, never compressed. See Astro site rules, rule 3.

• Not: icon (unless it is one), asset, illustration

List page

A page that lists the entries of a collection, such as /articles/. Its own text (heading, introduction, banner) is in content/<collection>-list/index.md.

• Client word: the page's name, for example "Articles list"
• Not: index page, archive, overview

Photo

An image the site compresses when it is built. Kept in content/images/.

• Client word: photo, image
• Not: picture, media, upload

Schema

The definition of a collection's fields, in the client site's content.config.ts. The single source of truth for every editing form.

• Not: model, blueprint, field definition (in the control panel)

Web address

The last part of a page's address on the site (/destinations/namibia/). It comes from the entry's file or folder name. The panel shows it but does not change it: a new address breaks links, so changing it is the developer's job.

• Client word: Web address
• Not: URL, permalink, slug (to clients)
• In code: slug

Publishing

Build

GitHub Actions turning the client site into finished web pages (astro build), published to the dist branch.

• Client word: Publishing (the "Building" stage)
• Not: compile, generate

Commit

One recorded change in Git. One save makes one commit, with its text and images together.

• Client word: (not shown; clients see Save)

Conflict

Someone else saved the same page after this person opened it. Nothing is written: the form keeps what she typed, and the panel fetches the newer version, so Discard changes shows it.

• Client word: "Someone saved this page after you opened it"
• Not: clash, merge conflict, collision
• In code: SaveResult::conflict()

dist branch

The branch in a client site's repository that holds only the finished build. The host fetches from it.

• In code: dist

Fetch

The host downloading a finished build from GitHub and unpacking it into a new release. Started by the webhook; cron checks for a missed one every few minutes.

• Client word: Publishing (the "Going live" stage)
• Not: deploy, pull (used for the principle "the host pulls"), sync, download
• In code: hammer deploy:fetch (planned)

Live

What the public sees now.

• Client word: Live
• Not: production (to clients), published

Publish

The client's word for the whole path from Save to Live: build, fetch, switch. The control panel shows the stages Saved, Building, Going live, Live, with a time estimate taken from the site's own recent publishes.

• Client word: Publish, Publishing…, Live
• Not: deploy (to clients)

Release

One finished build, unpacked into its own folder on the host. The site shows one release at a time; the previous one is kept for rollback.

• Client word: version (in "go back to the previous version")
• Not: deployment, snapshot

Rollback

Switching back to the previous release.

• Client word: Go back to the previous version
• Not: revert (that is a Git word for something else)

Save

What a person does in the control panel. For the system, a save is one commit to the client site's repository.

• Client word: Save
• Not: submit, update, commit (to clients)

Switch

Pointing the website at a new release, in one step, by rewriting one .htaccess file.

• Client word: Live
• Not: swap, flip, deploy

Webhook

A web address one system calls to tell another that something happened. GitHub calls the host's webhook when a new build is ready; the host then fetches the build itself and starts at once. Picture a doorbell: it announces, it never comes in. GitHub never pushes files onto the host.

• Client word: (not shown)
• Not: doorbell (except as the picture above), callback, ping, hook (on its own)
• In code: /cp/hooks/build-ready (planned)

Working copy

The host's copy of the client site's content, which the panel reads from. GitHub holds the real version; the panel updates its copy after each save, and after a conflict.

• Client word: none; clients never see it
• Not: cache, local copy, checkout
• In code: ContentRepository

People and signing in

Administrator

Monate Media: a person who looks after the site, updates and recovery.

• Client word: administrator
• Not: admin (in text; fine in code), superuser
• In code: Role::Admin

Audit log

The record of sign-ins, failed sign-ins, password and two-factor changes, and resets.

• In code: AuditLog

Authenticator app

The phone app that shows the six-digit codes. We suggest Google Authenticator; any authenticator app works.

• Client word: authenticator app

Recovery code

One of eight single-use codes shown once when two-factor is set up. Signs in once instead of the six-digit code. Only hashes are stored.

• Client word: recovery code
• Not: backup code, emergency code
• In code: RecoveryCodes

Setup link

A private link to the setup page, printed by hammer doctor. Works for one hour.

• In code: SetupLink

Sign in

Proving who you are: email address and password, then a six-digit code.

• Client word: Sign in, Sign out
• Not: log in, login, log on
• In code: /cp/sign-in, /cp/sign-out, SignInAction, SignInThrottle

Site owner

The client: a person who edits their own site.

• Client word: site owner
• In code: Role::Owner

Two-factor

The second step of signing in: a six-digit code from an authenticator app, or a recovery code. Required for everyone.

• Client word: two-factor sign-in, six-digit code
• Not: 2FA, MFA, OTP (in text for clients)
• In code: Totp

Welcome link

A single-use link, valid for 72 hours, that hammer install, user:create and user:reset print. The person opens it to choose their own password and set up two-factor.

• Client word: welcome link
• Not: invite, invitation, activation link
• In code: WelcomeLinks, the /cp/welcome address

Hosting and tools

Cron

The host's timer that runs a command every minute. Slim Killer uses it as a safety net and for scheduled jobs.

• Client word: scheduled task
• Not: scheduler, timer

Host

The server that serves a client site, usually shared hosting such as Hostinger.

• Client word: hosting
• Not: server (fine), box, VPS (a different thing)

Host check

One check that hammer doctor runs: PASS, WARN, FAIL or INFO.

• Not: health check, test
• In code: PhpCheck, HostCheck, Status

Quality gates

The checks that must pass before a branch is merged: Pint (code style), PHPStan (types) and Pest (tests). The branch scripts run them.

• Not: CI checks, linters

Sandbox

A throwaway copy of a client site used for spikes, so the real site is never touched.

Spike

A short experiment that answers one question and is then thrown away. Slim Killer's spikes S1 to S5 tested committing from PHP, fetching builds, reading Astro's schemas, editing files without changing them, and timing a save to live.

• Not: prototype (a prototype is kept), proof of concept

Building the code

Aggregate

Objects that must be correct together at the same instant, changed as one. See Rule 10.

Binding

A line in the container's definitions that says which implementation to use for an interface. A client site changes behaviour by changing a binding.

• Not: registration, provider

Ceremony

The extra structure domain modelling adds: value objects, aggregates, exception trees. Worth it only where the rules are hard. See Rule 7.

Container

The object that builds every other object and hands each one what it needs (PHP-DI).

• Not: service locator (the misuse to avoid), DI framework

Domain

The part of the code that holds business rules. In Slim Killer, mostly the publish pipeline and the shop. See Rule 7.

• Not: business logic layer, model layer

Entry point

Where a program starts and everything is wired together: hammer and the control panel's public/cp/index.php. See Rule 1.

• Not: bootstrap (that is the folder), main

Fake

A stand-in for the outside world in tests, such as a fake clock or a fake GitHub.

• Not: mock (a mock checks calls, which Rule 2 avoids), stub

Invariant

A rule that must always be true, such as "a release cannot go live before it is checked".

• Not: constraint, validation (validation is how you check one)

Value object

A small read-only object that is valid from the moment it exists, such as EmailAddress. See Rule 9.