Popular v0.11.0

Added

• Every page says which generator built it, via <meta name="generator">
  (hugo.Generator on Hugo, Astro.generator on Astro). Astro does not inject
  this itself, and it is what the Astro theme catalogue's reviewers look for
  when verifying that a demo really is an Astro site.
• [module.hugoVersion] in the Hugo theme's hugo.toml, declaring the
  0.146.0 floor where themes.gohugo.io's build actually reads it. theme.toml's
  min_version is the older field, from the retired hugoThemes repo; both are
  kept in step. A site built with an older Hugo now says so, rather than the
  floor being a claim nothing checked.
• npm create popular-site@latest, a scaffolder for Astro sites (packaging
  phase 3). It writes a small project that depends on the theme rather than
  containing a copy of it, so the site updates with npm update instead of by
  diffing tags and re-copying files. Pick the neutral starter or any of the
  four demos as a fuller example to edit down.
  • The templates are collected from demos/* at pack time, so the demos stay
    the single source of truth and there is no committed copy to drift. The
    demo switcher bar is stripped on the way, and CI fails if it ever reaches
    a scaffolded site.
  • A project-page URL like https://you.github.io/my-community/ is split into
    Astro's site and base for you, the same split scripts/setup.py does.
  • Releases now publish two npm packages: astro-theme-popular and
    create-popular-site, versioned in lockstep so a scaffolded site always pins
    the theme release that shipped with it.

Changed

• A Popular deployment now loads nothing from a third party at all. The
  superfan demo was the last exception: it pulled Cinzel from Google Fonts
  through customCSS for its display face. It uses the bundled Quantico like
  the other demos now, so no page of the theme, its demos or its docs sends a
  visitor's IP anywhere. customCSS itself is unchanged and still takes any
  stylesheet URL you want, including a CDN.

• npm create popular-site@latest renders the same project templates the
  setup wizard does (scripts/templates/), instead of carrying its own copies
  of astro.config.mjs, package.json and content.config.ts. Two generators
  writing the same file two ways is how they drift, and one had already started:
  the wizard's template still defaulted to an older theme version.

• The release smoke-tests what it published: after both packages reach the
  registry it scaffolds a site from them and builds it. The scaffolder's own CI
  installs the theme from the checkout, which is right for a pull request but
  cannot catch a mismatch between two published versions. That gap is exactly
  what broke create-popular-site@0.10.0, whose templates needed a newer theme
  than it pinned; it is deprecated.

• The Astro README and the quick start lead with the scaffolder. The README
  still described npm run demo:aquarium as switching the active demo set into
  src/, which stopped being true when the demos became workspaces, and the
  quick start still told Astro users to use the repo as a template.

• The Astro demo deployment serves the neutral starter at its root, with the
  four flavored demos still at their subpaths and the gallery landing page moved
  to /demos/. The root used to be the gallery, a hand-written HTML page that is
  not an Astro build at all, so the URL people are given demonstrated nothing and
  could not be verified as an Astro site. It is now exactly what
  npm create popular-site@latest writes.

  • The gallery gets its icons and fonts from the deployment instead of cdnjs and
    Google Fonts, so the landing page stops being the one page that loads a third
    party.

• Astro: the demos are now real consumers of the npm package (packaging
  phase 3). The repo is an npm workspace, and each of the five demos is a
  project with its own package.json, astro.config.mjs, popular.config.ts,
  src/content/ and public/images/, installing the theme the way an adopter
  does. scripts/use-demo.mjs and the copy-a-demo-into-src/ step are gone;
  npm run dev --workspace demos/aquarium replaces activation.

  • The demo deployment and the image-alt job became integration tests.
    Both now build five real consumers against the packaged theme instead of
    one copied-together site, so a package regression fails CI rather than
    surfacing after publish.
  • Nothing changes for anyone using the theme. The template model (src/)
    keeps working until the cutover, and the Hugo side is untouched.

• Web fonts are served by the site itself, not fetched from
  fonts.googleapis.com. Inter and Quantico now ship in the theme
  (static/fonts/ ⇄ src/styles/fonts/), 716KB of woff2 under their SIL Open
  Font Licences. Nothing about the rendering changes: the vendored files are
  exactly the subsets and weight ranges Google was serving.

  • This removes a GDPR exposure. Embedding Google Fonts sends every
    visitor's IP address to Google, which a German court held to violate the
    GDPR (LG München I, 3 O 17493/20). A community site should not have to
    think about that.
  • It is also faster, not slower. The partitioned browser cache has meant no
    cross-site reuse since 2020, and the old @import added a DNS lookup, a
    TLS handshake and a round trip before any font could start downloading.
  • Every face keeps its unicode-range, so all seven Inter subsets ship but a
    latin-only page still downloads about 150KB of them. Greek, Cyrillic and
    Vietnamese sites now render in Inter instead of falling back.
  • Sites that prefer a CDN, or a different family entirely, override
    fonts.css the same way as before.

• Font Awesome is served by the site itself, not fetched from cdnjs. A
  Popular site now renders its icons offline, keeps working when a CDN has an
  outage or changes a URL, and no longer hands every visitor's IP address to a
  third party the community never chose. Font Awesome Free 7.3.1 ships in
  the theme (static/fontawesome/ ⇄ public/fontawesome/), about 364KB of
  woff2 and one stylesheet, under its own LICENSE.txt.

  • params.fontAwesome / SITE.fontAwesome is now optional: leave it
    unset for the bundled copy, or set it to a URL to use a CDN as before.
    Existing sites that set it keep working unchanged.
  • The version moves from 6.5.2 to 7.3.1. Every icon the theme and its demos
    use exists in 7.3.1 in the same style, but an adopter naming an icon that
    7.x removed would see a blank square, so check any icon you named yourself.
  • Sites generated by scripts/setup.py no longer pin the CDN URL in their
    config, so they follow the theme.

Fixed

• Astro package model: an adopter's SITE.fontAwesome now resolves against
  the base, so a site-relative path survives a subpath install. It was
  written to the page raw, unlike every other URL the theme emits. The subpath
  guard in CI could not see it because leaving the key unset renders no link at
  all; a smoke variant now sets it.
• The demo configs no longer pin fontAwesome to /fontawesome/…. That
  path is the template model's default and does not exist in the package model,
  which bundles the stylesheet instead, so every page of every demo requested a
  stylesheet that 404'd. Icons rendered anyway, from the bundled copy, which is
  why it went unnoticed. Leaving the key unset is and was the correct setting.