Add syntax highlighting on code blocks, plus a Code Highlighting post

Colors <pre><code> blocks site-wide via vendored highlight.js v11.11.1
(pinned to that stable tag, not main, which tracks an in-progress
11.0.0-beta1), auto-detected and restricted to
configure({ languages: ['php', 'bash', 'xml', 'css', 'python',
'javascript', 'yaml', 'json', 'ini'] }) - no per-block markup needed for
the ~60 existing code blocks across the site. css/python/javascript ship
in the core bundle; yaml/json/ini (ini covers .env-style files too)
don't and are vendored as separate per-language files.

Themes swap with the existing dark/light toggle: ir-black (dark) +
github (light, resolving the entry's own open question), via the same
data-theme-driven mechanism as the main palette
(syntax-highlight-init.twig/syntax-highlight.twig, mirroring
theme-init.twig/nav.twig's split) - a MutationObserver swaps the theme
link live without touching the existing toggle button's click handler.

Twig-syntax code blocks have no highlight.js grammar and are marked
class="nohighlight" by hand (15 blocks across 9 files, found by grepping
for literal {% %}/{{ }} syntax rather than guessing) rather than
force-matched into the restricted candidate set, which would color them
wrong instead of leaving them plain.

One correction to the original backlog entry's suggested approach: it
suggested vendoring highlight.js under novaconium/vendor/ next to Twig.
That would have silently 404ed on every request - Twig is server-side
PHP, never fetched by a browser, but highlight.js's .js/.css files are,
and only public/ is web-reachable. Vendored to public/vendor/highlightjs/
instead; documented in AGENTS.md and a new upgrading-highlightjs doc,
since public/ isn't touched by the usual novaconium/-swap framework
update workflow, so a future highlight.js bump won't propagate to
existing projects automatically the way it does for everything else
under novaconium/.

Caught two real bugs via testing rather than review: hljs.highlightAll()
silently no-ops if called before the document finishes parsing rather
than deferring itself, and a bash example starting with the word "php"
auto-detects as PHP, not bash.

Also adds App/pages/blog/code-highlighting/ - a new blog post
demonstrating the feature with a verified worked example in each of the
nine languages, plus how to force a language via an explicit
language-<name> class when auto-detection isn't enough.

Closes the "Syntax highlighting on code blocks" backlog item in
novaconium/ISSUES.md.

AGENTS.md

@@ -313,6 +313,45 @@ render it. A crawl is a full truncate-and-rebuild inside one transaction,
 not incremental — simple and correct at this site's scale; don't add
 incremental/diffing logic without a real need for it.
 
+**Standing rule: a vendored dependency's files go under `novaconium/vendor/`
+only if they're server-side (PHP, autoloaded, never fetched by a browser)
+— anything the browser has to fetch (`.js`, `.css`, images) has to live
+under `public/vendor/` instead, since `public/` is the only web-reachable
+directory (`novaconium/` isn't reachable at all — see `public/.htaccess`).**
+Twig lives under `novaconium/vendor/twig/` correctly, since it's pure PHP
+source. highlight.js (`/admin/docs/upgrading-highlightjs`,
+`public/vendor/highlightjs/`) is the first vendored dependency that's
+actually browser-servable, and originally almost got vendored to
+`novaconium/vendor/` too, following Twig's precedent blindly — that would
+have silently 404ed on every request, since nothing under `novaconium/`
+is ever served to a browser. This has a real consequence beyond just
+placement: `public/` is project-owned and untouched by the "Updating the
+framework" workflow (`rm -rf novaconium && cp -r <new-novaconium>` — see
+`/admin/docs/getting-started`), so a future framework release that bumps
+a `public/vendor/`-placed dependency will **not** carry that upgrade to
+an existing project automatically the way a `novaconium/vendor/` bump
+would — re-vendoring it is a separate manual step every time, documented
+per-dependency (see `/admin/docs/upgrading-highlightjs`).
+
+**`class="nohighlight"` marks a `<pre><code>` block whose content is
+literal Twig template syntax** (`{% %}`/`{{ }}`), so highlight.js's
+auto-detection (`novaconium/pages/_layout/syntax-highlight.twig`,
+restricted to `configure({ languages: ['php', 'bash', 'xml', 'css',
+'python', 'javascript', 'yaml', 'json', 'ini'] })` — `yaml`/`json`/`ini`
+are vendored as separate per-language files under
+`public/vendor/highlightjs/languages/`, not part of the core bundle like
+the other six; see `/admin/docs/upgrading-highlightjs`) doesn't
+force-match it to whichever configured language scores highest — Twig has
+no highlight.js grammar, and a restricted auto-detect still always
+returns its best guess among the allowed set, never "give up," so an
+unmarked Twig block would get colored *wrong*, not just left plain.
+Currently on:
+`novaconium/pages/admin/docs/{layouts,content-index,rss,sitemap,forms,seo}/index.twig`
+and `App/pages/blog/{style-guide,twig-syntax-guide}/index.twig`. A new
+Twig-syntax code sample added anywhere needs the same class — a PHP or
+Bash sample doesn't (auto-detection handles those reliably on its own,
+via strong signals like a leading `<?php`).
+
 ## Running it
 
 ```

App/pages/blog/code-highlighting/index.twig

@@ -0,0 +1,90 @@
+{% extends layout %}
+
+{% import '_layout/icons.twig' as icons %}
+
+{% block title %}Code Highlighting{% endblock %}
+{% block description %}How syntax highlighting works on this site, with worked examples in bash, HTML, CSS, YAML, Python, JavaScript, JSON, and INI/env.{% endblock %}
+
+{% block robots %}index, follow{% endblock %}
+{% block tags %}highlighting, reference{% endblock %}
+{% block canonical %}{{ request_path|default('/') }}{% endblock %}
+
+{% block og_type %}article{% endblock %}
+{% block og_title %}{{ block('title') }}{% endblock %}
+{% block og_description %}{{ block('description') }}{% endblock %}
+{% block og_url %}{{ block('canonical') }}{% endblock %}
+
+{% block twitter_card %}summary{% endblock %}
+{% block twitter_title %}{{ block('title') }}{% endblock %}
+{% block twitter_description %}{{ block('description') }}{% endblock %}
+
+{% block blog_content %}
+    <h1>Code Highlighting</h1>
+
+    <p>Every <code>&lt;pre&gt;&lt;code&gt;</code> block on this site gets colored automatically via vendored <a href="https://highlightjs.org/">highlight.js</a> — see <a class="icon-link" href="/admin/docs/styling">{{ icons.book() }}Styling</a> for the mechanism and <a class="icon-link" href="/admin/docs/upgrading-highlightjs">{{ icons.book() }}Upgrading highlight.js</a> for what's vendored. This post is a plain reference: how to write a code block, and one worked example in each language this site highlights.</p>
+
+    <h2>How to use it</h2>
+
+    <p>Write a normal code block — nothing extra required, the language is auto-detected:</p>
+
+    <pre><code class="nohighlight">&lt;pre&gt;&lt;code&gt;your code here&lt;/code&gt;&lt;/pre&gt;</code></pre>
+
+    <p>Auto-detection is restricted to the languages this site actually uses (see <code>hljs.configure(...)</code> in <code>novaconium/pages/_layout/syntax-highlight.twig</code>) so it doesn't misfire trying to match dozens of unrelated bundled languages against a short snippet. If a snippet is ambiguous, or ever gets detected as the wrong language, force it with an explicit <code>language-&lt;name&gt;</code> class instead of relying on auto-detection:</p>
+
+    <pre><code class="nohighlight">&lt;pre&gt;&lt;code class="language-yaml"&gt;your code here&lt;/code&gt;&lt;/pre&gt;</code></pre>
+
+    <p>A code block written in Twig template syntax (<code>{{ '{%' }} ... {{ '%}' }}</code>, <code>{{ '{{' }} ... {{ '}}' }}</code>) has no highlight.js grammar to match — mark those <code>class="nohighlight"</code> instead, the same way the two snippets above are marked (they're showing literal HTML as plain text, not being highlighted as HTML themselves). See <a class="icon-link" href="/blog/twig-syntax-guide">{{ icons.book() }}the Twig Syntax Guide</a> for Twig's own syntax, written the same way.</p>
+
+    <h2>Bash</h2>
+    <pre><code>#!/bin/bash
+for f in App/pages/blog/*/index.twig; do
+    echo "Post: $f"
+done</code></pre>
+
+    <h2>HTML</h2>
+    <pre><code>&lt;article class="post"&gt;
+    &lt;h1&gt;Hello, World!&lt;/h1&gt;
+    &lt;p&gt;A short excerpt.&lt;/p&gt;
+&lt;/article&gt;</code></pre>
+
+    <h2>CSS</h2>
+    <pre><code>.post-list li {
+    border-bottom: 1px solid var(--border-color);
+    padding: 0.75rem 0;
+}</code></pre>
+
+    <h2>YAML</h2>
+    <pre><code>site:
+    name: Novaconium Website
+    theme: dark
+tags:
+    - php
+    - twig
+    - highlighting</code></pre>
+
+    <h2>Python</h2>
+    <pre><code>def excerpt(text, length=140):
+    return text[:length].rsplit(" ", 1)[0] + "..."</code></pre>
+
+    <h2>JavaScript</h2>
+    <pre><code>function toggleTheme() {
+    const html = document.documentElement;
+    const next = html.dataset.theme === "light" ? "dark" : "light";
+    html.setAttribute("data-theme", next);
+}</code></pre>
+
+    <h2>JSON</h2>
+    <pre><code>{
+    "title": "Code Highlighting",
+    "tags": ["highlighting", "reference"],
+    "published": true
+}</code></pre>
+
+    <h2>INI / .env</h2>
+    <pre><code>; App/config.php equivalent, .ini-style
+[matomo]
+url = https://matomo.example.com/
+site_id = 1</code></pre>
+
+    <p>YAML, JSON, and INI aren't part of highlight.js's core bundle the way PHP/Bash/CSS/Python/JavaScript/XML are — they're vendored as three separate files under <code>public/vendor/highlightjs/languages/</code>, loaded after the core bundle. See <a class="icon-link" href="/admin/docs/upgrading-highlightjs">{{ icons.book() }}Upgrading highlight.js</a> for how to add another language the same way.</p>
+{% endblock %}

App/pages/blog/index.php

@@ -34,5 +34,11 @@ return [
             'excerpt'   => "A showcase of this theme's default styling for headings, lists, tables, code, and other common HTML elements.",
             'published' => '2026-07-13',
         ],
+        [
+            'slug'      => 'code-highlighting',
+            'title'     => 'Code Highlighting',
+            'excerpt'   => 'How syntax highlighting works on this site, with worked examples in bash, HTML, CSS, YAML, Python, JavaScript, JSON, and INI/env.',
+            'published' => '2026-07-14',
+        ],
     ],
 ];

App/pages/blog/style-guide/index.twig

@@ -83,7 +83,7 @@
 
     <h2>Code</h2>
     <p>Inline: <code>(new Mailer())-&gt;send($old['name'], $old['email'], $old['message']);</code></p>
-    <pre><code>{% verbatim %}{% extends layout %}
+    <pre><code class="nohighlight">{% verbatim %}{% extends layout %}
 
 {% block content %}
     ...

App/pages/blog/twig-syntax-guide/index.twig

@@ -24,7 +24,7 @@
 
     <h2>Output &amp; variables</h2>
     <p>Twig prints an expression with <code>{{ '{{ ... }}' }}</code>. Sidecar data, route params, and a handful of framework-provided variables (<code>request_path</code>, <code>layout</code>, <code>site_name</code>) are all just variables in scope:</p>
-    <pre><code>{% verbatim %}{{ title }}
+    <pre><code class="nohighlight">{% verbatim %}{{ title }}
 {{ params.slug }}
 {{ post.title }}{% endverbatim %}</code></pre>
     <p>Dot notation (<code>post.title</code>) works whether <code>post</code> is an array key or an object property — Twig tries both, so templates don't need to care which.</p>
@@ -46,29 +46,29 @@
 
     <h2>Control structures</h2>
     <p>The two workhorses are <code>{% verbatim %}{% if %}{% endverbatim %}</code> and <code>{% verbatim %}{% for %}{% endverbatim %}</code>:</p>
-    <pre><code>{% verbatim %}{% if sent %}
+    <pre><code class="nohighlight">{% verbatim %}{% if sent %}
     &lt;p&gt;Thanks — your message has been sent.&lt;/p&gt;
 {% endif %}{% endverbatim %}</code></pre>
-    <pre><code>{% verbatim %}{% for post in posts %}
+    <pre><code class="nohighlight">{% verbatim %}{% for post in posts %}
     &lt;li&gt;&lt;a href="/blog/{{ post.slug }}"&gt;{{ post.title }}&lt;/a&gt;&lt;/li&gt;
 {% endfor %}{% endverbatim %}</code></pre>
     <p>This exact loop is what renders the <a href="/blog">blog listing page</a> you probably followed a link from to get here.</p>
 
     <h2>Comments</h2>
     <p>Anything between <code>{% verbatim %}{# and #}{% endverbatim %}</code> is stripped entirely from the output — unlike an HTML comment, it never reaches the browser:</p>
-    <pre><code>{% verbatim %}{# Open Graph / Facebook #}{% endverbatim %}</code></pre>
+    <pre><code class="nohighlight">{% verbatim %}{# Open Graph / Facebook #}{% endverbatim %}</code></pre>
     <p>That one's real — it's the comment sitting above the Open Graph block in <code>novaconium/pages/_layout/layout.twig</code>.</p>
 
     <h2>Template inheritance &amp; includes</h2>
     <p><code>{% verbatim %}{% extends %}{% endverbatim %}</code> is how every page on this site gets its <code>&lt;html&gt;</code>/<code>&lt;head&gt;</code>/nav/footer for free — a child template only fills in named <code>{% verbatim %}{% block %}{% endverbatim %}</code> slots the parent declares:</p>
-    <pre><code>{% verbatim %}{% extends layout %}
+    <pre><code class="nohighlight">{% verbatim %}{% extends layout %}
 
 {% block title %}Blog{% endblock %}
 {% block blog_content %}
     ...
 {% endblock %}{% endverbatim %}</code></pre>
     <p><code>{% verbatim %}{% include %}{% endverbatim %}</code> pulls in a whole template inline (used for <code>_layout/nav.twig</code> and <code>_layout/matomo.twig</code>), while <code>{% verbatim %}{% import %}{% endverbatim %}</code> pulls in reusable <strong>macros</strong> — parameterized snippets like the icons used throughout this page:</p>
-    <pre><code>{% verbatim %}{% import '_layout/icons.twig' as icons %}
+    <pre><code class="nohighlight">{% verbatim %}{% import '_layout/icons.twig' as icons %}
 {{ icons.book() }}{% endverbatim %}</code></pre>
     <p>See <a class="icon-link" href="/admin/docs/layouts">{{ icons.book() }}Layouts</a> for how <code>{% verbatim %}{% extends %}{% endverbatim %}</code> resolution walks the <code>App/</code>-over-<code>novaconium/</code> override chain.</p>
 

README.md

@@ -21,6 +21,7 @@ A tiny, Hugo-flavored PHP micro-framework. Routes are directories on disk, pages
 - **Sessions with flash data** — `Lib\Session`, a thin wrapper around native PHP sessions with CodeIgniter-style flash values (set now, readable on exactly the next request) for post/redirect/GET flows without a query-string flag. Lazy-start, same mechanism `Lib\Csrf` already uses. See `/admin/docs/session`.
 - **Content index: sitemap, search, tags** — `/sitemap.xml`, full-text `/search` (SQLite FTS5), and blog tag browsing all share one crawler that renders every page and harvests `keywords`/`tags`/`changefreq`/`priority` Twig blocks via Twig's own `renderBlock()` — no front-matter, no separate metadata files. Off by default (depends on SQLite); reindexes lazily on demand or via `php novaconium/bin/index-content.php`. See `/admin/docs/content-index`.
 - **Blog RSS feed** — `/blog/feed`, built from the same hand-written post list `App/pages/blog/index.php` itself renders from, so it works with no database at all. `Lib\Rss` (a small RSS 2.0 envelope builder) also backs a per-tag feed, `/blog/tag/<tag>/feed`, once the content index above is enabled. Auto-discovered via a `<link rel="alternate">` on `/blog/*` pages.
+- **Syntax-highlighted code blocks** — vendored [highlight.js](https://highlightjs.org/) colors PHP/Bash/HTML code blocks site-wide, auto-detected with no per-block markup, swapping between dark (`ir-black`) and light (`github`) themes along with the existing dark/light toggle. Twig-syntax samples (which highlight.js can't parse) are left plain rather than colored wrong. See `/admin/docs/upgrading-highlightjs`.
 - **No build step, no Composer** — clone it, point Apache (or `php -S`) at `public/`, and it runs. Twig is vendored as source; see `/admin/docs/upgrading-twig` for upgrading it.
 
 ## Getting started

novaconium/ISSUES.md

@@ -56,17 +56,14 @@ three of the others):
 
 1. **Media/file manager** — no hard dependency; usable standalone, though
    best gated behind admin login once that exists.
-2. **Syntax highlighting on code blocks** — no hard dependency on the
+2. **Admin login & user management** — SQLite groundwork and session
-   copy button (see Done — shipped 2026-07-14), but touches the same
-   `<pre><code>` markup it did.
-3. **Admin login & user management** — SQLite groundwork and session
    handling it needed are both done; ready to build.
-4. **In-house comments** — needs admin login & user management (comments
+3. **In-house comments** — needs admin login & user management (comments
    are tied to real user accounts, not anonymous); build right after it.
-5. **Ecommerce functionality** — needs admin login & user management
+4. **Ecommerce functionality** — needs admin login & user management
    (order/product admin, and customer accounts); SQLite groundwork and
    session handling (cart) it needed are both done.
-6. **Paywall functionality** — needs everything Ecommerce needs, plus
+5. **Paywall functionality** — needs everything Ecommerce needs, plus
    Ecommerce itself for the recurring-billing/payment-gateway plumbing;
    build after it rather than in parallel — also now has a concrete
    precedent to follow for the "gated content must skip the static cache"
@@ -76,8 +73,8 @@ three of the others):
 
 MySQL support, Session handling (with flash sessions), Draft pages
 (admin-only preview), Blog tags/categories + Internal search + XML
-sitemap (shipped together as one content index — see Done), and Blog RSS
+sitemap (shipped together as one content index — see Done), Blog RSS
-feed all shipped 2026-07-14.
+feed, and Syntax highlighting on code blocks all shipped 2026-07-14.
 
 See **Won't Do** below for 404 tracking, dropped in favor of Matomo.
 
@@ -100,46 +97,6 @@ wanted later, in which case that part could ride on SQLite groundwork).
 Needs basic safety handling: extension allowlist, filename sanitization,
 and a max upload size, since this is a file-write surface.
 
-### Syntax highlighting on code blocks
-
-- **Type:** Feature
-- **Status:** Backlog
-- **Priority:** Low
-- **Added:** 2026-07-13
-
-Color the PHP/Twig/Bash/HTML snippets across `/admin/docs/*` and the
-blog's reference posts instead of the current flat, single-color
-`<pre><code>` rendering. PHP has a built-in `highlight_string()`, but it
-only understands PHP — everything else on this site's code blocks (Twig
-template syntax, Bash/Docker commands in `/admin/docs/styling`, plain
-HTML) needs something else, so use [highlight.js](https://highlightjs.org/)
-client-side for everything uniformly, with the **ir-black** theme (dark,
-high-contrast — fits this project's existing dark/teal default palette).
-ir-black is a dark-only theme, though, and this site now has a light
-theme too (see the dark/light toggle) — decide whether code blocks stay
-ir-black regardless of site theme (simplest, and arguably fine since
-code blocks are visually distinct boxes already), or whether a second,
-light-appropriate highlight.js theme gets swapped in via the same
-`data-theme` attribute the color-palette toggle already sets.
-Staying consistent with the no-CDN, no-build-step philosophy (Twig itself
-is vendored, not `npm install`ed) means vendoring highlight.js's built
-`highlight.min.js` + the `ir-black.min.css` theme file directly under
-`novaconium/vendor/` next to `twig/`, following the same
-one-subdirectory-per-vendor convention established there — rather than
-pulling from a CDN. highlight.js doesn't ship a Twig grammar out of the
-box; either register a custom language definition for it (Twig's syntax
-is close enough to Jinja2 that an existing community Jinja grammar may
-mostly work) or leave Twig snippets using the plain/no-highlight class
-and accept that only PHP/Bash/HTML/XML get colored initially.
-
-No hard dependency on the copy-to-clipboard button above, but both touch
-every `<pre><code>` block on the site, so doing them in the same pass
-avoids visiting each doc page's code samples twice. If both ship, the
-copy button must keep copying the plain, unhighlighted text (via
-`textContent`, not `innerHTML` — see that entry) even after this adds
-`<span>` wrappers around tokens, so a copied snippet doesn't come out
-full of stray markup.
-
 ### Admin login & user management
 
 - **Type:** Feature
@@ -235,6 +192,78 @@ _Nothing yet._
 
 ## Done
 
+### Syntax highlighting on code blocks
+
+- **Type:** Feature
+- **Status:** Done
+- **Priority:** Low
+- **Added:** 2026-07-13
+- **Shipped:** 2026-07-14
+
+Colors `<pre><code>` blocks site-wide via vendored highlight.js v11.11.1
+(pinned to that stable tag, not `main`, which tracks an in-progress
+`11.0.0-beta1`), auto-detected and restricted to `configure({ languages:
+['php', 'bash', 'xml', 'css', 'python', 'javascript', 'yaml', 'json',
+'ini'] })` — no per-block markup needed for the ~60 code blocks across the
+site. `css`/`python`/`javascript` ship in the core bundle alongside the
+original `php`/`bash`/`xml`; `yaml`/`json`/`ini` (the last covers
+`.env`-style files too) don't and are vendored as three separate
+per-language files under `public/vendor/highlightjs/languages/` — added
+after initial shipment, once `/blog/code-highlighting` (a new reference
+post, worked example of each of the nine) needed them. Themes swap with the
+existing dark/light toggle: **ir-black** (dark, as originally specified)
++ **github** (light, new — resolving the open question this entry
+originally left for "decide whether code blocks stay ir-black regardless
+of site theme"), via the same `data-theme`-driven mechanism as the main
+palette (`novaconium/pages/_layout/syntax-highlight-init.twig`/
+`syntax-highlight.twig`, mirroring `theme-init.twig`/`nav.twig`'s split —
+a `MutationObserver` on `data-theme` swaps the theme `<link>` live,
+without touching the existing toggle button's own click handler at all).
+
+Twig-syntax code blocks (no highlight.js grammar exists for Twig) are
+marked `class="nohighlight"` by hand at the source — the entry's own
+suggested fallback — rather than force-matched into the restricted
+candidate set, which would color them *wrong* rather than leave them
+plain (auto-detection with a restricted language list always returns its
+best guess among the allowed set, never "gives up"). 15 blocks across 9
+files needed the marker; verified by finding every `<pre><code>`
+containing literal `{% %}`/`{{ }}` syntax rather than guessing, and
+confirmed two files matching that initial grep (`sidecars`, one block in
+`forms`) turned out to be `{% verbatim %}`-wrapped *PHP* snippets
+(verbatim just protecting a stray `{{ }}` mention), correctly left alone
+for auto-detection. Same class of gotcha hit again writing the bash
+example for `/blog/code-highlighting`: a command starting with the
+literal word `php` (`php -S 127.0.0.1:8000 ...`) auto-detects as PHP, not
+bash — not a bug, just a reminder that short/ambiguous snippets can
+mis-detect regardless of the restricted candidate set; the shipped bash
+example uses a `#!/bin/bash` shebang instead, a strong, reliable signal,
+verified against the real detector before committing to it.
+
+**One correction to this entry's own suggested approach, found while
+implementing it:** vendoring highlight.js under `novaconium/vendor/` next
+to Twig (as originally suggested) would have been wrong and silently
+broken — Twig is server-side PHP, never fetched by a browser, but
+highlight.js's `.js`/`.css` files are, and only `public/` is web
+-reachable. Vendored to `public/vendor/highlightjs/` instead — see the
+standing rule added to `AGENTS.md` and `/admin/docs/upgrading-highlightjs`
+for the consequence: `public/` isn't touched by the usual
+`novaconium/`-swap framework-update workflow, so a future highlight.js
+version bump won't propagate to existing projects automatically the way
+everything else under `novaconium/` does.
+
+**A real bug caught by testing, not review:** `hljs.highlightAll()`
+doesn't defer itself if called while `document.readyState` is still
+`"loading"` — it silently no-ops permanently rather than waiting and
+retrying, confirmed with an actual DOM test (jsdom) before it was
+noticed, not assumed safe just because the script tag sits near the end
+of `<body>`. Fixed by wrapping the call in the same `DOMContentLoaded`
+pattern `code-copy.twig` already uses. Verified end-to-end with a real
+`highlight.js` execution against real rendered page HTML (not a hand
+-rolled mock): correct language detection on real PHP/Bash blocks,
+`nohighlight` blocks left untouched, and `code.textContent` (what the
+copy-to-clipboard button reads) confirmed unchanged after `<span>`
+-wrapping — the specific regression this entry flagged as a risk.
+
 ### Blog RSS feed
 
 - **Type:** Feature

novaconium/pages/_layout/layout.twig

@@ -4,6 +4,7 @@
 <head>
     <meta charset="utf-8">
     {% include '_layout/theme-init.twig' %}
+    {% include '_layout/syntax-highlight-init.twig' %}
     <meta name="viewport" content="width=device-width, initial-scale=1">
     <title>{% block title %}{{ site_name }}{% endblock %}</title>
     <meta name="description" content="{% block description %}A tiny, Hugo-flavored PHP micro-framework site.{% endblock %}">
@@ -70,5 +71,6 @@
         </nav>
     </footer>
     {% include '_layout/code-copy.twig' %}
+    {% include '_layout/syntax-highlight.twig' %}
 </body>
 </html>

novaconium/pages/_layout/syntax-highlight-init.twig

@@ -0,0 +1,18 @@
+{# Creates the highlight.js theme <link> with the correct href before
+   paint, so switching to light doesn't flash the dark (ir-black) code
+   theme first — same FOUC-avoidance trick theme-init.twig uses for the
+   main palette. Must run after theme-init.twig (data-theme needs to
+   already be set on <html>) and before the stylesheet link — see
+   novaconium/pages/_layout/layout.twig. The live swap (when the toggle
+   button is clicked after page load) is handled separately by
+   novaconium/pages/_layout/syntax-highlight.twig's MutationObserver. #}
+<script>
+    (function () {
+        var isLight = document.documentElement.getAttribute('data-theme') === 'light';
+        var link = document.createElement('link');
+        link.id = 'hljs-theme';
+        link.rel = 'stylesheet';
+        link.href = isLight ? '/vendor/highlightjs/styles/github.min.css' : '/vendor/highlightjs/styles/ir-black.min.css';
+        document.head.appendChild(link);
+    })();
+</script>

novaconium/pages/_layout/syntax-highlight.twig

@@ -0,0 +1,52 @@
+{# Colors <pre><code> blocks site-wide via vendored highlight.js
+   (public/vendor/highlightjs/ — see /admin/docs/upgrading-highlightjs),
+   auto-detected and restricted to only the languages this site actually
+   uses (hljs.configure below) so it doesn't waste cycles or misfire
+   trying to match ~40 bundled languages against a handful of short
+   snippets. php/bash/css/python/javascript/xml ship in the core
+   highlight.min.js bundle; yaml/json/ini don't (checked, not assumed —
+   see /admin/docs/upgrading-highlightjs) and are vendored as separate
+   per-language files under languages/, loaded after the core bundle so
+   their hljs.registerLanguage(...) self-registration calls have a global
+   hljs to register against. Twig-syntax code blocks have no highlight.js
+   grammar and are NOT auto-detected against — forcing one through the
+   restricted candidate set above would still force-match it to whichever
+   configured language scores highest, coloring it *wrong* rather than
+   leaving it plain. Those blocks are marked class="nohighlight" by hand
+   at the source (a real highlight.js convention meaning "skip this block
+   entirely") — see AGENTS.md for which files have them and why.
+
+   The copy-to-clipboard button (code-copy.twig) needs no changes for
+   this: it already reads code.textContent, not innerHTML, which stays
+   the original plain text regardless of the <span> wrapping
+   highlightAll() adds.
+
+   hljs.highlightAll() does NOT defer itself if called while the document
+   is still parsing (document.readyState === "loading") — it just silently
+   no-ops, permanently, rather than waiting and retrying. Confirmed this
+   with a real DOM test, not assumed: calling it immediately (unwrapped)
+   produced zero highlighted blocks even though this script tag sits near
+   the end of <body>, since the document can still be mid-parse at that
+   exact point. So this is wrapped in the same DOMContentLoaded pattern
+   code-copy.twig already uses for its own button injection, rather than
+   called directly. #}
+<script src="/vendor/highlightjs/highlight.min.js"></script>
+<script src="/vendor/highlightjs/languages/yaml.min.js"></script>
+<script src="/vendor/highlightjs/languages/json.min.js"></script>
+<script src="/vendor/highlightjs/languages/ini.min.js"></script>
+<script>
+    (function () {
+        hljs.configure({ languages: ['php', 'bash', 'xml', 'css', 'python', 'javascript', 'yaml', 'json', 'ini'] });
+
+        document.addEventListener('DOMContentLoaded', function () {
+            hljs.highlightAll();
+        });
+
+        var themeLink = document.getElementById('hljs-theme');
+
+        new MutationObserver(function () {
+            var isLight = document.documentElement.getAttribute('data-theme') === 'light';
+            themeLink.href = isLight ? '/vendor/highlightjs/styles/github.min.css' : '/vendor/highlightjs/styles/ir-black.min.css';
+        }).observe(document.documentElement, { attributes: true, attributeFilter: ['data-theme'] });
+    })();
+</script>

novaconium/pages/admin/docs/_layout/layout.twig

@@ -29,6 +29,7 @@
                 <li><a class="icon-link" href="/admin/docs/third-party">{{ icons.external_link() }}Third-party</a></li>
                 <li><a class="icon-link" href="/admin/docs/design-notes">{{ icons.book() }}Design notes</a></li>
                 <li><a class="icon-link" href="/admin/docs/upgrading-twig">{{ icons.book() }}Upgrading Twig</a></li>
+                <li><a class="icon-link" href="/admin/docs/upgrading-highlightjs">{{ icons.book() }}Upgrading highlight.js</a></li>
             </ul>
         </nav>
         <div class="docs-content">

novaconium/pages/admin/docs/content-index/index.twig

@@ -43,7 +43,7 @@ return [
         </tbody>
     </table>
 
-    <pre><code>{% verbatim %}{% block tags %}yellow, the best, summer, hot{% endblock %}
+    <pre><code class="nohighlight">{% verbatim %}{% block tags %}yellow, the best, summer, hot{% endblock %}
 {% block changefreq %}weekly{% endblock %}
 {% block priority %}1.0{% endblock %}{% endverbatim %}</code></pre>
 

novaconium/pages/admin/docs/forms/index.twig

@@ -87,7 +87,7 @@ return [
 
     <p>The honeypot field and the hidden timestamp are the two pieces every form needs regardless of its actual fields — copy them as-is:</p>
 
-    <pre><code>{% verbatim %}{% extends layout %}
+    <pre><code class="nohighlight">{% verbatim %}{% extends layout %}
 
 {% block title %}Newsletter{% endblock %}
 {% block description %}Sign up for occasional updates.{% endblock %}

novaconium/pages/admin/docs/index.twig

@@ -49,5 +49,6 @@
         <li><a class="icon-link" href="/admin/docs/third-party">{{ icons.external_link() }}Third-party</a> — vendored Twig and its license.</li>
         <li><a class="icon-link" href="/admin/docs/design-notes">{{ icons.book() }}Design notes</a> — the original design rationale.</li>
         <li><a class="icon-link" href="/admin/docs/upgrading-twig">{{ icons.book() }}Upgrading Twig</a> — how to bump the vendored copy.</li>
+        <li><a class="icon-link" href="/admin/docs/upgrading-highlightjs">{{ icons.book() }}Upgrading highlight.js</a> — how to bump the vendored copy, and why it's not automatic on a framework update.</li>
     </ul>
 {% endblock %}

novaconium/pages/admin/docs/layouts/index.twig

@@ -19,10 +19,10 @@ App/pages/blog/_layout/layout.twig       <- overrides it for everything under
 
     <p>A nested layout can extend the parent one (paths are resolved against the page roots, not relative to the current file):</p>
 
-    <pre><code>{% verbatim %}{% extends 'admin/docs/_layout/layout.twig' %}{% endverbatim %}</code></pre>
+    <pre><code class="nohighlight">{% verbatim %}{% extends 'admin/docs/_layout/layout.twig' %}{% endverbatim %}</code></pre>
 
     <p>Every <code>index.twig</code> extends whichever layout was resolved for it, via the <code>layout</code> variable that's always injected into the context:</p>
 
-    <pre><code>{% verbatim %}{% extends layout %}
+    <pre><code class="nohighlight">{% verbatim %}{% extends layout %}
 {% block content %}...{% endblock %}{% endverbatim %}</code></pre>
 {% endblock %}

novaconium/pages/admin/docs/rss/index.twig

@@ -85,7 +85,7 @@ return Response::xml(Rss::render(
 
     <p><a href="/admin/docs/seo">{{ icons.book() }}SEO</a>'s <code>head_extra</code> block is how a feed gets a <code>&lt;link rel="alternate" type="application/rss+xml"&gt;</code> tag in <code>&lt;head&gt;</code> so browsers/feed readers can discover it — <code>App/pages/blog/_layout/layout.twig</code> overrides it with exactly one such tag, scoped to <code>/blog/*</code> pages only since only that layout overrides the block. A layout isn't limited to one <code>&lt;link&gt;</code> in that override — list several, each with its own <code>title</code> attribute so a feed reader can tell them apart:</p>
 
-    <pre><code>{% verbatim %}{% block head_extra %}
+    <pre><code class="nohighlight">{% verbatim %}{% block head_extra %}
     &lt;link rel="alternate" type="application/rss+xml" title="{{ site_name }} Blog" href="/blog/feed"&gt;
     &lt;link rel="alternate" type="application/rss+xml" title="{{ site_name }} Products" href="/products/feed"&gt;
 {% endblock %}{% endverbatim %}</code></pre>

novaconium/pages/admin/docs/seo/index.twig

@@ -43,7 +43,7 @@
 
     <p>Any <code>index.twig</code> can override any subset of these blocks, same as <code>title</code> or <code>content</code>:</p>
 
-    <pre><code>{% verbatim %}{% extends layout %}
+    <pre><code class="nohighlight">{% verbatim %}{% extends layout %}
 
 {% block title %}Pricing{% endblock %}
 {% block description %}Plans and pricing for the whole team.{% endblock %}
@@ -59,7 +59,7 @@
 
     <p>Every <code>App/pages/*/index.twig</code> page in this project already includes the full block below as a reference — copy it into a new page and fill in the blanks. Nothing here is required (the layout's defaults are fine on their own), but having every knob visible up front makes it obvious what's available. Don't want to copy-paste by hand? <code>php novaconium/bin/create-static-page.php &lt;path&gt;</code> scaffolds this exact template for you — see <a href="/admin/docs/getting-started">Getting started</a>.</p>
 
-    <pre><code>{% verbatim %}{% extends layout %}
+    <pre><code class="nohighlight">{% verbatim %}{% extends layout %}
 
 {% block title %}Page title{% endblock %}
 {% block description %}One or two sentences describing this page.{% endblock %}

novaconium/pages/admin/docs/sitemap/index.twig

@@ -29,7 +29,7 @@
         </tbody>
     </table>
 
-    <pre><code>{% verbatim %}{% block changefreq %}weekly{% endblock %}
+    <pre><code class="nohighlight">{% verbatim %}{% block changefreq %}weekly{% endblock %}
 {% block priority %}1.0{% endblock %}{% endverbatim %}</code></pre>
 
     <p>A page that doesn't override either just gets the layout's defaults — nothing to set for most pages. Bump <code>priority</code> on a handful of pages that matter most (the homepage, key landing pages) rather than trying to rank every page precisely; search engines treat this as a hint, not a strict ordering.</p>

novaconium/pages/admin/docs/styling/index.twig

@@ -58,6 +58,12 @@ docker run --rm -v "$(pwd):/usr/src/app" -w /usr/src/app novaconium-sass \
 
     <p>To customize the light theme the same way you'd customize the dark one, edit the <code>-light</code> variables in <code>App/sass/_colors.sass</code> and recompile.</p>
 
+    <h2>Syntax-highlighted code blocks follow the same toggle</h2>
+
+    <p><a href="/admin/docs/upgrading-highlightjs">highlight.js</a> colors PHP/Bash/HTML(XML) <code>&lt;pre&gt;&lt;code&gt;</code> blocks site-wide, and swaps between two vendored themes — <strong>ir-black</strong> (dark) and <strong>github</strong> (light) — the same way the rest of the palette does, but as a separate mechanism from the Sass variables above, since these are two plain vendored CSS files, not compiled from this project's own <code>_colors.sass</code>. <code>novaconium/pages/_layout/syntax-highlight-init.twig</code> creates the correct theme <code>&lt;link&gt;</code> before paint (same FOUC-avoidance trick as <code>theme-init.twig</code>), and <code>novaconium/pages/_layout/syntax-highlight.twig</code> watches the <code>data-theme</code> attribute with a <code>MutationObserver</code> to swap it live when the toggle button is clicked — it doesn't need to know about the toggle button itself, only the attribute it already mutates.</p>
+
+    <p>A code block written in Twig syntax has no highlight.js grammar to match against — those are marked <code>class="nohighlight"</code> by hand at the source rather than highlighted incorrectly. See <code>AGENTS.md</code> for which files have them.</p>
+
     <h2>Copy-to-clipboard on code blocks</h2>
 
     <p><code>novaconium/pages/_layout/code-copy.twig</code>, included once from <code>_layout/layout.twig</code>'s footer, injects a hover-revealed copy button into every <code>&lt;pre&gt;</code> containing a <code>&lt;code&gt;</code> on the page — no per-page markup needed. It copies via <code>code.textContent</code> (not <code>innerHTML</code>), so HTML-entity-escaped samples like <code>&amp;lt;h1&amp;gt;</code> in the <a href="/admin/docs/seo">SEO</a> starter template come out as literal characters, not escaped markup. Uses the same event-delegation pattern as the theme toggle in <code>_layout/nav.twig</code>: one document-level click listener rather than a listener per button.</p>

novaconium/pages/admin/docs/third-party/index.twig

@@ -2,7 +2,7 @@
 
 {% block title %}Third-party{% endblock %}
 
-{% block description %}Vendored Twig and its license.{% endblock %}
+{% block description %}Vendored Twig and highlight.js, and their licenses.{% endblock %}
 
 {% block robots %}noindex, nofollow{% endblock %}
 
@@ -10,4 +10,6 @@
     <h1>Third-party</h1>
 
     <p><a href="https://twig.symfony.com/">Twig</a> is vendored in source form under <code>novaconium/vendor/twig/</code> (no Composer — see <a href="/admin/docs/upgrading-twig">Upgrading Twig</a> for how to upgrade it). It's BSD-3-Clause licensed; the full license text ships alongside it at <code>novaconium/vendor/twig/LICENSE</code>.</p>
+
+    <p><a href="https://highlightjs.org/">highlight.js</a> (v11.11.1) is vendored as its built distribution under <code>public/vendor/highlightjs/</code> — not <code>novaconium/vendor/</code> like Twig, since it's fetched by the browser and only <code>public/</code> is web-reachable (see <a href="/admin/docs/upgrading-highlightjs">Upgrading highlight.js</a>). Also BSD-3-Clause; the license text ships at <code>public/vendor/highlightjs/LICENSE</code>.</p>
 {% endblock %}

novaconium/pages/admin/docs/upgrading-highlightjs/index.twig

@@ -0,0 +1,44 @@
+{% extends 'admin/docs/_layout/layout.twig' %}
+
+{% block title %}Upgrading highlight.js{% endblock %}
+
+{% block description %}How to bump the vendored copy of highlight.js.{% endblock %}
+
+{% block robots %}noindex, nofollow{% endblock %}
+
+{% block docs_content %}
+    <h1>Upgrading vendored highlight.js</h1>
+
+    <p>Like Twig (see <a href="/admin/docs/upgrading-twig">Upgrading Twig</a>), highlight.js is vendored by hand — no Composer, no npm, no lockfile. Upgrading is a manual copy-and-verify process.</p>
+
+    <h2>The one thing that makes this different from every other vendored/framework file</h2>
+
+    <p>Everything else under <code>novaconium/</code> gets refreshed automatically when a project runs the <a href="/admin/docs/getting-started">"Updating the framework"</a> workflow (<code>rm -rf novaconium && cp -r &lt;new-novaconium&gt;</code>). highlight.js is vendored under <code>public/vendor/highlightjs/</code> instead, because its files are fetched by the browser and only <code>public/</code> is the Apache document root — <code>novaconium/</code> isn't web-reachable at all. <code>public/</code> is project-owned and that update workflow never touches it. <strong>A future framework release that bumps the vendored highlight.js version will not update it on an existing project automatically</strong> — re-vendoring it is a separate, manual step, following this page, even after an otherwise-routine framework update.</p>
+
+    <h2>What's currently vendored</h2>
+
+    <ul>
+        <li>Version: <strong>11.11.1</strong> (see the version comment at the top of <code>public/vendor/highlightjs/highlight.min.js</code> — that comment is always the source of truth, this doc can drift).</li>
+        <li>The root <code>build/highlight.min.js</code> bundle from <a href="https://github.com/highlightjs/cdn-release">highlightjs/cdn-release</a> — includes <code>php</code>, <code>bash</code>, <code>css</code>, <code>python</code>, <code>javascript</code>, and <code>xml</code> (covers HTML) out of the box.</li>
+        <li>Three separate per-language files under <code>public/vendor/highlightjs/languages/</code> — <code>yaml.min.js</code>, <code>json.min.js</code>, <code>ini.min.js</code> (covers <code>.env</code>-style key/value files too) — checked, not assumed, that these aren't part of the core bundle before vendoring them separately from <code>build/languages/</code> in the same <code>cdn-release</code> repo, at the same pinned tag.</li>
+        <li>Two themes: <code>public/vendor/highlightjs/styles/ir-black.min.css</code> (dark) and <code>styles/github.min.css</code> (light), swapped via the site's existing <code>data-theme</code> toggle — see <a href="/admin/docs/styling">Styling</a>.</li>
+        <li><code>public/vendor/highlightjs/LICENSE</code> (BSD-3-Clause) — covers the per-language files too, same license, same repo.</li>
+    </ul>
+
+    <p>All nine languages are why <code>hljs.configure({ languages: [...] })</code> in <code>novaconium/pages/_layout/syntax-highlight.twig</code> lists <code>['php', 'bash', 'xml', 'css', 'python', 'javascript', 'yaml', 'json', 'ini']</code> — see <a href="/blog/code-highlighting">the Code Highlighting post</a> for a worked example of each.</p>
+
+    <h2>How to upgrade</h2>
+
+    <ol>
+        <li>Pick a target version from the <a href="https://github.com/highlightjs/cdn-release/tags">cdn-release tags</a> — always a stable tag (e.g. <code>11.x.y</code>), never the <code>main</code> branch, which tracks an in-progress pre-release (this project's own vendored copy was pinned from tag <code>11.11.1</code> specifically for this reason, not <code>main</code>).</li>
+        <li>Download, from that same tag: <code>build/highlight.min.js</code>, <code>build/languages/yaml.min.js</code>, <code>build/languages/json.min.js</code>, <code>build/languages/ini.min.js</code>, <code>build/styles/ir-black.min.css</code>, <code>build/styles/github.min.css</code>, and <code>build/LICENSE</code>.</li>
+        <li>Replace the seven files under <code>public/vendor/highlightjs/</code> wholesale (<code>highlight.min.js</code>, the three files under <code>languages/</code>, the two under <code>styles/</code>, and <code>LICENSE</code>).</li>
+        <li>Confirm <code>php</code>, <code>bash</code>, <code>css</code>, <code>python</code>, and <code>javascript</code> are still present in the new core bundle (e.g. <code>grep -o '"php"' highlight.min.js</code>) — the root bundle's included-language set can change between releases; if one of these ever drops out, either vendor that language's individual file from <code>build/languages/</code> the same way <code>yaml</code>/<code>json</code>/<code>ini</code> already are, or adjust <code>hljs.configure({ languages: [...] })</code> to match what's actually available.</li>
+        <li>Run the app and check: code blocks still get colored on <a href="/blog/code-highlighting">the Code Highlighting post</a> (all nine languages, one worked example each) and the theme still swaps live with the dark/light toggle, and a <code>class="nohighlight"</code> Twig-syntax block (e.g. on <code>/admin/docs/seo</code>) still renders plain, uncolored. There's no automated test suite, so this is the real regression check.</li>
+        <li>Update the version note at the top of this page.</li>
+    </ol>
+
+    <h2>Adding a new highlighted language</h2>
+
+    <p>If a project adds code blocks in a language outside the nine above, vendor that language's file from <code>build/languages/&lt;name&gt;.min.js</code> in <code>cdn-release</code> (at the same pinned tag as everything else) into <code>public/vendor/highlightjs/languages/</code>, add a <code>&lt;script src="/vendor/highlightjs/languages/&lt;name&gt;.min.js"&gt;&lt;/script&gt;</code> tag after the core bundle (and after the other <code>languages/</code> scripts, order between them doesn't matter) in <code>novaconium/pages/_layout/syntax-highlight.twig</code>, and add the language's name to the <code>hljs.configure({ languages: [...] })</code> call there — each language file self-registers against the global <code>hljs</code> via its own <code>hljs.registerLanguage(...)</code> call once loaded, no other wiring needed.</p>
+{% endblock %}

novaconium/sass/main.sass

@@ -172,6 +172,19 @@ pre
     color: var(--accent)
     border-color: var(--accent)
 
+// Vendored highlight.js themes (public/vendor/highlightjs/, see
+// /admin/docs/upgrading-highlightjs) each set their own background and
+// pre code.hljs padding — overridden here so a highlighted block blends
+// into the existing pre box above instead of introducing a second,
+// mismatched background/padding. Loaded after the theme stylesheet (see
+// novaconium/pages/_layout/syntax-highlight-init.twig), so this wins by
+// source order alone, no !important needed.
+.hljs
+  background: transparent
+
+pre code.hljs
+  padding: 0
+
 hr
   border: none
   border-top: 1px solid var(--border-color)

public/css/main.css

@@ -176,6 +176,14 @@ pre:hover .copy-code-button, pre .copy-code-button:focus-visible {
   border-color: var(--accent);
 }
 
+.hljs {
+  background: transparent;
+}
+
+pre code.hljs {
+  padding: 0;
+}
+
 hr {
   border: none;
   border-top: 1px solid var(--border-color);

public/vendor/highlightjs/LICENSE

@@ -0,0 +1,29 @@
+BSD 3-Clause License
+
+Copyright (c) 2006, Ivan Sagalaev.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+* Redistributions of source code must retain the above copyright notice, this
+  list of conditions and the following disclaimer.
+
+* Redistributions in binary form must reproduce the above copyright notice,
+  this list of conditions and the following disclaimer in the documentation
+  and/or other materials provided with the distribution.
+
+* Neither the name of the copyright holder nor the names of its
+  contributors may be used to endorse or promote products derived from
+  this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

public/vendor/highlightjs/languages/ini.min.js

@@ -0,0 +1,15 @@
+/*! `ini` grammar compiled for Highlight.js 11.11.1 */
+(()=>{var e=(()=>{"use strict";return e=>{const n=e.regex,a={className:"number",
+relevance:0,variants:[{begin:/([+-]+)?[\d]+_[\d_]+/},{begin:e.NUMBER_RE}]
+},s=e.COMMENT();s.variants=[{begin:/;/,end:/$/},{begin:/#/,end:/$/}];const i={
+className:"variable",variants:[{begin:/\$[\w\d"][\w\d_]*/},{begin:/\$\{(.*?)\}/
+}]},t={className:"literal",begin:/\bon|off|true|false|yes|no\b/},r={
+className:"string",contains:[e.BACKSLASH_ESCAPE],variants:[{begin:"'''",
+end:"'''",relevance:10},{begin:'"""',end:'"""',relevance:10},{begin:'"',end:'"'
+},{begin:"'",end:"'"}]},l={begin:/\[/,end:/\]/,contains:[s,t,i,r,a,"self"],
+relevance:0},c=n.either(/[A-Za-z0-9_-]+/,/"(\\"|[^"])*"/,/'[^']*'/);return{
+name:"TOML, also INI",aliases:["toml"],case_insensitive:!0,illegal:/\S/,
+contains:[s,{className:"section",begin:/\[+/,end:/\]+/},{
+begin:n.concat(c,"(\\s*\\.\\s*",c,")*",n.lookahead(/\s*=\s*[^#\s]/)),
+className:"attr",starts:{end:/$/,contains:[s,l,t,i,r,a]}}]}}})()
+;hljs.registerLanguage("ini",e)})();

public/vendor/highlightjs/languages/json.min.js

@@ -0,0 +1,8 @@
+/*! `json` grammar compiled for Highlight.js 11.11.1 */
+(()=>{var e=(()=>{"use strict";return e=>{const a=["true","false","null"],s={
+scope:"literal",beginKeywords:a.join(" ")};return{name:"JSON",aliases:["jsonc"],
+keywords:{literal:a},contains:[{className:"attr",
+begin:/"(\\.|[^\\"\r\n])*"(?=\s*:)/,relevance:1.01},{match:/[{}[\],:]/,
+className:"punctuation",relevance:0
+},e.QUOTE_STRING_MODE,s,e.C_NUMBER_MODE,e.C_LINE_COMMENT_MODE,e.C_BLOCK_COMMENT_MODE],
+illegal:"\\S"}}})();hljs.registerLanguage("json",e)})();

public/vendor/highlightjs/languages/yaml.min.js

@@ -0,0 +1,28 @@
+/*! `yaml` grammar compiled for Highlight.js 11.11.1 */
+(()=>{var e=(()=>{"use strict";return e=>{
+const n="true false yes no null",a="[\\w#;/?:@&=+$,.~*'()[\\]]+",s={
+className:"string",relevance:0,variants:[{begin:/"/,end:/"/},{begin:/\S+/}],
+contains:[e.BACKSLASH_ESCAPE,{className:"template-variable",variants:[{
+begin:/\{\{/,end:/\}\}/},{begin:/%\{/,end:/\}/}]}]},i=e.inherit(s,{variants:[{
+begin:/'/,end:/'/,contains:[{begin:/''/,relevance:0}]},{begin:/"/,end:/"/},{
+begin:/[^\s,{}[\]]+/}]}),l={end:",",endsWithParent:!0,excludeEnd:!0,keywords:n,
+relevance:0},t={begin:/\{/,end:/\}/,contains:[l],illegal:"\\n",relevance:0},c={
+begin:"\\[",end:"\\]",contains:[l],illegal:"\\n",relevance:0},r=[{
+className:"attr",variants:[{begin:/[\w*@][\w*@ :()\./-]*:(?=[ \t]|$)/},{
+begin:/"[\w*@][\w*@ :()\./-]*":(?=[ \t]|$)/},{
+begin:/'[\w*@][\w*@ :()\./-]*':(?=[ \t]|$)/}]},{className:"meta",
+begin:"^---\\s*$",relevance:10},{className:"string",
+begin:"[\\|>]([1-9]?[+-])?[ ]*\\n( +)[^ ][^\\n]*\\n(\\2[^\\n]+\\n?)*"},{
+begin:"<%[%=-]?",end:"[%-]?%>",subLanguage:"ruby",excludeBegin:!0,excludeEnd:!0,
+relevance:0},{className:"type",begin:"!\\w+!"+a},{className:"type",
+begin:"!<"+a+">"},{className:"type",begin:"!"+a},{className:"type",begin:"!!"+a
+},{className:"meta",begin:"&"+e.UNDERSCORE_IDENT_RE+"$"},{className:"meta",
+begin:"\\*"+e.UNDERSCORE_IDENT_RE+"$"},{className:"bullet",begin:"-(?=[ ]|$)",
+relevance:0},e.HASH_COMMENT_MODE,{beginKeywords:n,keywords:{literal:n}},{
+className:"number",
+begin:"\\b[0-9]{4}(-[0-9][0-9]){0,2}([Tt \\t][0-9][0-9]?(:[0-9][0-9]){2})?(\\.[0-9]*)?([ \\t])*(Z|[-+][0-9][0-9]?(:[0-9][0-9])?)?\\b"
+},{className:"number",begin:e.C_NUMBER_RE+"\\b",relevance:0},t,c,{
+className:"string",relevance:0,begin:/'/,end:/'/,contains:[{match:/''/,
+scope:"char.escape",relevance:0}]},s],g=[...r]
+;return g.pop(),g.push(i),l.contains=g,{name:"YAML",case_insensitive:!0,
+aliases:["yml"],contains:r}}})();hljs.registerLanguage("yaml",e)})();

public/vendor/highlightjs/styles/github.min.css

@@ -0,0 +1,10 @@
+pre code.hljs{display:block;overflow-x:auto;padding:1em}code.hljs{padding:3px 5px}/*!
+  Theme: GitHub
+  Description: Light theme as seen on github.com
+  Author: github.com
+  Maintainer: @Hirse
+  Updated: 2021-05-15
+
+  Outdated base version: https://github.com/primer/github-syntax-light
+  Current colors taken from GitHub's CSS
+*/.hljs{color:#24292e;background:#fff}.hljs-doctag,.hljs-keyword,.hljs-meta .hljs-keyword,.hljs-template-tag,.hljs-template-variable,.hljs-type,.hljs-variable.language_{color:#d73a49}.hljs-title,.hljs-title.class_,.hljs-title.class_.inherited__,.hljs-title.function_{color:#6f42c1}.hljs-attr,.hljs-attribute,.hljs-literal,.hljs-meta,.hljs-number,.hljs-operator,.hljs-selector-attr,.hljs-selector-class,.hljs-selector-id,.hljs-variable{color:#005cc5}.hljs-meta .hljs-string,.hljs-regexp,.hljs-string{color:#032f62}.hljs-built_in,.hljs-symbol{color:#e36209}.hljs-code,.hljs-comment,.hljs-formula{color:#6a737d}.hljs-name,.hljs-quote,.hljs-selector-pseudo,.hljs-selector-tag{color:#22863a}.hljs-subst{color:#24292e}.hljs-section{color:#005cc5;font-weight:700}.hljs-bullet{color:#735c0f}.hljs-emphasis{color:#24292e;font-style:italic}.hljs-strong{color:#24292e;font-weight:700}.hljs-addition{color:#22863a;background-color:#f0fff4}.hljs-deletion{color:#b31d28;background-color:#ffeef0}

public/vendor/highlightjs/styles/ir-black.min.css

@@ -0,0 +1 @@
+pre code.hljs{display:block;overflow-x:auto;padding:1em}code.hljs{padding:3px 5px}.hljs{background:#000;color:#f8f8f8}.hljs-comment,.hljs-meta,.hljs-quote{color:#7c7c7c}.hljs-keyword,.hljs-name,.hljs-selector-tag,.hljs-tag{color:#96cbfe}.hljs-attribute,.hljs-selector-id{color:#ffffb6}.hljs-addition,.hljs-selector-attr,.hljs-selector-pseudo,.hljs-string{color:#a8ff60}.hljs-subst{color:#daefa3}.hljs-link,.hljs-regexp{color:#e9c062}.hljs-doctag,.hljs-section,.hljs-title,.hljs-type{color:#ffffb6}.hljs-bullet,.hljs-literal,.hljs-symbol,.hljs-template-variable,.hljs-variable{color:#c6c5fe}.hljs-deletion,.hljs-number{color:#ff73fd}.hljs-emphasis{font-style:italic}.hljs-strong{font-weight:700}