Peter Meier
e28230bcef
## Responsive sources Wire `ensureResponsiveImage` (multi-width × multi-format srcset) into the three remaining single-`<img>` components: - ImageBlock (body): widths 600 + 1200, fit follows transform params - ImageGalleryBlock (single-image branch): widths 600 + 1280, fit=contain - PostCard (post-list cards): widths 400 + 800, fit=cover, ar=3:2 `resolveContentImages` now sets `block.resolvedResponsive` alongside the legacy `resolvedImageSrc`, so every Svelte block component renders `<picture>` if the responsive shape is present and falls back to a plain `<img>` otherwise. Posts list pages (`/posts`, `/posts/page/N`, `/posts/tag/.../page/N`) call a new `resolvePostCardResponsive` helper instead of one-shot `ensureTransformedImage`. ## Drop AVIF from defaults Server-side AVIF encoding on the CMS is 5-10× slower than WebP. The bandwidth win is marginal for this site and the build time hit is severe (multi-minute hangs on each new variant). Default formats are now `["webp", "jpeg"]` for `ensureResponsiveImage`, in `Layout.astro`'s TopBanner hero, and in the post-card helper. Callers can still opt back into AVIF per-call. ## Module split for client-safe types `ResponsiveImage` is now defined in a tiny `rusty-image-types.ts` and duplicated in `rusty-image.ts` so Svelte components can `import type` the shape without dragging `rusty-image.ts` (and its `node:crypto`/`node:fs` imports) into the browser bundle. `resolvePostCardResponsive` lives in a new `server-image.ts` for the same reason — `blog-utils.ts` is imported by Svelte islands, so its server-only helpers move out. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
RustyAstro
Astro-Frontend für RustyCMS: nutzt die REST-API und die OpenAPI-Spezifikation. Page-Content (Listen- und Einzelseiten) ist angebunden.
Voraussetzungen
- RustyCMS läuft (z.B.
cargo runim Nachbarordnerrustycms) unterhttp://localhost:3000. - Node.js 18+
Setup
cd rustyastro
cp .env.example .env
# Optional: .env anpassen (PUBLIC_CMS_URL)
npm install
Entwicklung
# Terminal 1: CMS starten
cd rustycms && cargo run
# Terminal 2: Astro starten
cd rustyastro && npm run dev
Astro läuft standardmäßig auf http://localhost:4321. Die Startseite listet alle Pages aus dem CMS; Klick auf einen Eintrag öffnet die Einzelseite unter /:slug (z.B. /home, /about).
Konfiguration
| Variable | Beschreibung |
|---|---|
PUBLIC_CMS_URL |
Basis-URL des RustyCMS (ohne Slash), z.B. http://localhost:3000 |
Die OpenAPI-Spec wird von {PUBLIC_CMS_URL}/api-docs/openapi.json geladen (u.a. für die Anzeige auf der Startseite). Page-Daten kommen von GET /api/content/page und GET /api/content/page/:slug.
TypeScript-Typen für die API (z.B. PageEntry) werden aus dieser Spec generiert. Nach Schema-Änderungen im CMS:
# RustyCMS muss laufen
yarn generate:api-types
Die generierte Datei ist src/lib/cms-api.generated.ts (wird von cms.ts importiert).
Build
npm run build
Beim Build müssen die CMS-Endpunkte erreichbar sein (für getStaticPaths und die Daten der Seiten). Für Produktion PUBLIC_CMS_URL auf die echte CMS-URL setzen.
Struktur
src/lib/cms.ts– CMS-Client (OpenAPI, Pages, Slug-Liste)src/lib/cms-api.generated.ts– aus OpenAPI generierte Typen (mityarn generate:api-typeserzeugen)src/pages/index.astro– Startseite mit Page-Listesrc/pages/[slug].astro– Einzelseite pro Page-Slugsrc/layouts/Layout.astro– Layout inkl. Tailwind