200 Commits

This Branch

This Branch

All Branches

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	c07ec2298c	sync: add MITHOME-121 to TODO.md (Partners logo optional + Media access fix) ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-12 00:51:16 +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	02a73b3702	sync: mark MITHOME-120 done in TODO.md ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-12 00:05:06 +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	3f72d714df	sync: add cms.stage.llmdev.mozdit.hu nginx vhost log entry to TODO.md ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-11 23:33:33 +02:00
Do SikiandClaude Sonnet 5	265b656df9	docs: document the cms.stage.llmdev.mozdit.hu nginx vhost (MITHOME-97 follow-up) ... Server-side nginx config isn't tracked anywhere in this repo, which is exactly how an orphaned vhost went unnoticed: it used to reverse-proxy to the old CMS (content-editor.js, port 4001), retired in MITHOME-93. After that service was stopped/disabled, the vhost silently kept serving its still-valid TLS cert as nginx's apparent fallback for any unmatched *.mozdit.hu subdomain — which is what produced a real-looking (but harmless) Firefox "this site may be impersonating" warning when the user mistyped a URL. Repointed the vhost (server-side, not in this repo) to reverse-proxy /admin, /api/ and /_next/ to the same staging app container Payload already runs on (127.0.0.1:8081) — same backend as stage.mozdit.hu, just a friendlier admin-specific URL. Root redirects straight to /admin; anything else redirects to the canonical stage.mozdit.hu to avoid serving the public site twice. Reused the existing Let's Encrypt cert (no new certbot run needed). This commit only adds docs/nginx-vhosts.md, documenting what's live on the server and why, since nginx config itself isn't part of this repo's source of truth. Verified live: TLS cert now matches cms.stage.llmdev.mozdit.hu (no more mismatch warning), GET / redirects to /admin (302), GET /admin returns 200 with correctly loaded assets (checked in a real browser, zero console errors), GET /rolunk redirects to stage.mozdit.hu, GET /api/health proxies through correctly, and POST /api/users/login with the real staging admin credentials returns 200 through this domain too. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-11 23:33:01 +02:00
Do SikiandClaude Sonnet 5	00d2b82877	sync: add MITHOME-97 admin-seed follow-up log entry to TODO.md ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-11 23:21:17 +02:00
Do SikiandClaude Sonnet 5	729268a3fe	feat(deploy): auto-seed a known Payload admin user on every deploy ... Follow-up to MITHOME-97: after every deploy, a brand-new database (first-ever deploy, or a volume wipe) leaves the Payload admin behind the "Create first user" screen — someone has to notice and fill it in by hand, which means environments can silently end up with no known admin credentials, or with whatever a random person happened to type in at the time. deploy.sh now calls Payload's built-in `POST /api/users/first-register` REST endpoint right after the healthcheck passes, using ADMIN_EMAIL / ADMIN_PASSWORD from the environment's .env file. That endpoint only succeeds when the `users` collection is completely empty (throws 403 Forbidden otherwise) — which makes this naturally idempotent: the first deploy against a fresh database creates the known admin, every later deploy gets a harmless 403 and skips it. It never overwrites an existing user's password. Missing ADMIN_EMAIL/ADMIN_PASSWORD in the env file just skips the step with a warning, it doesn't fail the deploy. Documented the new variables in .env.staging.example and .env.production.example (next to the existing PAYLOAD_SECRET instructions), and the new deploy.sh step 4 in .agent/workflows/deploy.md. Also dropped a stale "Content Editor is staging feliratot kap" line from the same doc (that behavior belonged to the CMS retired in MITHOME-93 and no longer exists). Verified locally against real Payload instances (not just reading the code): a fresh, empty MongoDB returns 200 and creates the user; a second call against the same now-non-empty database returns 403 and changes nothing; a database that already had a different user (the existing dev DB) also correctly returns 403. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-11 23:12:12 +02:00
Do SikiandClaude Sonnet 5	94647d5293	sync: mark MITHOME-97 done, add MITHOME-92/93/97 log entries to TODO.md ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-11 22:52:53 +02:00
Do SikiandClaude Sonnet 5	d8cccc1a65	fix(deploy): drop stale content-editor systemd restart from staging script ... scripts/deploy_to_stage_on_local.sh restarted a "mozdit-content-editor.service" systemd unit after every staging deploy — the old custom CMS's own service (content-editor.js, retired in MITHOME-93). Left in place, the next staging deploy would pull the commit that deletes content-editor.js and then try to restart a service pointing at a now-missing script. Removed the restart from the deploy script; the server-side systemd unit itself (if still installed) needs a manual stop/disable — out of reach from here (no SSH access in this session), flagging it to the user instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-11 22:13:47 +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	19622d9703	sync: mark MITHOME-93 done in TODO.md ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-11 21:50:00 +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	21a0d73639	sync: mark MITHOME-92 done in TODO.md ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-11 21:36:49 +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	b5590175b7	sync: mark MITHOME-91 + MITHOME-114 done in TODO.md ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 16:16:47 +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	594865ea9a	sync: mark MITHOME-90 done, add MITHOME-119 (MFA prep) to TODO.md ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 13:28:57 +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	71ab1e08ac	sync: mark MITHOME-118 cancelled in TODO.md ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 13:17:00 +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	30f271651a	sync: mark MITHOME-110 done in TODO.md ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 13:08:07 +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	1b587ac373	sync: mark MITHOME-89 done, add MITHOME-118 to TODO.md ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 12:34:25 +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	928439bc7b	sync: add MITHOME-117 visual design-protection ticket ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 12:25:18 +02:00
Do SikiandClaude Sonnet 5	1c9e231a16	sync: add localization epic (MITHOME-109..116) to TODO.md ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 12:22:08 +02:00
Do SikiandClaude Sonnet 5	329269aeb1	sync: mark MITHOME-88 done in TODO.md ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 12:16:35 +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	570f4b45e5	docs: add program-hid-update skill for the Program Híd artifact ... Project-scoped Claude Code skill that re-queries the MITHOME and PLATFM Plane projects, recomputes the roadmap-phase/bridge/epic-progress data, and republishes the same Program Híd artifact (claude.ai/code/artifact/95d7def2-c648-4fb7-a3f3-0d172b1c21ab) in place. Includes the canonical artifact source (source.html) so future runs edit a versioned file instead of a session-local scratchpad copy. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 12:05:23 +02:00
Do SikiandClaude Sonnet 5	91a9d97a59	docs: note PLATFM-1 program-level convergence map in TODO.md ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 11:52:54 +02:00
Do SikiandClaude Sonnet 5	72a5a10476	sync: reconcile Hermes epic with PLATFM-10/PLATFM-12 ... MITHOME-99 (Hermes Agent EPIC) and its 6 pure-AI-pilot subtasks (MITHOME-100/101/104/106/107/108) duplicated work already planned under PLATFM-10 (managed AI features pilot). Cancelled them in Plane, linked to PLATFM-10 and the new PLATFM-12 engine-choice ADR. The genuine MITHOME-side responsibility (the website's own event source) survives as MITHOME-102/103/105, reparented under the Payload epic (MITHOME-85) and reworded to target a PLATFM-2-compatible event schema (idempotencyKey, eventType, data) instead of a Hermes-specific webhook. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 11:44:26 +02:00
Do SikiandClaude Sonnet 5	c4e3d91640	sync: add Hermes Agent epic (MITHOME-99..108) to TODO.md ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 11:03:37 +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	db2f38743f	sync: mark MITHOME-98 done in TODO.md ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 10:39:58 +02:00
Do SikiandClaude Sonnet 5	4c54c639e5	fix(docker): authenticate the dev app's MongoDB URI (MITHOME-98) ... docker-compose.dev.yml's mongodb service sets MONGO_INITDB_ROOT_USERNAME/ PASSWORD, which makes the official mongo image enable --auth — but the app service's MONGODB_URI was unauthenticated (mongodb://mongodb:27017/mozdit). Same bug class as MITHOME-32 (staging/production), but that ticket covers docker-compose.staging.yml /docker-compose.prod.yml specifically, not this dev file — hence the separate MITHOME-98. Why /api/health never caught it: that route is a pure liveness check and never touches MongoDB. Only an endpoint that actually performs a DB operation exercises the bug. Verified live (docker compose -f docker-compose.dev.yml up --build): - Reproduced the failure first: inside the running app container, a plain `mongodb://mongodb:27017/mozdit` connection's findOne() throws "Command find requires authentication" — confirms the hypothesis that the app fails only on a real query, not at startup. - With the fix in place: POST /api/contact returns 200 with a submissionId, and the document is actually present in contact_submissions (checked via mongosh) — a real, previously- broken write path now works end to end. - npm test: 58/58 passed (unaffected, as expected for a docker-compose/doc-only change). Also fixed the same stale unauthenticated example in DOCKER.md. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 10:39:29 +02:00
Do SikiandClaude Sonnet 5	018a1f2767	sync: mark MITHOME-87 done in TODO.md ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 03:42:12 +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	2a4f33172b	sync: mark MITHOME-86 done in TODO.md ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 03:21:32 +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	30364fcab7	sync: update TODO.md with Payload CMS epic (MITHOME-85..97) ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-10 03:14:31 +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	38be6c0450	sync: update TODO.md with MITHOME-84 (make-transparent)	2026-08-23 11:47:25 +02:00
Do Siki	b56b81b2ba	feat(cms): make-transparent (remove white background) in the logo editor ... Adds a ⚪ Háttér átlátszóvá (fehér) button to the canvas editor. Pixels above a luminance threshold become fully transparent; a soft ramp just below keeps edges smooth. Lets white-background partner/site logos sit on any page background. Closes MITHOME-84	2026-08-23 11:46:29 +02:00
Do Siki	f6846ad217	test(cms): partner-logo test uses unique names and only cleans its own files ... The previous cleanup emptied proto/public/partners/ entirely, deleting real committed partner logos during the pre-deploy run. Now the test uploads to unique run-specific filenames and removes only those.	2026-08-23 11:42:24 +02:00