5 Commits

Include renames

Author	SHA1	Message	Date
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