064ca3ff6d5b26c7524badf4068df7a858ef7a61
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
107cbadf79 |
perf: Header-Medien sofort und in passender Groesse laden
Drei Gruende, warum Hero-Bild und -Video spuerbar spaet erschienen: 1. Das Standbild des Hero-Videos steckte im poster-Attribut. poster nimmt nur eine fertige URL und laedt die hochgeladene Datei damit in voller gespeicherter Groesse — am Bildoptimierer vorbei, ohne Ruecksicht auf das Geraet. Es liegt jetzt als eigene ContentImage-Ebene unter dem Video, laeuft also durch next/image. Gemessen: auf einem 500px breiten Viewport kommt statt der vollen Datei die 640px-Variante als WebP an. Das Video darueber ist transparent, bis es eigene Bilddaten hat — der Uebergang bleibt unsichtbar. 2. Die aeusserste Hero-Section startete bei opacity 0 und wurde erst per Animation nach der Hydration sichtbar. Das groesste Element im ersten Viewport wurde damit um die gesamte JS-Ladezeit zurueckgehalten. Die Animation dort ist entfernt; der gestaffelte Aufbau der Textspalte bleibt unveraendert. 3. next/image erhielt weiterhin die Prop "priority". Die ist seit Next.js 16 abgekuendigt (siehe node_modules/next/dist/docs, Changelog v16.0.0) und erzeugt nur noch einen <link rel="preload">, setzt am <img> selbst aber weder fetchpriority noch loading — im Trace kam das Hero-Bild deshalb trotz "priority" mit Prioritaet "Low" an. Die Dokumentation nennt dafuer ausdruecklich loading="eager" und fetchPriority="high" als Ersatz; ContentImage bildet seine unveraendert heissende priority-Prop jetzt darauf ab, die Produktgalerie ebenso. Danach bestand die LCP-Discovery-Pruefung von Chrome vollstaendig, vorher scheiterte sie an fetchpriority. Ausserdem bekommen Inhaltsbilder leicht abgerundete Ecken (8px), Platzhalter und echtes Bild gleichermassen, damit die Form beim Pflegen eines Bildes nicht umspringt. Randlose Flaechen (Hero ueber die volle Fensterbreite) bleiben bewusst eckig — dort saesse die Rundung an der Fensterkante. Geprueft im Produktions-Build gegen Chrome: CLS 0.00, kein horizontaler Ueberlauf bei schmalem Viewport, Video spielt (readyState 4), Hero-Bild loading="eager" + fetchpriority="high", uebrige Bilder lazy. |
||
|
|
de0f6ee249 |
fix: Preis-/Datumsformat an Kunden-Locale anpassen, Produktgalerie-LCP verbessern
- format.ts: formatPrice/formatDate/formatDateTime/formatMonthYear nehmen jetzt ein optionales Locale-Argument (Default "de" fuer unveraenderte Aufrufer wie Rechnungen/Admin) und formatieren fuer "en" als en-GB statt hart codiert als de-DE -- englischsprachige Kundschaft sah bisher trotz gewaehlter Sprache "9,90 €" und "10. Mai 2026" statt "€9.90"/"10 May 2026". Alle kundenseitigen Aufrufer (Produktseite, Warenkorb, Checkout, Bestell- verfolgung, Konto-Bestellungen, Ernten-/Chargenseiten, Live-Suchvorschlaege, Bestell-/Versand-E-Mails) reichen jetzt die aktive Locale durch. - en.ts: openCart/shippingWithCount/shippingLabel pluralisieren "item(s)" jetzt korrekt (vorher z.B. "Open cart, 1 items"). - product-gallery.tsx: Haupt- und Vorschaubilder nutzen jetzt next/image statt <img> (hochgeladene Produktfotos sind immer same-origin unter /uploads/..., brauchen also keine remotePatterns-Konfiguration wie der entfernte Kommentar behauptete) -- Hauptbild mit priority/responsivem sizes, da es auf der Produktseite das wahrscheinlichste LCP-Element ist. - content-image.tsx: neue optionale priority-Prop; hero.tsx setzt sie fuer das Startseiten-Hero-Bild (ebenfalls LCP-Kandidat). - Sticky-Mobile-CTA-Leiste und useCartStock-Polling gegengeprueft: bereits korrekt (pb-28-Platzreservierung bzw. Fetch nur bei Warenkorb-Aenderung ohne Intervall) -- keine Aenderung noetig. Verifiziert: tsc --noEmit clean, pnpm test (142/142 gruen), pnpm build erfolgreich. |
||
|
|
ac432e261b |
fix: SEO- und Barrierefreiheits-Luecken auf Kaufentscheidungsseiten schliessen
Konkrete, verifizierte Luecken auf den Seiten, die Kund:innen von Google aus oder per Link erreichen: - Product-JSON-LD auf der Produktdetailseite ergaenzt um "image" (absolute URLs der hochgeladenen Produktfotos) — fehlte bisher trotz vorhandener Bilder und ist fuer Google Rich-Results/Merchant-Listing mit Sternebewertung + Preis im Suchergebnis erforderlich. - Alt-Text fuer echte (hochgeladene) Bilder aussagekraeftiger: ContentImage uebernimmt jetzt das bereits vorhandene, bisher nur auf Platzhalterkacheln sichtbare "label" (Ernte-Jahr/Typ, Kategorie, Ort) mit in den Alt-Text — wirkt projektweit auf Produktkarten, Ernte-Uebersicht/-Detail und Produkt-Teaser. Produktgalerie-Hauptbild zeigt zusaetzlich die Geschmacksnoten im Alt-Text statt nur des Produktnamens. - Checkout: allgemeine Fehlermeldung nach fehlgeschlagenem Absenden bekommt role="alert" und Fokus wird aktiv dorthin verschoben — bisher rein farblich markiert, Screenreader-Nutzer:innen haetten den Fehler beim geldwerten Bestellabschluss sonst gar nicht mitbekommen. - Cart-Drawer und Warenkorb-Seite: Lagerbestand-Hinweise (Ausverkauft/Nur noch N) treffen asynchron erst nach dem ersten Rendern ein — jetzt in einem persistenten aria-live-Wrapper, damit der Uebergang tatsaechlich angesagt wird statt stumm zu bleiben. Geprueft und bereits solide befunden (keine Aenderung noetig): Shop-Kanonical ignoriert bewusst Such-/Filter-Query-Parameter (kein Duplicate-Content-Risiko), Sitemap deckt Produkt- und Ernte-Detailseiten mit echtem lastmod ab, Produktgalerie-Tastaturbedienung ueber echte <button>-Kacheln mit aria-label/aria-current, Cart-Drawer-Fokusfalle/Fokus-Rueckgabe, Mengen-Steller- aria-live, Farbkontrast von text-honey-dark/text-red-700 auf dem Hintergrund (~4.9:1 bzw. ~6.1:1, beide AA-konform). tsc/vitest/build bleiben gruen (142 Tests). |
||
|
|
54919d82ed |
feat: Bild-Upload fuer Inhalte, Produkte und Ernten
Docker Image bauen und veroeffentlichen / build-and-push (push) Successful in 2m34s
Echter Datei-Upload statt CSS-Platzhaltergrafiken, gespeichert unter UPLOAD_DIR (Laufzeit-Verzeichnis, weiss nichts von seiner tatsaechlichen Speicher-Anbindung — in Produktion ein von der Betreiberin selbst per Kubernetes eingebundenes Volume, z.B. SMB; lokal ein simples ./uploads). - lib/uploads.ts: Kernlogik. Bildformat wird ausschliesslich aus den tatsaechlichen Bilddaten erkannt (Magic-Bytes via sharp), nie aus Client-Dateiname/MIME-Type. Zufaellige, nicht erratbare Dateinamen (Path-Traversal-/Overwrite-Schutz). Re-Encoding validiert Pixel-Daten vollstaendig und entfernt eingebettete Metadaten (EXIF/ICC/XMP) als Nebeneffekt. Content-Type beim Ausliefern kommt ausschliesslich aus einer festen Endung->MIME-Zuordnung, nie aus Dateiinhalt/-namen. - app/api/admin/upload/route.ts: Admin-only Upload-Endpunkt (CSRF- + Auth- + Rate-Limit-Pruefung, max. 8 MB, JPEG/PNG/WebP/AVIF). - app/uploads/[...path]/route.ts: liefert hochgeladene Bilder aus (public/ wird zur Build-Zeit fest ins Image gebacken, kann also keine zur Laufzeit hinzugefuegten Dateien bedienen) — mit Path-Traversal-Schutz und nosniff-Header. - content-registry.ts: neuer "image"-Feldtyp fuer Hero-/Startseite- Grafiken, admin/inhalte hat dafuer ein Upload-Widget. - Produkt-/Ernten-Admin-Formulare: Mehrfach-Bild-Upload fuer Product.images/Harvest.images (beide Felder existierten im Schema, hatten aber bislang keine Admin-Oberflaeche). Oeffentliche Seiten (Shop, Ernten, Chargen-QR-Seite) zeigen jetzt echte Fotos statt Platzhalter, sobald vorhanden. - Kubernetes: nur ein einfacher volumeMount in 05-app-deployment.yaml (Platzhalter-emptyDir, klar als CHANGE-ME markiert) — die eigentliche Volume-Quelle (SMB o.ae.) bindet die Betreiberin selbst ein, wie gewuenscht keine SMB/CSI-spezifischen Manifeste hinzugefuegt. Verifiziert: tsc --noEmit clean, 139/139 Tests gruen (21 neu), pnpm build clean. Upload-/Serving-Pipeline live gegen einen laufenden Server getestet (Auth-/CSRF-Gates, Path-Traversal-Ablehnung, Format-Ablehnung) — ein vollstaendiger authentifizierter Upload end-to-end (braucht echten Admin-Login inkl. 2FA) wurde nicht live durchgespielt, nur per Code-Review verifiziert. Co-Authored-By: Claude Sonnet 5 <[email protected]> |