An instance that can be somebody else's

A name, a tagline, a logo, a favicon and the launcher icons derived from it; the
Middle-earth strings as data; themes as token sets; and a stylesheet for what
none of that reaches. All four are on one page, in one settings group.

The snapshot is a Jinja global over a process-level cache, because render() has
no session and four render paths never reach it at all -- the sign-in page, the
error pages, the offline page and the SSE fragments. A context value would have
had to be threaded through every one and would still have missed those. It being
a global is also what lets mark() branch on an uploaded logo without any of its
six call sites learning about branding; the macro that renders the sidebar link
is called brandlink now, because a macro imported as `brand` shadows the global
for the whole template and took out every page at once.

Defaults in code and overrides in the database, as the prompt fragments do, with
one difference stated in the module: an empty fragment means off, an empty
flavour string means the shipped wording. And blanked rather than dropped --
settings_store.update merges, so an omitted key leaves what was stored last time
and "I typed the default back in" would store something different from "I changed
nothing".

A custom theme sets a handful of tokens and inherits the rest, and the
inheritance is a CSS fact: tokens.css matches [data-base="shire"] as well as
[data-theme="shire"], so a custom light theme lands on parchment rather than four
light colours on near-black. Values are validated on read rather than on save,
because a theme written straight into the settings table still has to produce a
stylesheet that parses -- a `}` in a value ends the rule and silently breaks
every rule after it. The soft variants are derived from the accent, or a changed
accent leaves focus rings in the old hue and reads as half-working.

/branding.css is a route, not an inline block: an external stylesheet has no HTML
context to escape from. The link carries a content hash, so a save is not left to
the browser's cache, and it is deliberately outside the service worker's precache
list, which is versioned by the release.

The instance name moved off /admin/general rather than being duplicated there.
An upgrade keeps it: the general row is read as a seed exactly while the branding
row has never mentioned the name, which is `key in row` and not `row[key] is
truthy` -- the two read alike would resurrect the old name underneath a cleared
one.

The theme list stops being a hard-coded pair in five places. Every failure mode
in that area is silent, so it is driven under a DOM stub as well as tested.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Jaroslav Beneš
2026-08-06 15:42:25 +02:00
parent 46066150d9
commit 78e5717f77
67 changed files with 1887 additions and 117 deletions
+41 -7
View File
@@ -9,19 +9,44 @@
"use strict";
var THEME_KEY = "lembas-theme";
var THEMES = ["moria", "shire"];
/* --- Theme -------------------------------------------------------------
Stored locally so the choice applies instantly and survives being signed
out, and mirrored to the server so it follows the user to another device.
The server call is best-effort: a failure must not undo the local switch. */
The server call is best-effort: a failure must not undo the local switch.
The list used to be a literal pair here, and in four other places. It comes
from `data-themes` on <html> now -- "id:base" pairs, space separated --
because an administrator can define one, and a hard-coded pair would refuse
it silently: applyTheme would return, the button would do nothing, and
nothing anywhere would say why. */
function themes() {
var raw = document.documentElement.dataset.themes || "moria:moria shire:shire";
var map = {};
raw.split(/\s+/).forEach(function (entry) {
var parts = entry.split(":");
if (parts[0]) map[parts[0]] = parts[1] || "moria";
});
return map;
}
function themeNames() {
return Object.keys(themes());
}
function currentTheme() {
return document.documentElement.dataset.theme || THEMES[0];
return document.documentElement.dataset.theme || themeNames()[0];
}
function applyTheme(name) {
if (THEMES.indexOf(name) === -1) return;
var known = themes();
if (!Object.prototype.hasOwnProperty.call(known, name)) return;
document.documentElement.dataset.theme = name;
/* Both attributes, always. `data-base` is what makes a custom theme inherit
its built-in palette -- tokens.css matches it as well as `data-theme` --
so setting only the first leaves a custom light theme's four colours on
Moria's near-black surfaces. */
document.documentElement.dataset.base = known[name];
try {
localStorage.setItem(THEME_KEY, name);
} catch (e) { /* private mode */ }
@@ -36,9 +61,13 @@
if (bg) meta.setAttribute("content", bg);
}
/* The toggle names where it is going, not where it is. With more than two
themes "the next one" is the honest description, because naming it would
mean carrying every label into the browser for a label nobody reads
twice. */
document.querySelectorAll("[data-theme-toggle]").forEach(function (el) {
el.setAttribute("aria-label", name === "moria" ? "Switch to Shire (light)"
: "Switch to Moria (dark)");
el.setAttribute("aria-label", known[name] === "moria" ? "Switch to the light theme"
: "Switch to the dark theme");
});
/* For anything holding colours as values rather than reading them from a
@@ -56,8 +85,13 @@
}
}
/* Round the list rather than between two names. With only the built-in pair
this is exactly what it always did; with a third defined it reaches it,
which a hard-coded flip never could. */
function toggleTheme() {
applyTheme(currentTheme() === "moria" ? "shire" : "moria");
var names = themeNames();
var at = names.indexOf(currentTheme());
applyTheme(names[(at + 1) % names.length] || names[0]);
}
/* --- Textarea autosize -------------------------------------------------