Egy nap, húsz PR és százpontos Lighthouse: CyberTeam új alapokon

A helyzet

Reggel még a WordPressből átörökített CyberTeam.hu rendbetétele volt a cél. Az eredeti arculatot meg kellett tartani, de az elavult HTML-blokkok, a következetlen térközök, a hiányzó képes címsávok, a mobilos teljesítménygondok és a lokalizációs hibák nem maradhattak. A kapcsolatűrlap régi Contact Form 7 útvonala sem volt teljes bizonyossággal rekonstruálható; a megoldáshoz egyszerre kellett UX-, SEO-, adatvédelmi, üzemeltetési és fejlesztői szempontokat összehangolni. Eközben a KampányMűvek Engine és a Gödi Sittes CRM is kapott figyelmet. A nap végére a GitHubban húsz beolvasztott CyberTeam PR szerepelt – de a szám önmagában nem érdekelt: minden változáshoz ellenőrizhető műszaki indokot kerestünk.

A megoldási út

A problémákat nem egyetlen óriási átírással kezeltük. Kis, ellenőrizhető PR-ekben haladtunk: előbb tartalmi és vizuális konzisztencia, majd teljesítmény, biztonságos adatkezelés, egységes fejlesztői parancsok, blogmotor és dokumentáció. A GitHub PR-előzményét felhasználva a következő műszaki döntéseket és zsákutcákat érdemes rögzíteni:

1. WordPress-örökség helyett tiszta, egységes UI

A meglévő CyberTeam-dizájn értékét nem akartuk elveszíteni. A WordPress blokkstruktúrájának visszamásolása helyett saját CSS-ből rekonstruáltuk a hero-elemeket, a kék „Garancia a Biztonságra” címkét, a konzultációs CTA-kat, a NIS2-szekciót, a szolgáltatáskártyákat és az aloldali, képes címsávokat. Az IBF-oldal információs kártyáinak és kiemelőblokkjainak logikája alapján az eltérő aloldalakat is egységesítettük. Külön javítottuk a lábléc logóját, a kattintható telefon- és e-mail-hivatkozásokat, a hibás süti-szabályzati HTML-t és az akadálymentes navigációt. A cél a vizuális hűség volt, nem a régi függőségek konzerválása.

2. Három nyelv, valóban lefordított útvonalakkal

A magyar, angol és német változat nem állhatott meg három szöveggyűjteménynél. Szakmai szövegellenőrzés, pontosabb NIS2-megfogalmazások, lokalizált űrlapok, kereső, impresszum és navigáció készültek; az URL-ek nyelvenként természetes útvonalat kaptak, a régi linkekhez 301-es aliasokkal. A canonical, hreflang és sitemap kezelés az összes nyelvre kiterjed. Valós Chromium-böngészővel 30 lokalizált útvonalat négy viewporton – 320, 390, 768 és 1440 pixelen – ellenőriztünk. Ez 120 oldal–képernyőméret kombináció, amelyben a túlcsordulás, képek, gombok, fejlécek és láblécek sem maradhattak véletlenre.

3. 2,6 másodperces LCP-től a 100 pontos mobilmérésig

A Lighthouse körüli délelőtti vita abból indult, hogy a mobilos Largest Contentful Paint 2,6 másodperc körül volt, miközben a logó és a hero is gyanúsnak tűnt. Nem akartuk a dizájnt lebontani a pontszám kedvéért. A kritikus útvonalról lekerültek a mobilon feleslegesen előtöltött, több száz kilobájtos háttérképek; reszponzív WebP/AVIF-változatokat, szelektív preloadot és a hajtás alatti elemek késleltetett kirajzolását vezettük be. A vizuális regressziós ellenőrzést hozzá kellett igazítani ahhoz is, hogy a böngésző immár helyesen AVIF-ot szolgálhat ki, nem kizárólag WebP-t. A helyi mobil Performance-mérések 90, majd 97 és 99 után elérték a 100 pontot. Ez konkrét Lighthouse-futás eredménye, nem ígéret minden eszközre vagy hálózatra.

4. Kapcsolatűrlap PHP és állandó Node-szerver nélkül

Az örökölt Contact Form 7 címzetti és SMTP-útvonala nem volt teljesen bizonyítható; emiatt nem találgattunk e-mail-címeket. Ehelyett Apache CGI-re, Pythonra és msmtp-re építettünk saját küldési folyamatot, szerveroldali validációval, honeypot-védelemmel, rate limitinggel és TLS-ellenőrzéssel. Az SMTP-titkok védett, Gitből kizárt fájlban vannak, nem statikus HTML-ben vagy build-artefaktban. A `make mail-start` telepítési/indítási varázslót, a `make dev MAIL=1` pedig élő újratöltésű, valódi CGI/SMTP-vel tesztelhető fejlesztői módot ad. Az SMTP 0-s kilépése és `smtp_accepted` állapota a szolgáltatói átvételt igazolja; ezt tudatosan nem keverjük össze a címzett végső kézbesítésével.

