Built with Chinaski

Favicon

The site favicon is generated once, from a single uploaded source image, and deployed automatically with every build. Upload it under Settings (the favicon upload control); the app generates every size browsers and installable web apps expect.

Uploading

Settings’ favicon control accepts PNG, JPEG, SVG, or ICO files up to 5 MB. On save:

  • The source is size-checked (“roughly square” — an aspect ratio no wider than ~1.25:1, because scaling a wide wordmark into an icon produces an unusable sliver). Non-square uploads are rejected with a clear message rather than mangled.
  • A generated icon set is produced: favicon-96x96.png, apple-touch-icon.png (180×180), web-app-manifest-192x192.png, web-app-manifest-512x512.png, an SVG wrapper embedding the 96×96 rendering (favicon.svg), and a favicon.ico (taken verbatim when you uploaded an ICO, otherwise derived from the 96×96 PNG).
  • Files land in two places: the assets/ directory (the source of truth for the next static build) and public/ (so the CMS can serve them immediately).
  • The save triggers a rebuild, and the action is audited (“Favicon updated by ”).

Fresh installs ship a default set (the Chinaski mark), which the upload replaces.

Where the favicons appear

At build time, the full favicon set is copied to the site root of the output — not under any language prefix — and included in the signed build manifest. The standard _head.tt partial then emits the favicon <link> tags for enabled sites: favicon PNG, apple-touch-icon, and the .ico shortcut.

Removing it

The Settings favicon delete control removes the uploaded source and all derivatives from both directories, clears the setting, and triggers a rebuild — the restored state is the shipped defaults (or no favicon <head> links if the shipped defaults are absent).

Failure modes to know about

  • Where is the favicon not working? The generated set lives in assets/; if the static build happens elsewhere, a build-log entry tells you. favicon.svg generation failure is logged as a warning (non-fatal), while the PNG/ICO set is what the <head> references.
  • Root-owned leftovers: generated and copied files replace rather than modify — a stray root-owned favicon left behind by a deploy tooling action can’t wedge the save; the write path requires directory-level writability instead of file-level ownership.
  • If the process can’t write the assets directory at all, the flash error names the directory and points at ownership/permissions — that’s your fix, not retrying.