88 Commits

Include renames

Author	SHA1	Message	Date
Do SikiandClaude Sonnet 5	314b129259	feat(cms): "View site" link in admin header (MITHOME-97 follow-up) ... User request: there was no way to get from the Payload admin back to the public website — confirmed live (read_page on the admin nav showed only internal links: collections, globals, account, logout). Added a "🌐 Honlap megnyitása" link next to the QuickSearch box (src/components/admin/QuickSearch.tsx — same header slot, no new admin.components entry or importmap regen needed since the export name didn't change). Opens in a new tab, points at siteConfig.general.url (NEXT_PUBLIC_SITE_URL), so it resolves to the correct site per environment automatically — stage.mozdit.hu on staging, the production domain once that's live. Verified live in the browser: link renders next to the search box, resolves to the expected URL (find() confirmed the href), zero new console errors in a fresh tab. Gate: tsc, lint, unit tests (51 passed), production build all green. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-12 00:59:55 +02:00
Do SikiandClaude Sonnet 5	d207e5653e	fix(cms): make Partners.logo optional; fix Media read access (public site was broken) ... User request: don't force a logo upload to save a Partner — allow saving name+url first, logo later. Removed `required: true` from Partners.ts logo field. The frontend (getPartners(), payload-content.ts) already filters out logo-less partners before rendering, so this is safe: a partner without a logo just doesn't show on the public site yet, nothing breaks. While verifying this live (create a partner without a logo, check the public homepage doesn't break), found a real, previously-undetected bug that predates this change: partner logos never actually loaded on the public site at all. Payload's default collection read access is "authenticated users only" (Boolean(user)), and Media.ts never overrode it — so GET /api/media/file/<name> always 403'd for anyone not logged into the admin. Next.js's image optimizer (/_next/image) fetches that URL server-side without forwarding the browser's admin session cookie, so it always got a 403 back, which it reports as "The requested resource isn't a valid image" (400) — the <img> silently rendered as a broken image icon on the homepage the whole time. Fixed by adding `access: { read: () => true }` to Media.ts — write operations (create/update/delete) stay admin-only via Payload's default. Verified live in the browser: created a Partner with only name+url via the admin (saved successfully, no required-field error), confirmed it correctly does NOT appear on the public homepage (no logo yet), then deleted that test record. Separately, in a fresh unauthenticated tab, confirmed the existing Partner's logo now actually renders on /hu (previously a broken image icon) — curl-verified both /api/media/file/<name> and /_next/image?url=... return 200 without any auth. Zero console errors. Gate: tsc, lint, unit tests (51 passed), production build all green. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-12 00:41:42 +02:00
Do SikiandClaude Sonnet 5	74e40329a0	feat(cms): admin quick-search across all content (MITHOME-120) ... 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>	2026-09-12 00:03:13 +02:00
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	12b2711168	chore: retire legacy custom CMS (content-editor.js) (MITHOME-93) ... Removes the standalone, git-push-based content editor that predates Payload CMS: content-editor.js, its scripts/cms-*.js modules, its scripts/test-content-editor-*.js + scripts/test-cms-publish.js test suite, scripts/markdown-render.js (only used by the editor's guide renderer), the proto-side test doubles (cms-editor-client.test.ts, cms-editor-shortcuts.test.ts), and the editor's own user guide (docs/felhasznaloi-utmutato.md). Kept: proto/src/content/*.json (still the source for migrate-content-to-payload.ts and test fixtures for Header/Footer, per MITHOME-96), proto/src/content/schema.js + scripts/test-content-schema.js (still validate those JSON files), and docs/content-editor-recovery.md (historical incident record, not user-facing tool docs). Safety net before deletion (per user request): added proto/scripts/export-content-snapshot.ts, a reusable Payload Local API exporter, and ran it to produce docs/backups/payload-content-snapshot-*.json — a full hu/en snapshot of every Global + LegalPages + Partners document at the moment of retirement. Also confirmed no data-loss risk otherwise: .content-backups/ (the editor's own gitignored backup dir) tops out at 2026-08-23, well before today's fresh migration run, and every JSON edit ever made through the editor already exists as its own git commit ("content: frissítve a CMS-ből"). Updated dangling references: pre-deploy-tests.sh and .agent/steering/testing.md (dropped the CMS test block), .agent/workflows/deploy.md (publish flow is now Payload draft/publish, not git push), CLAUDE.md + .agent/AGENTS.md (dropped the /cms-feature workflow, deleted alongside it), README.md (stack description), .agent/steering/development-rules.md (the guide-maintenance rule no longer has a guide to maintain). Verified: tsc, lint, proto unit tests (51 passed), root test-content-schema.js, plane-sync unit tests, production build all green after the deletion. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-11 21:48:50 +02:00
Do SikiandClaude Sonnet 5	d445f0f31a	feat(cms): enable draft/publish + version history on Globals/Collections (MITHOME-92) ... Adds versions.drafts to all content-bearing Globals (Home, About, Services, Contact, Common) and Collections (LegalPages, Partners) via shared config in src/lib/payload-versions.ts. Media and Users are deliberately excluded (no draft workflow needed for uploads/auth). This is the direct successor to the old custom CMS's "Verziók panel" (MITHOME-64): the Payload admin now shows Save Draft / Publish changes and a Versions tab with history/diff/restore per document. Fixes a real bug found during manual verification: Payload's `_status` field defaults to 'draft' when a create/update call's data omits it, and that value is preserved on subsequent updates rather than being overwritten. Since migrate-content-to-payload.ts never passed `_status`, every migrated document ended up in draft status, which would have broken public pages once combined with any future explicit draft read. Fixed by explicitly setting `_status: 'published'` on every write in the migration script. Verified live in the browser: - Payload admin: Home global shows Status: Published, Save Draft / Publish changes buttons, Versions tab with history (draft -> current). - Saving a draft edit (title change, not published) does NOT change what /hu and /en render — confirmed by reloading the public page before publishing. - Publishing the change updates the public page as expected. - Full gate green: tsc, lint, tests (58 passed), production build. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-11 21:36:03 +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
Do SikiandClaude Sonnet 5	8407b45367	feat(cms): Users access control + lockout policy (MITHOME-90) ... Explicit, documented decisions instead of relying on implicit Payload defaults: - auth.maxLoginAttempts: 5, lockTime: 10 min — codifies the lockout policy rather than leaving it as an unstated library default. - auth.cookies: { secure: NODE_ENV === 'production', sameSite: 'Lax' } — secure cookies once behind HTTPS (MITHOME-15), harmless over plain HTTP in local dev. - access.{create,read,update,delete,unlock}: explicit requireAuthenticatedUser (== Payload's defaultAccess, Boolean(user)). Investigated the known open advisory flagged in MITHOME-86 (GHSA-jg8r-5jh2-v2xj — any authenticated user can unlock any other account) by reading Payload's unlock operation source: the gap only matters when a less-privileged authenticated identity exists that needs protecting from a more-privileged one. This project's single "admin" role model (no role hierarchy — MITHOME-85 epic decision) has no such identity, so the default is accepted as-is, with the reasoning and a MITHOME-46 (central IDM/SSO) revisit trigger written into the code comment rather than left implicit. - Added an optional `name` field for a nicer admin identity than a bare email (audit trail, header display). Verified live: existing dev@mozdit.hu user unaffected (name column shows "<No Name>", backward compatible). Reproduced the lockout for real — 5 wrong POST /api/users/login attempts, 6th attempt with the *correct* password still rejected ("locked due to too many failed login attempts"), unlocked via Local API (overrideAccess), then the correct password logged in successfully. build/lint/tsc/test (58 passed) all clean. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 13:26:41 +02:00
Do SikiandClaude Sonnet 5	fb11eff18b	docs(cms): note the manual pre-processing workflow on the Partners logo field ... Following the MITHOME-118 scope decision (cancelled — see Plane comment): partner logos are prepared with a free external tool (e.g. remove.bg) before upload, not edited inside Payload admin. Surface that expectation right on the field so an editor isn't looking for a crop/transparency tool that doesn't exist. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 13:16:14 +02:00
Do SikiandClaude Sonnet 5	6589289878	feat(cms): enable Payload localization — hu default + en (MITHOME-110) ... payload.config.ts: localization: { locales: ['hu','en'], defaultLocale: 'hu', fallback: true }. URL/routing side is separate (MITHOME-114). Proved the mechanism on a real field rather than a throwaway one: Common.buttons.* (contact/learnMore/webmail/sendMessage) marked localized: true — these are genuinely translatable UI labels, so this doubles as a first, correct slice of the full MITHOME-111 retrofit instead of being disposable test scaffolding. Gotcha discovered and documented in the migration script: marking an existing field `localized: true` after data was already written non- localized makes that value unreadable via `locale: defaultLocale` (the storage shape changed) — the migration script must be re-run so it gets rewritten under the localized shape. This will matter again for the full MITHOME-111/112 retrofit. Verified: Local API round-trip (set en, defaultLocale/hu re-seeded via re-running the migration script) — hu reads "Kapcsolatfelvétel", en reads "Contact". Real browser: admin UI locale switcher (hu/en) in the top bar, fields show "— hu"/"— en" per-locale labels, switching locale swaps the visible value correctly on the Common global editor. build/lint/tsc/test (58 passed) all clean. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 13:07:36 +02:00
Do SikiandClaude Sonnet 5	776fa66bc8	feat(cms): Partners + Media collection MVP (MITHOME-89) ... Payload built-in upload collection (Media) + a Partners collection (name, url, logo -> Media relationship) mirroring home.json's partners.items. Scope decision (see Plane MITHOME-89/118): the old logo editor (crop/rotate/transparent-background — MITHOME-76/84) is entirely client-side canvas logic (scripts/cms-logo-client.js, 345 lines), not server-side processing. Porting that UX into the Payload admin is a real custom React field component, split into its own ticket (MITHOME-118) rather than bundled here. This ticket covers plain upload only. - src/collections/Media.ts, src/collections/Partners.ts, registered in payload.config.ts. - migrate-content-to-payload.ts: upsertPartner() uploads the existing processed logo file (filePath) into Media (idempotent — matched by `alt` == partner name) and upserts the Partner document (matched by `name`). - .gitignore: Payload's default local upload storage lands at proto/media/ (not proto/public/) — runtime data, not source, needs a persistent volume in staging/production (flagged for MITHOME-97). Also ignored the generated src/payload-types.ts. Verified: migration run twice against the real dev MongoDB produced exactly 1 Media doc + 1 Partner doc (no duplicates, confirmed via mongosh) with the correct file size (12289 bytes, matching the source PNG). Real browser: logged into /admin, Partners list shows the migrated entry, and the document editor renders the logo thumbnail (270x80, 12KB) correctly. build/lint/tsc/test (58 passed) all clean. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 12:33:34 +02:00
Do SikiandClaude Sonnet 5	17c6d63ae3	feat(cms): LegalPages collection + migration (MITHOME-88) ... Slug-based collection mirroring LegalPageContent (proto/src/content/ types.ts) for the two legal pages (adatvedelem, hasznalati-feltetelek). - src/collections/LegalPages.ts: slug (unique), title, lastUpdated, sections[] (id/title/content). `content` stays a plain textarea, not lexical richText — the current frontend (src/app/(frontend)/adatvedelem/page.tsx) renders it through a hand-rolled "•"/"**bold**" regex converter, not a real Markdown/ richText parser, matching the same bootstrap-scope call made for Contact.gdpr.label in MITHOME-87. - Registered in payload.config.ts. - migrate-content-to-payload.ts: added an idempotent upsertLegalPage helper (find-by-slug, then update or create — Collections don't have Globals' fixed-slug updateGlobal) and seeded both legal pages from their existing JSON. Verified: migration run twice against the real dev MongoDB produced exactly 2 documents (no duplicates) — confirmed via mongosh. Real browser: logged into /admin, Legal Pages list shows both entries with correct titles/slugs, opened the adatvedelem document and the slug/ title/body fields all show the migrated content correctly. build/lint/ tsc/test (58 passed) all clean. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 12:16:09 +02:00
Do SikiandClaude Sonnet 5	a3d7e9ce75	chore(cms): disable Payload's anonymous telemetry ... Payload sends anonymous usage telemetry to its own servers by default. The site is self-hosted specifically so the client's data never leaves our own infrastructure (see the legal/GDPR discussion in chat) — that reasoning extends to Payload's own runtime telemetry too, so opt out via telemetry: false in payload.config.ts. Verified: build and dev server produce no telemetry notice, and the admin dashboard's network requests (checked in a real browser) are all to localhost — no outbound telemetry calls. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 10:52:54 +02:00
Do SikiandClaude Sonnet 5	3132fcb8eb	feat(cms): Home/About/Services/Contact/Common Globals + JSON migration (MITHOME-87) ... 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>	2026-09-10 03:41:03 +02:00
Do SikiandClaude Sonnet 5	3183098926	chore(deps): pin tsx 4.23.13 and add migrate:content script ... tsx 4.22.4 (the version resolved before this was an explicit dependency) fails on Node v25.6.1 with "T.registerHooks is not a function" — its CommonJS-require hook feature-detection finds node:module's registerHooks but calls it with a shape that version of Node no longer accepts. This broke both the `payload` CLI (needed for `generate:importmap`, see next commit) and would have broken `npm run migrate:content` (MITHOME-87) the same way. 4.23.13 fixes it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 03:40:24 +02:00
Do SikiandClaude Sonnet 5	a661739844	fix(cms): resolve double-root-layout conflict between the site and Payload admin ... 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>	2026-09-10 03:40:00 +02:00
Do SikiandClaude Sonnet 5	849acf4c34	fix(config): disable Next.js 16 auto-generated agent-rules files ... \`next dev\` (Next.js 16) writes proto/AGENTS.md and proto/CLAUDE.md on every run to brief AI agents on framework changes. This project already has its own agent instruction system (root CLAUDE.md -> .agent/) — a second, unrelated proto/CLAUDE.md stub would conflict with/shadow it for anyone working inside proto/. Disabled via agentRules: false. Verified live: MITHOME-86's admin route renders end-to-end against a real MongoDB (docker-compose.dev.yml mongodb service) — GET /admin 200 with the create-first-user flow, GET /api/users correctly 403s for an anonymous request, /api/health unaffected. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 03:19:25 +02:00
Do SikiandClaude Sonnet 5	1600d99c5d	feat(cms): Payload CMS bootstrap — config, MongoDB adapter, admin routes (MITHOME-86) ... 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>	2026-09-10 03:14:51 +02:00
Do SikiandClaude Sonnet 5	6cb99f603a	chore(deps): upgrade Next.js to 16.3.4 for Payload CMS compatibility ... Payload 3.88.0's peer range for `next` is >=15.2.9 <15.3.0 || >=15.3.9 <15.4.0 || >=15.4.11 <15.5.0 || >=16.2.6 <17.0.0 — the project's previous 15.5.23 fell in the unsupported gap between the 15.4.x and 16.2.x ranges. Upgrading to 16.3.4 (React 19.1.0 stays compatible) unblocks MITHOME-86. - next.config.ts: drop the removed `eslint.ignoreDuringBuilds` option (Next 16 no longer runs ESLint during `next build`) - eslint.config.mjs: import eslint-config-next's native flat-config arrays directly instead of bridging through FlatCompat, which threw "Converting circular structure to JSON" under ESLint 9 with the upgraded config - tsconfig.json: Next 16's own migration set `jsx: react-jsx` and added `.next/dev/types/**/*.ts` to `include` - ThemeProvider.tsx: suppress two react-hooks/set-state-in-effect false positives (new rule shipped with eslint-config-next 16) — these effects intentionally sync state from localStorage/DOM on mount, there is no subscription to move the setState into Verified: npm run build, npm run lint, tsc --noEmit, npm test (58 passed) all clean on this change alone, before installing Payload. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 03:04:54 +02:00
DO Siki	e9cb17ed67	content: frissítve a CMS-ből	2026-08-23 12:11:59 +02:00
Do Siki	4b48f27302	content: add Angele Pihenőház partner (logo + URL)	2026-08-23 11:41:13 +02:00
Do Siki	f65c22987f	feat: partners section on the homepage (logo + URL, CMS upload) ... - 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	2026-08-23 10:22:22 +02:00
Do Siki	410b4a2e2f	docs: refresh all documentation to the current state ... - agent docs: Linear (ZEE-*) → Plane (MITHOME-*) everywhere (task tracking, commit examples, workflows, env vars) - testing steering: replace the obsolete Gherkin/Linear reporting with the pre-deploy suite and the CMS test scripts - README: rewrite to Next.js 15, local deploy, Plane, CMS, security monitoring - DOCKER/proto docs: correct dev-stack ports (app 8080, mongo 27018) and Next.js 15 - content-editor-recovery: mark the old 'next steps' as done - mark clearly-obsolete Linear/GitHub-era guides as deprecated (banner) — LINEAR-SYNC, GITHUB-CICD/INTEGRATION, TEST-MANAGEMENT/REPORTING, traceability, sync-status analysis, requirements docs	2026-08-22 19:41:50 +02:00
DO Siki	46db2622d3	content: frissítve a CMS-ből	2026-08-22 13:39:29 +02:00
DO Siki	e715a3aa8b	content: frissítve a CMS-ből	2026-08-22 13:38:43 +02:00
Do Siki	d908f6b1b4	chore(quality): type-check and lint gates in pre-deploy, clean lint/tsc ... - 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	2026-08-22 12:37:22 +02:00
Do Siki	162e5782e9	refactor(cms): split oversized modules below the 400-line limit ... - content-editor.js: extract the /save handler to scripts/cms-save.js - cms-logo-page.js: inline the ~280-line canvas editor script to scripts/cms-logo-client.js (page is now the HTML/CSS shell only) - cms-editor-client.js: move the keyboard-shortcut section to scripts/cms-editor-shortcuts.js, inlined after the main client All modules now under the hard limit; full pre-deploy suite green. Closes MITHOME-80	2026-08-22 12:31:28 +02:00
Do Siki	15529c7705	fix: contact length limits + logger/next.config nitpicks + dep updates ... - /api/contact enforces per-field length caps (name/email/subject/message) before sanitization/persistence; over-long message returns 400 without touching Mongo (test added) - logger: crypto-based request id (randomUUID) instead of Math.random().substr; defaultMeta.version prefers DEPLOY_VERSION over npm_package_version - next.config: move Turbopack svg rule from deprecated experimental.turbo to top-level turbopack - deps: bump next 15.5.2 → 15.5.23; npm audit fix (19 → 3, remaining are transitive sharp/libvips DoS advisories, not exploitable for static images) Closes MITHOME-78, MITHOME-79	2026-08-22 12:22:27 +02:00
Do Siki	9f1fb349c2	fix(web): hygiene — OG image/metadataBase, Header a11y text + nav flag, dead code ... - 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	2026-08-22 12:12:48 +02:00
Do Siki	6030c48abb	feat(cms): keyboard shortcuts — Ctrl+S save, Ctrl+P publish, ? help ... - Ctrl/Cmd+S saves (native browser save dialog suppressed) - Ctrl/Cmd+P publishes; Ctrl/Cmd+Shift+V opens the Versions panel - '?' toggles a shortcuts overlay (Esc/click closes) - plain typing in inputs never triggers actions (modifiers required; '?' only outside editing targets) - jsdom regression tests run the real client script with dispatched KeyboardEvents; the client is evaluated once per suite because each eval would stack another keydown listener on the shared document Closes MITHOME-75	2026-08-19 22:52:09 +02:00
DO Siki	8f72b91fb1	content: frissítve a CMS-ből	2026-08-19 22:33:59 +02:00
DO Siki	2846edfa6e	content: frissítve a CMS-ből	2026-08-19 17:39:30 +02:00
Do Siki	02d6755874	test(footer): assert address from common.json instead of hardcoded city ... The footer address is CMS-editable now; the test must follow the single source instead of a fixed city.	2026-08-19 17:37:36 +02:00
DO Siki	d0270547cc	content: frissítve a CMS-ből	2026-08-19 17:12:37 +02:00
DO Siki	7b3bd2b78b	content: frissítve a CMS-ből	2026-08-19 17:12:35 +02:00
DO Siki	cb1084c0c7	content: frissítve a CMS-ből	2026-08-19 17:11:51 +02:00
DO Siki	3ba453d0a1	content: frissítve a CMS-ből	2026-08-19 17:11:49 +02:00
DO Siki	2ae5247cc6	content: frissítve a CMS-ből	2026-08-19 17:10:27 +02:00
DO Siki	7f4efbde98	content: frissítve a CMS-ből	2026-08-19 17:10:25 +02:00
DO Siki	ce14b6716b	content: frissítve a CMS-ből	2026-08-19 17:08:12 +02:00
DO Siki	6019b8b459	content: frissítve a CMS-ből	2026-08-19 17:08:10 +02:00
DO Siki	5ab3abba2a	content: frissítve a CMS-ből	2026-08-19 17:01:11 +02:00
Do Siki	9365c0f1ee	feat(footer): CMS-editable company address (common.json footer.address) ... '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	2026-08-19 16:53:16 +02:00
DO Siki	bbe0ff4c0a	content: frissítve a CMS-ből	2026-08-19 15:31:13 +02:00
DO Siki	d5e2023a1e	content: frissítve a CMS-ből	2026-08-19 15:31:12 +02:00
DO Siki	4a51585bb0	content: frissítve a CMS-ből	2026-08-19 15:29:24 +02:00
DO Siki	fd5e048c11	content: frissítve a CMS-ből	2026-08-19 15:29:22 +02:00
DO Siki	09228b6a6d	content: frissítve a CMS-ből	2026-08-19 15:17:00 +02:00
DO Siki	219f5122bd	content: frissítve a CMS-ből	2026-08-19 15:03:37 +02:00
Do Siki	5d2141ec88	fix(cms): capture array container before node removal so reindex runs ... The ❌ delete buttons called wrap.closest('.array-items') AFTER remove(); a detached node has no ancestors, so closest() returned null and reindexItems() silently skipped. Remaining items kept their old indices, collect() produced sparse arrays (null holes) and saves failed schema validation, e.g. '$.details.services[1].specs.items[0]: string érték szükséges'. Capture the container before remove() for both str-item and obj-card delete handlers. Regression test runs the real browser script in jsdom and clicks the actual delete buttons (nested string array + object card reindexing). Closes MITHOME-67	2026-08-19 13:30:53 +02:00