KampányMűvek / CyberTeam / 13 October 2026

One day, twenty PRs, and a perfect mobile Lighthouse score: rebuilding CyberTeam

Twenty CyberTeam pull requests merged in one development day: a three-language WordPress migration, consistent UI, a measured 100/100 local mobile Lighthouse result, Apache CGI/SMTP, private SQLite archiving, Make-driven developer tooling, and KampányMűvek Engine 4.0.0-alpha.17. Production deployment remains a separate, verified operation.

6 min read
KampányMűvekCyberTeamDevOpsWeb Performance
WordPress migrationi18nLighthouse 100WebPAVIFApache CGISMTPSQLiteMakefileDockerKampányMűvek EngineGA4
Screenshot of the CyberTeam.hu homepage on 13 October 2026 showing a dark blue header, multilingual navigation, cybersecurity hero photography and teal consultation buttons.
The CyberTeam homepage from the supplied screenshot: familiar brand design on a substantially reworked technical foundation.

Situation

The day began with a familiar migration problem: keep the recognisable CyberTeam.hu visual identity, but remove inherited WordPress fragility. Inconsistent spacing, missing background banners, outdated blocks, poor mobile critical-path performance and partial localisation needed attention. The original Contact Form 7 destination and mail routing could not be reconstructed with complete certainty; solving the problem had to account for security, accessibility, SEO, deployment and maintainability at once. The reusable KampányMűvek Engine and a separate Gödi Sittes CRM task also entered the picture. By the end of the day twenty CyberTeam pull requests had merged, but each change was evaluated on engineering evidence, not on the number of commits.

Approach

We deliberately avoided a single wholesale rewrite. Small, reviewable pull requests progressed from content and visual consistency through performance and secure contact handling to developer experience, the publishing engine and documentation. Here is the engineering trail, including the assumptions that proved wrong:

1. Consistent UI without preserving the WordPress dependency

The original brand and page composition were worth keeping; the old block HTML was not. We rebuilt hero elements, the blue security promise label, consultation calls to action, NIS2 sections, service cards and inner-page banner images using clean CSS. Information cards and highlighted blocks were standardised based on the better existing IBF page. We separately repaired the footer logo, click-to-call and email links, broken cookie-policy markup and accessible navigation. Visual fidelity was the requirement, not retaining the legacy implementation.

2. Three languages with genuinely localised routes

Hungarian, English and German required more than three sets of strings. We reviewed professional wording, improved NIS2 claims, localised forms, navigation, search and legal pages, and introduced natural language-specific URLs with 301 aliases for older routes. Canonicals, hreflang and sitemaps cover the language variants. Real Chromium visual QA visited 30 localised routes across 320, 390, 768 and 1440 pixel viewports: 120 page/viewport combinations checking overflow, assets, buttons, navigation and footers.

3. From 2.6-second LCP to a measured 100 on mobile

A local Largest Contentful Paint reading of roughly 2.6 seconds put the logo and hero under suspicion. Instead of sacrificing the design for a metric, we removed unnecessary heavyweight mobile background images from the critical path, introduced responsive WebP/AVIF sources, made preloading selective and deferred below-the-fold painting. The test suite had to be corrected too: old WebP-only assertions failed once browsers legitimately selected AVIF. Reported local mobile Lighthouse Performance scores rose through 90, 97 and 99 to 100. That is a measured result in a specific environment, not a promise about all devices or networks.

4. A contact form without PHP or an always-on Node server

The historical Contact Form 7 recipient and SMTP configuration could not be proven, so we did not guess. We implemented Apache CGI with Python and msmtp, plus server-side validation, honeypot spam checks, rate limits and validated TLS transport. Secrets stay in protected, Git-ignored local configuration instead of generated static assets. `make mail-start` provides a guided local setup; `make dev MAIL=1` enables live reload with a functioning CGI/SMTP path. A zero exit code and `smtp_accepted` establish SMTP acceptance, not final arrival in the recipient mailbox.

5. An inquiry must survive an email problem: SQLite

Reliable business intake cannot rely on an email handoff alone. Validated submissions are archived in a private SQLite database before attempting SMTP, with identifiers and delivery states. New commands `make mail-inbox` and `make mail-read ID=...` display submissions and their complete details in the terminal. Separate development storage, read-only SQL access, parameterised queries, path and symlink checks and sanitised terminal output prevent convenient administration from becoming an information leak. Eight focused offline Python tests passed. Production backup and retention decisions still need their own operational review.

6. From fragile shell sequences to a Make-driven workflow

A routine built around remembering `git pull`, `npm run build` and Apache setup commands becomes a maintenance liability. We added Docker-based development, UAT and documentation environments, browser auto-reload, `make quality`, `make update` and diagnostic commands. The update command refuses to overwrite dirty working trees; the ordinary `make dev` does not send emails by accident. One useful regression involved visual assertions that only expected WebP; we fixed the outdated assertions, not the correct AVIF optimisation. Native macOS Apache, Docker development and production now have deliberately separate lifecycles.

7. A new Engine release and multilingual knowledge hub

CyberTeam needs a professional knowledge hub, but not empty filler posts. The Hungarian, English and German knowledge-hub pages use the Engine's structured content registry, with search and SEO integration. The reusable feature required an Engine upgrade to `4.0.0-alpha.17`, pinned with SHA-256 integrity verification. The infrastructure is ready while actual editorial posts are a separate next step. Shared functionality belongs in the central Engine; the site supplies its own configuration.

8. Google Analytics preparation, not prematurely claimed measurement

We looked for measurement already present in the original WordPress site before creating a new GA4 stream. Historical Site Kit integration revealed the existing data stream. A separate pull request prepares consent-gated analytics loading, consistent `cta_click` events and `generate_lead` for successful contact submission. Client-side Google account configuration, including key events and custom dimensions, remains outstanding; the pull request was still open when these notes were compiled. Personal form fields, phone numbers and message bodies must not go into analytics events.

9. Documentation and a separate CRM task

We refreshed the Hungarian and English developer handbook, architecture, Make reference, email operations and internal documentation links, removing obsolete instructions. A new inquiry also prompted work on a server-side Gödi Sittes CRM import script. Crucially, this separate operational task was not conflated with CyberTeam's release. Fast parallel work only remains safe if data, credentials and deployment boundaries stay explicit.

Outcome

Twenty CyberTeam pull requests merged into main on 13 October 2026. The site now has more consistent presentation across three languages and localised routing; local mobile Lighthouse Performance reached a measured 100/100. Apache CGI/SMTP contact handling, a private SQLite archive and tested Make commands provide clearer operational foundations. KampányMűvek Engine 4.0.0-alpha.17 supports the multilingual publishing infrastructure. Consent-based GA4 event tracking still required review, and CyberTeam production deployment was a separate future action. A merged pull request is not automatically a deployed release; local test success, SMTP acceptance and live production validation are explicitly different kinds of evidence.