5. A megkeresés nem veszhet el: SQLite-archívum

Egy működő e-mailküldés még nem üzembiztos ügyfélkezelés. A validált beküldéseket az SMTP-kísérlet előtt saját, nem publikus SQLite-archívumba mentjük, egyedi azonosítóval és kézbesítési státusszal. A nap végén két kényelmi, de szigorú hozzáférési feltételekkel működő parancs is készült: `make mail-inbox` a formázott termináltáblázathoz és `make mail-read ID=...` a teljes üzenethez. Külön fejlesztői archívum, olvasási jogosultságú SQL-kapcsolat, paraméterezett lekérdezés, szimbolikus linkek ellenőrzése és vezérlőkarakter-szűrés védi az adatokat. Nyolc célzott offline Python-teszt sikerült. Mentési és megőrzési szabályokat az éles üzemre továbbra is külön meg kell határozni.

6. Parancsdzsungel helyett Make-alapú fejlesztői platform

A nap során világossá vált: a kézzel összefűzött `git pull`, `npm run build` és Apache-indítás hosszú távon nem elfogadható fejlesztői felület. Docker-alapú dev/UAT/docs környezet, automatikus böngészőfrissítés, `make quality`, `make update`, diagnosztika és dokumentált Make-parancsok készültek. A `make update` piszkos working tree esetén szándékosan megáll, a levélküldés normál `make dev` alatt nem indul el véletlenül. Egy regresszió tanulságos volt: a vizuális tesztek régi WebP-only feltételezéseket tartalmaztak, ezért a helyes AVIF-kiszolgálás után is hibáztak. A tesztet javítottuk, nem a működő képoptimalizálást kapcsoltuk ki. Különválasztottuk a Docker, a natív macOS Apache és a production üzem életciklusát.

7. Új Engine-verzió és háromnyelvű tudástár

A CyberTeamnek szakmai tudástár kell, de üres demóbejegyzésekkel nem akartuk látszólag feltölteni. Az Engine strukturált blogregiszterére építettük a magyar, angol és német tudástár-oldalakat, keresési és SEO-kapcsolódásokkal. Ehhez maga a KampányMűvek Engine is továbbfejlődött: megérkezett a `4.0.0-alpha.17`, amelyet teljes, SHA-256-tal ellenőrzött rögzített kiadásként integráltunk. A bloginfrastruktúra kész, a tényleges szakmai bejegyzések külön tartalmi feladatot jelentenek. Az általánosítható képesség az Engine-ben maradt, a CyberTeam csak saját konfigurációval használja.

8. Google Analytics: előkészítés, nem készre jelentett mérés

Megvizsgáltuk, volt-e az eredeti WordPress-oldalon használható Google-mérés. A Site Kit nyomaiból azonosíthatóvá vált a korábbi GA4-adatfolyam, ezért nem kell indokolatlanul újat létrehozni. Külön PR készült a hozzájáruláshoz kötött betöltés, a konzisztens `cta_click` események és a sikeres kapcsolatfelvételhez kapcsolódó `generate_lead` logikájának előkészítésére. A Google-fiókban a kulcsesemények és dimenziók beállítása az ügyfélre vár; a PR a napló összeállításakor még nyitott volt. Űrlapmezőket, telefonszámokat és üzenettörzseket nem küldünk analitikába.

9. Dokumentáció és párhuzamos CRM-üzem

Végül a magyar és angol fejlesztői kézikönyvet, architektúrát, Make-referenciát, kapcsolatűrlap-leírást és dokumentációs hivatkozásokat is aktualizáltuk, eltávolítva az elavult utasításokat. Közben a Gödi Sittes CRM is előkerült egy új érdeklődő adminisztrációja miatt: szerveren futtatható importszkriptet terveztünk/adtunk hozzá, de ezt nem keverjük a CyberTeam kiadásával. Egy ilyen napon a valódi fegyelem nem pusztán a sebesség, hanem az, hogy a párhuzamos projektek adatai és telepítési folyamatai elkülönítve maradjanak.

Mi lett belőle

A CyberTeam repóban húsz pull request került be a main ágba 2026. október 13-án; a szerkesztői felület három nyelven, egységes arculattal és lokalizált útvonalakkal készült tovább. A mobilos Lighthouse Performance a helyi ellenőrzésen elérte a 100/100-at. Saját Apache CGI/SMTP-alapú kapcsolatűrlap, privát SQLite-archívum és célzottan tesztelt Make parancsok állnak rendelkezésre. Az új KampányMűvek Engine 4.0.0-alpha.17 a háromnyelvű blogot is megalapozta. A Google-eseménykövetés integrációjának ellenőrzése és a CyberTeam production deploy külön, következő lépés: egy main merge nem jelent automatikusan éles működést. Az eredményeknél ezért különválasztjuk a fejlesztői tesztet, az SMTP-átadást és a valódi production-ellenőrzést.