MUNKANAPLÓ / WORKLOG
Not a case study. An engineering worklog.
Finished systems hide most of the engineering work behind them. This log keeps the problems, wrong turns, fixes, trade-offs and verification steps that do not fit on a portfolio card.
103 of 103 entries are currently available in English. The remaining entries stay in Hungarian while translations are reviewed in batches.
18 entries ezen az pageon · 103 total
NIS2, ISO and TISAX should not become three separate evidence factories
Different frameworks often ask about the same underlying operation in different language. The goal was one evidence source for a shared control instead of three parallel collection processes.
Open entry →The handover test: does the process still work when I am not there to explain it?
At the end of several months of governance work, one of the strongest quality checks was whether someone else could follow the register and reporting process without an oral walkthrough.
Open entry →A timeline is only a row of dates until it shows dependencies
The management timeline had to show more than deadlines: it also needed to make visible which decision or piece of evidence was blocking the next milestone.
Open entry →In June, release engineering and governance turned out to use the same kind of thinking
The WordPress upgrade and audit work looked unrelated, yet both relied on the same fundamentals: source of truth, reproducibility, verification and a known path back.
Open entry →The first thing to remove from a working local config was the secrets
A reproducible Docker environment must not put database passwords and other sensitive values under version control. The WordPress configuration was moved to environment-driven inputs.
Open entry →The site worked in Docker — until WordPress tried to upload a file
The WordPress site loaded correctly, so the stack looked finished, but media uploads exposed a filesystem-permission mismatch between the host and the container.
Open entry →We suspected the plugins, but the missing piece was `.htaccess`
Odd routing behaviour after an update looked like a plugin compatibility problem. The actual fault was lower in the stack: required web-server rewrite configuration was missing.
Open entry →
Putting WordPress in Docker was not mainly about writing a Compose file
The legacy WordPress development environment moved into Docker. The real work was turning years of implicit server assumptions into explicit, reproducible configuration.
Open entry →A custom WordPress image should bake in the environment, not the entire project
A custom Docker image can quickly become a dumping ground. Runtime dependencies, project files and developer convenience tooling needed clear boundaries.
Open entry →A PHP limit is not a tuning detail when editors cannot upload media
Default PHP limits in the Dockerized WordPress stack did not reflect real usage. Upload and memory limits had to match production behaviour rather than being raised arbitrarily.
Open entry →WP-CLI belongs where WordPress actually runs
Running WP-CLI on the host would have introduced another PHP and tooling mismatch. I placed it in the same container runtime that the application itself used.
Open entry →Behind an HTTPS reverse proxy, WordPress can easily end up chasing its own redirects
The container saw HTTP while the browser used HTTPS. Without an explicit proxy boundary, WordPress could generate redirect loops and inconsistent asset URLs.
Open entry →A domain stored in the WordPress database always comes back to bite local development
A production database dump kept trying to redirect the local stack back to the live domain. Safe URL normalization became part of development startup.
Open entry →A startup script is useful only if it refuses to claim the system is ready when it is not
Local WordPress startup was scripted, but the important part was validating prerequisites and failing clearly instead of leaving developers with a half-ready stack.
Open entry →A good local environment is a documented model of production, not a production clone
We did not try to reproduce every production detail one-for-one in Docker. Instead, we documented what matched, what differed and which differences mattered to test reliability.
Open entry →Before an upgrade, test the backup instead of merely creating it
Ahead of major core and theme upgrades, the existence of a backup was not enough. Files and database had to be available together through a restore process we actually understood.
Open entry →By the end of May, WordPress had become an engineerable system instead of just a server
The month's biggest result was not a new feature. The legacy site gained a reproducible local runtime, practical tooling and a recovery-aware development history.
Open entry →Some problems should not be solved with code: where the audit boundary actually sits
Several open items already had enough technical evidence, but closure required an audit or legal decision. The important part was not turning every unresolved question into an engineering problem.
Open entry →No matching entry in the complete worklog.