2 Commits

Include renames

Author	SHA1	Message	Date
Do SikiandClaude Sonnet 5	1b3ae07811	feat(deploy): staging/production Docker deploy for Payload (MITHOME-97) ... Fixes a real, previously-undiscovered build failure and a bigger architectural gap found while testing an actual `docker build` of proto/Dockerfile for the first time since the Payload migration: 1. Docker build failure: the (frontend)/[locale] pages use generateStaticParams, so `next build` fully prerenders them (SSG) — which calls the Payload Local API during the build. With no MONGODB_URI/PAYLOAD_SECRET reachable in the build stage, `docker build` failed outright ("missing secret key"). 2. Bigger problem underneath: even if the build could reach a DB, full SSG means a Payload admin edit would NOT appear on the public site until a full rebuild + redeploy — directly undermining the project's whole reason for migrating to Payload (self-service content editing for the client). Fix (user-confirmed direction: force-dynamic): dropped generateStaticParams from (frontend)/[locale]/layout.tsx and [locale]/[slug]/page.tsx, added `export const dynamic = 'force-dynamic'` to layout.tsx + both page.tsx files. Every request now reads Payload live — publishing in the admin is visible immediately, and the Docker build no longer needs any DB connectivity at all (verified: a full `docker build --target builder` now succeeds with zero env vars set). Docker/Compose changes: - docker-compose.staging.yml / docker-compose.prod.yml: wired PAYLOAD_SECRET through to the app container (was documented in .env.*.example since MITHOME-86 but never actually passed to the container — Payload would have refused to start). No fallback, same fail-loudly pattern as MONGODB_URI. - Same two files: added a named `media_data_{staging,prod}` volume mounted at /app/media — Payload's local upload storage (Media.ts) writes there at the container's runtime cwd; without a volume, `deploy.sh`'s `--force-recreate` would silently wipe every uploaded logo/image on each deploy. - docker-compose.dev.yml: was missing PAYLOAD_SECRET entirely (only discovered because the same "missing secret key" error reproduces there too) — added a dev-only literal value. Media persistence already works there via the existing `./proto:/app` bind mount, no volume needed. Also dropped the obsolete `version: '3.8'` key (compose warns it's ignored). - DOCKER.md: one-paragraph note on the new PAYLOAD_SECRET requirement and where the admin account gets created. Verified: - `docker build --target builder` succeeds from a clean context with zero environment variables (previously failed). - `docker build --target runner` + `docker run` against the real dev MongoDB (PAYLOAD_SECRET + MONGODB_URI supplied at runtime only): /hu, /admin and /api/health all return 200 inside the container; confirmed live in the browser that Payload content renders correctly end-to-end through the production Next.js server, not just `next dev`. - `docker compose -f docker-compose.{staging,prod,dev}.yml config` parses cleanly. - Full gate green: tsc, lint, proto unit tests (51 passed), scripts/pre-deploy-tests.sh (proto tests, tsc, lint, content schema, plane-sync — all pass). deploy.sh itself needs no changes: it already just runs `docker compose up --build`, and that now works without any build-time DB wiring. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-11 22:12:01 +02:00
Do SikiandClaude Sonnet 5	d6f3dda9e5	feat(frontend): Payload Local API + hu/en locale routing (MITHOME-91/114) ... Replaces the JSON content system with Payload's Local API across every frontend page, and introduces symmetric locale-prefixed routing (/hu/..., /en/...) with per-locale translated slugs — supersedes the earlier "hu unprefixed" decision (see chat 2026-09-10). Routing structure: - src/app/(frontend)/layout.tsx: now a minimal shell (html/body, theme script, ThemeProvider) — no longer locale-aware. - src/app/(frontend)/page.tsx: redirects bare "/" to the default locale (/hu). - src/app/(frontend)/not-found.tsx: explicit 404 for the (frontend) group — without it, Next's built-in fallback collided with the (payload) group's own root and reproduced the "double html / script tag" symptom from MITHOME-87, but only on notFound() paths. Verified fixed in both dev and a real production (standalone) server; the remaining "script tag" console warning on invalid routes turned out to be Turbopack dev-mode-only noise (zero console errors in production) — confirmed by building and running .next/standalone directly. - src/app/(frontend)/[locale]/layout.tsx: validates the locale segment (generateStaticParams hu/en, notFound() otherwise), fetches Common + Home via Payload, renders Header/Footer/staging-banner. - src/app/(frontend)/[locale]/page.tsx: home, fetches Home global + Partners collection. - src/app/(frontend)/[locale]/[slug]/page.tsx: catch-all for about/ services/contact/privacy/terms — resolves slug -> PageKey via src/lib/i18n.ts's PAGE_SLUGS map (generateStaticParams pre-renders all 10 locale×slug combinations), generateMetadata per page. New lib layer: - src/lib/i18n.ts: Locale/PageKey types, PAGE_SLUGS (translated slugs per locale), localePath()/resolvePageKey()/switchLocalePath() helpers (the last one already shaped for MITHOME-115). - src/lib/payload-content.ts: Local API getters that also unwrap Payload's `{ value: string }[]` array-field shape back into plain string[] (see src/globals/fields/stringArray.ts) — keeps the page JSX consuming the exact shape the old content/types.ts had, so the migration is a data-source swap, not a markup rewrite. Presentational split: page bodies moved to src/components/views/ (HomeView, AboutView, ServicesView, ContactView, LegalPageView — the last one shared by both legal pages, identical shape) as prop-driven components; the app-router page.tsx files became thin server-side fetch + render wrappers. Header/Footer converted from importing content directly to accepting nav/locale/content props, since they're 'use client' and can't call the Payload Local API themselves — config/site.ts's navigation arrays became getMainNavigation(locale)/ getFooterNavigation(locale)/getFooterLegalLinks(locale) functions. Two real, pre-existing bugs fixed along the way (not introduced by this migration): - Services and Contact pages' "Webmail belépés" links used the primary CTA's href (/kapcsolat) with target="_blank" instead of the actual webmail URL (home.hero.cta.secondary.href) — now correct. - The GDPR checkbox link pointed to "/adatkezelesi-tajekoztato", which never matched the real privacy page route under any past URL scheme. contact.json's gdpr.label now carries a {privacyHref} placeholder that ContactView replaces with the locale-correct path — also fixes the adatvedelem page's own <title> tag, which previously read "Adatvédelmi Tájékoztató | Szolgáltatás jellemzők:" (a copy-paste bug using common.labels.features instead of the site name). Known, accepted limitation: the outer shell layout hardcodes <html lang="hu"> because it sits above the [locale] segment and can't read the param — every [locale]/[slug] page's own generateMetadata is locale-correct, but the initial lang attribute isn't. Documented as a MITHOME-116 (SEO/hreflang) follow-up rather than restructured now. Verified end to end in a real browser: /hu matches the https://stage.mozdit.hu visual baseline (MITHOME-117) exactly; /en renders with English nav/metadata (content body still Hungarian-only, as expected — MITHOME-111/113 not done yet); /hu/kapcsolat's GDPR link resolves to /hu/adatvedelem; dark mode still works; invalid locale (/fr/about) and invalid slug (/hu/nemletezo-oldal) both 404 correctly; bare "/" redirects to /hu. build/lint/tsc/test (58 passed) all clean, including a clean production standalone-server run. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 16:15:09 +02:00