This website

Symptom. Pick a theme, refresh — the page paints in the default cyberpunk palette for ~80 ms, then swaps to the saved one. The matrix rain appears in the wrong colour for a single frame.

Cause. The dashboard (which sets data-theme) is a defer'd script, so it runs after the stylesheet. The stylesheet already contains all four palettes, but the saved one isn't applied until the script parses.

Fix. A tiny inline synchronous script in extend_head.html reads localStorage.getItem('lt.theme') and sets documentElement.setAttribute('data-theme', …) before the stylesheet loads. Runs in one statement, no conditionals on the dashboard.

(function () {
  try {
    var t = localStorage.getItem('lt.theme');
    if (t && t !== 'cyberpunk') {
      document.documentElement.setAttribute('data-theme', t);
    }
  } catch (e) { /* localStorage blocked */ }
})();

First attempt. Just changed three primary colours. Result: every theme looked like the default cyberpunk with a different accent.

Lesson. A theme is not a hue. It's a palette — background, surface, border, glow, text-primary, text-secondary, and the three accent colours all have to shift together, or the page looks like a colour-swap demo.

Fix. Every theme in custom.css defines the full 17-token set: --neon-blue/orange/purple/green, --cyber-bg/bg-2/bg-3, --cyber-surface/border/glow/glow-strong, --text-primary/secondary, and the PaperMod passthrough tokens (--theme, --entry, --primary, --secondary, …). Solarized is a light theme — neon values become ink. Terminal swaps the whole palette to amber-on-black.

Symptom. Solarized painted correctly on the dashboard panel but reverted to cyberpunk on the rest of the page.

Cause. The plain :root { … } fallback in custom.css had the same specificity as the :root[data-theme="solarized"] block, and the cascaded order meant the fallback won.

Fix. The themed blocks now use :root[data-theme="X"], which is more specific than a bare :root. The fallback :root block only applies when no data-theme attribute is set at all — i.e. on pages that haven't loaded the dashboard yet, and on the initial FOUC frame.

Symptom. Right after moving the script tags into extend_head.html, the home page loaded matrix.js and theme-dashboard.js twice. Two rain canvases, two dashboard panels, LocalStorage thrashing between reads.

Cause. layouts/index.html had been carrying its own <script src="/js/matrix.js"> at the bottom for the original drop-in install. The extend_head.html partial was now also including the same scripts, so the home page got both.

Fix. The bottom-of-page script tags were deleted from layouts/index.html. Scripts now load exactly once across every page, verified by grep -c 'js/matrix.js' public/index.html returning 1.

Symptom. The default speed was 1 row/frame, which felt like a video at 2× speed. The whole canvas flashed past unreadable.

Cause. Most demos use integer speed. At 60 fps, "1 row/frame" is 60 rows/second — too fast for the binary glyphs the user actually wanted to read.

Fix. matrix.js now uses a fractional accumulator:

speedAcc += speed;
var step = Math.floor(speedAcc);
if (step < 1) step = 1;
speedAcc -= step;

The slider goes from 0.2× to 3×. At 0.2× the rain is contemplative; at 3× it's a flicker. The default of 1× feels like a calm downpour.

Symptom. First user test: "Where do I change the theme?" Nobody clicked the ⚙ because they didn't know what it was.

Fix. Three changes layered on top of each other:

• The header now carries a visible hint strip — T toggle, [/] speed, −/= opacity — formatted as <kbd> badges.
• The toggle button's title attribute says "Open design dashboard (press T)" so hover reveals the shortcut.
• The keyboard shortcuts actually work — pressing T while the dashboard is closed opens it; pressing it again closes it.

Symptom. Click any internal link from localhost or fahimimam.sytes.net and the browser bounced the visitor over to fahimimam.pro.bd. The address bar was effectively a redirect button: arrive anywhere, click anywhere, end up on the production host.

Cause. Hugo's baseURL is set to http://fahimimam.pro.bd/ at build time. PaperMod's templates use absURL and absLangURL for nav, logo, menu, breadcrumbs, and favicon links — both prepend the baseURL, so every rendered href is fully qualified against the production host. The build is host-locked.

Why this was bad. Two domains point at the site. Forcing both into one URL collapses them: a visitor who arrived on sytes.net gets silently teleported to pro.bd on the first click, and back-button behavior turns into an infinite redirect loop.

Fix. Hugo's layout override system lets a file in layouts/partials/ shadow the matching partial under themes/PaperMod/. I copied four partials and swapped every internal absURL / absLangURL for relURL / relLangURL, and every internal Permalink for RelPermalink:

layouts/partials/header.html       # logo + main menu
layouts/partials/head.html         # favicon + apple-touch + mask
layouts/partials/footer.html       # copyright link
layouts/partials/breadcrumbs.html  # home + intermediate crumbs

Plus two hand-written pages — the landing hero's CTA buttons and the CV viewer's PDF link — were using hardcoded href="/projects/" etc., which on a static build work correctly with relative URLs but I'd written them with absolute paths. Swapped for relURL / relLangURL for consistency.

What stayed absolute (intentionally). <link rel="canonical">, RSS / JSON feed links, OpenGraph / Twitter card tags, JSON-LD @id and url, and the live lunch-tracker demo URLs all stayed absolute. Search engines dedupe via canonical, feed readers need absolute URLs, and the OpenGraph spec requires them — making those relative would break every external consumer.

Verification. After the rebuild, grep 'href="http' against public/ returned matches only inside index.xml (RSS feeds), the lunch-tracker showcase's https://fahimimam.sytes.net/api/... demo links, and the JSON-LD / OG blocks. No navigation link is absolute anymore.