/api/contact used to write straight to a raw, Payload-external MongoDB
collection (contact_submissions, via proto/src/lib/mongodb.ts's
getCollection) — the client had no way to see incoming messages except
by reading the database directly. Rate limiting, length caps, email
validation, and spam-keyword filtering all stay on the route exactly
as before; only the persistence target changed.
New: src/collections/ContactSubmissions.ts (name, email, subject,
message, gdprConsent checkbox, status select defaulting to "new").
Deliberately no custom `access` block — Payload's default
(authenticated-only for every REST operation) is exactly right here:
the client reads submissions in the admin, nobody can read or write
them through the public REST API, and the route's own write uses the
Local API (payload.create), which runs with overrideAccess: true by
default and so isn't blocked by that same rule. No versions/drafts
(a submission is a fact, not editable content) and no field-level
length/format validation duplicated in the collection, matching the
ticket's explicit scope: those checks live on the route.
route.ts: replaced getCollection()/insertOne() with
getPayload({config}).create({ collection: 'contact-submissions', ... }).
Removed the now-unused getCollection() helper from lib/mongodb.ts
(checkMongoConnection/getDb stay, used by /api/health) and its test.
Test gotcha worth documenting: next/jest's SWC transform rewrites the
`@payload-config` tsconfig-path alias to a real relative specifier at
transform time, so `jest.mock('@payload-config', ...)` never actually
intercepts what route.ts requires — it silently falls through to the
real payload.config.ts (mongooseAdapter, live Mongo needed). Fixed by
mocking the resolved relative path instead
(`jest.mock('../../../payload.config', ...)`); documented inline in
route.unit.test.ts for whoever hits this next (MITHOME-96 will need
the same trick for other Payload-backed routes/collections).
Verified live end-to-end, not just the test suite: submitted the real
contact form on /hu/kapcsolat, got the success message, found the
submission in /admin/collections/contact-submissions with all fields
correct (including gdprConsent checked and status "Új"/New), then
deleted the test record. Zero console errors in a fresh tab. Gate:
tsc, lint, unit tests (50 passed — one fewer than before, the removed
getCollection test), production build all green.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds a search box to the top of every Payload admin page
(admin.components.header) that searches by text across every field of
every Global and Collection, in both locales — something Payload has
no built-in equivalent for: collection list views only search their
own title/slug fields, and Globals have no list view at all.
Implementation is deliberately client-side and index-free rather than
@payloadcms/plugin-search (a server-side search collection kept in
sync via hooks): this project's entire content is 5 Globals + 2 small
Collections, so a plugin-managed search index would be disproportionate
maintenance for the actual data volume — the same reasoning already
applied to the logo editor (MITHOME-118). On first use, the component
fetches every Global/Collection doc in both locales via the existing
REST API (same-origin, admin session cookie), recursively flattens
every field to (path, value) pairs client-side, and filters by
case-insensitive substring as the user types. Each result links
straight to the right edit view (global or collection/id).
New: src/components/admin/QuickSearch.tsx. Registered via
payload.config.ts admin.components.header, which required a
generate:importmap run — the useful gotcha this surfaced: Payload
resolves component paths against admin.importMap.baseDir, which
defaults to process.cwd() (the proto/ the CLI is run from), not
dirname(payload.config.ts) — so the path needed to be
'./src/components/admin/QuickSearch#QuickSearch', not
'./components/admin/QuickSearch#QuickSearch'. Documented inline.
Verified live in the browser (not just tsc/lint): search finds matches
in both a Global (Home hero.cta.secondary.text / services description)
and a Collection (Partners name/url), shows source + field path +
locale + a snippet per result, clicking a result navigates to the
correct edit view, and the search state persists across client-side
admin navigation since the header component doesn't remount. Zero
console errors in a fresh tab. Full gate green: tsc, lint, unit tests
(51 passed), production build.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
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>
Payload Global configs mirroring proto/src/content/types.ts:
- src/globals/{Home,About,Services,Contact,Common}.ts
- src/globals/fields/stringArray.ts — shared helper: Payload has no
native string[] field, so every plain string array from the old
content types (trustBullets, paragraphs, features, spec items, …)
becomes an array of one-field { value } objects.
- home.partners is intentionally NOT included — that becomes its own
Partners collection (logo -> Media upload) in MITHOME-89, to avoid
two disagreeing sources for the same data.
- contact.form.fields.gdpr.label stays a plain textarea (not lexical
richText): the JSON source is a hand-written HTML string with an
<a> tag; richText's node-tree serialization would need its own
migration/render logic, out of scope for this bootstrap pass.
scripts/migrate-content-to-payload.ts: one-shot, idempotent Local API
migration reading the existing JSON files and calling updateGlobal —
does not touch or delete the JSON files. Run via the new
`npm run migrate:content` script.
Registered the five Globals in payload.config.ts.
Also included here (belongs with the previous "resolve double-root-
layout conflict" commit but didn't actually get staged there —
verified only now by diffing HEAD against the working tree):
(frontend)/layout.tsx's relative imports corrected to ../../ instead
of ../ (one directory deeper than the original src/app/layout.tsx).
Verified:
- npm run build / lint, tsc --noEmit, npm test (58 passed) all clean
- npm run migrate:content against the real dev MongoDB container,
then read back via payload.findGlobal() — hero.title, trustBullets,
services.items[0].features, footer.address, faq.items.length all
match the JSON source
- Real browser: logged into /admin, opened the Home global editor —
Hero/Trust bullets group renders and shows the migrated Hungarian
content correctly (see screenshot shared in chat)
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Next.js 16 requires either one shared root layout for every route, or
each top-level route group to be fully self-contained (no ancestor
layout.tsx above it). MITHOME-86 added (payload)/layout.tsx — which
itself renders Payload's own <html>/<body> via <RootLayout> — while
src/app/layout.tsx still existed as a shared ancestor and did the same.
The result was two React trees fighting over <html>/<body>/<head>,
surfacing in the browser as hydration failures and "You are mounting a
new html component" errors on /admin (invisible to curl-based checks
in the MITHOME-86 verification, since they only exercise SSR, not
client hydration — that verification's "confirmed live" claim was
therefore incomplete; caught now with an actual browser).
Fix, per Payload's documented multi-root pattern: move every existing
site route (page.tsx, globals.css, kapcsolat/szolgaltatasok/rolunk/
adatvedelem/felhasznalasi-feltetelek) into a new (frontend) route
group with its own layout.tsx (renamed from src/app/layout.tsx, with
relative imports adjusted one level deeper), as a sibling of (payload).
No shared layout.tsx remains directly under src/app/.
Verified in a real browser (not just curl): /admin/login and the
dashboard now render and hydrate cleanly, and all site routes
(/, /rolunk, /szolgaltatasok, /kapcsolat, /adatvedelem,
/felhasznalasi-feltetelek) are unaffected — same output, just moved.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Alapinstalláció a Payload CMS-re való áttéréshez (EPIC MITHOME-85):
- payload@3.88.0, @payloadcms/next, @payloadcms/db-mongodb,
@payloadcms/richtext-lexical, graphql, sharp telepítve
- src/payload.config.ts: mongooseAdapter a meglévő MONGODB_URI-ra
(ugyanaz az adatbázis, mint a Mongoose/mongodb rétegnek), lexical
editor, PAYLOAD_SECRET env-ből
- src/collections/Users.ts: minimális auth collection — Payload nem
tud admin felületet renderelni auth collection nélkül. Ez csak a
bootstraphez kell; a valódi access control/jelszó-politika MITHOME-90
feladata.
- App Router route group (src/app/(payload)/): admin UI
([[...segments]]), REST (api/[...slug]), GraphQL + playground route-ok,
root layout — a szokásos Payload v3 Next.js integrációs minta szerint
- next.config.ts: withPayload() wrapper a route handler bundling-hoz
- tsconfig.json: @payload-config path alias -> src/payload.config.ts
(ez oldja fel a webpack/turbopack importot is, nem csak a type-checket)
- PAYLOAD_SECRET env var: generált dev érték a .env.local-ban
(gitignore-olt), changeme placeholder + generálási megjegyzés a
staging/production .env példafájlokban, dokumentálva a CLAUDE.md
env-lista részében
Ismert, még nem javított biztonsági advisory a felvett payload@3.88.0-ban
(GHSA-jg8r-5jh2-v2xj, moderate, CWE-307: az admin account-unlock alapból
más fiókok lockoutját is felold hitelesített usernek) — nincs újabb
patch-elt verzió jelenleg, nyomon követve MITHOME-90 alatt.
Ellenőrizve ezen a commiton: npm run build, npm run lint, tsc --noEmit,
npm test (58 passed) — mind zöld. Az admin bejelentkezés/DB-kapcsolat
élő tesztje MongoDB-t igényel (jelen környezetben Docker daemon nem fut,
ez lokálisan `docker compose -f docker-compose.dev.yml up -d mongodb`
után `npm run dev` + http://localhost:3000/admin-mal ellenőrizhető).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- home.json gains a partners block (title/subtitle/items: name, url, logo),
rendered on the homepage under the services section (next/image logos
linking out with rel=noopener)
- CMS: partner logos uploadable from the 🎨 Logó page via POST /partner-logo
(PNG, 1 MiB cap, filename sanitized to a slug, written to public/partners/)
- schema + types extended; guide updated
Closes MITHOME-83
- pre-deploy suite now runs tsc --noEmit and eslint; any failure aborts
the release
- fix all TypeScript errors (FooterConfig.copyright removed after the CMS
move; test guards/casts)
- fix all ESLint errors: <a>→<Link> and <img>→<Image> in Header/Footer,
remove unused imports and explicit any in src
- eslint config relaxes no-explicit-any/no-require-imports/no-unused-vars
for test and CommonJS config files (legitimate usage)
Closes MITHOME-81
- siteConfig.ogImage pointed to an existing asset; metadataBase added so
relative OG/Twitter URLs resolve against the real origin instead of localhost
- Header sr-only menu label moved to common.json (a11y.openMenu/closeMenu);
navigation primary styling driven by a NavigationItem.primary flag instead
of brittle 'Kapcsolat' string comparisons
- remove dead code: lib/site-config.ts (unused hybrid config) and the
unused, schema-divergent siteConfig.contact.form
- ContactConfig type cleaned up (address/form removed)
Closes MITHOME-77
'Budapest, Magyarország' lived hardcoded in site.ts. It now lives in
common.json (footer.address), editable via the Közös szövegek tab, and both
consumers (Footer, Kapcsolat page) read it from there — single source.
Schema and types extended; site.ts keeps only the email.
Closes MITHOME-73
'Is the fix live?' becomes a single check instead of an SSH session:
- CMS: git short SHA read at startup, shown in the bottom bar (v<sha>),
served by the public GET /version endpoint, recorded in a startup audit
entry
- Website: deploy.sh exports DEPLOY_VERSION (git SHA), Dockerfile bakes it
via build ARG into the runtime env, /api/health reports it as
deployVersion, smoke test asserts a non-'unversioned' stamp
Closes MITHOME-63
- Add comprehensive design system with CSS variables, animations, and utility classes
- Implement dark mode with ThemeProvider (system preference + manual toggle)
- Create JSON-based content management system in src/content/
- Update all pages to use structured JSON content
- Add ThemeProvider component with theme toggle button
- Update Header with glass effect and animated mobile menu
- Update Footer with dark mode support
- Update documentation (README.md, CLAUDE.md, knowledge.md, proto/README.md)
- Sync with Linear (ZEE-29 completed)
- Updated README.md with project details, quick start instructions, and tech stack.
- Expanded TODO.md to reflect current project status and backlog items, including Linear ticket synchronization.
- Added mobile menu toggle functionality in Header component with corresponding tests for user interactions.
- Configured Next.js for Docker deployment and optimized build settings.
