7 Commits

Include renames

Author	SHA1	Message	Date
Do SikiandClaude Sonnet 5	e2b0c62628	test(cms): Payload config + Local API tests, fix stale Docker tests (MITHOME-96) ... Adds the two test categories the ticket asked for, replacing the old content-JSON-schema-only testing story now that Payload is the real source of truth: 1. src/payload-config.test.ts — fast, DB-free unit tests over the Collection/Global config objects themselves. WHY not importing payload.config.ts directly: it pulls in the real `payload` and `@payloadcms/db-mongodb` packages as values (not just types), which are ESM-only and Jest's default transformIgnorePatterns skips node_modules entirely — confirmed by trying it (`SyntaxError: Cannot use import statement outside a module` from payload's own dist). Individual collection/global files only ever `import type` from 'payload' (erased at compile time), so they're safely importable in isolation. Two of the assertions are deliberate regression guards for real bugs found earlier this session (MITHOME-121): Media.access.read must stay public, and Partners.logo must stay optional. 2. scripts/test-payload-local-api.ts (npm run test:payload) — exercises every src/lib/payload-content.ts getter plus a full create/findByID/delete cycle against a real, already-migrated MongoDB. WHY a plain node script instead of a Jest integration config: same ESM problem as above, and Payload's dependency graph is too broad to safely add to transformIgnorePatterns — this follows the same working `node --import tsx` pattern already used by migrate-content-to-payload.ts. Not wired into pre-deploy-tests.sh (needs a live, pre-migrated MongoDB, same reasoning as the removed CMS integration tests); run manually or before a release. 3. Fixed the pre-existing (Docker-stack-gated, so silently never caught) staleness in integration.test.ts and e2e-docker.test.ts: unprefixed routes (/rolunk) → locale-prefixed (/hu/rolunk), and Mongo assertions against the old site_config/contact_submissions collections → the real globals/legal-pages/partners/ contact-submissions collections Payload actually uses. Also fixed an unrelated stale error-message assertion for spam detection that never matched the route's real string. Verified: full gate green (tsc, lint, 63 unit tests — 13 new — build), and separately ran test:payload live against the dev MongoDB (8/8 passed, including the write/read/delete cycle actually hitting Mongo). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-12 16:37:57 +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	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	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