FloeWater

FloeWater is HELL Energy's premium mineral water brand. Milcomp builds and operates the brand's international site, in five languages.

The challenge

On an international brand site the language versions are not translations, they are separate markets: a different product range, different legal content, different contact routing. If each language is its own website the brand drifts apart and maintenance multiplies; if it is one site with translations, market differences cannot be expressed at all.

The solution

WordPress Multisite in subdirectory mode: English at the root, with Hungarian, Romanian, Bulgarian and Croatian each in their own subdirectory, sharing a theme and media handling but holding their own content. The brand's appearance lives in the shared theme, so a design change reaches every market at once.

The contact forms got language-aware recipient routing: an enquiry is directed to the right department based on the language and the area selected, and the sender receives an automatic acknowledgement in their own language. On a brand site that is not a detail - a misrouted enquiry is a lost enquiry.

Technology

WordPress Multisite with a custom child theme on top of a Milcomp-maintained base theme, built on Bootstrap. Content blocks are driven by custom fields, search optimisation by Yoast, and delivery by a page cache plus the Cloudflare edge. The presentation microsite runs alongside as separate static content.

When the deployment is also the code

Releases are a git push: the Jenkins workspace is the served code, because the web server's theme directory is a symlink into the build workspace. That is fast and transparent, but it has a consequence worth knowing.

WordPress's own automatic updates write into that same directory, as a different user. After that the build can no longer overwrite the files - and, crucially, a half-failed release still updates every file it can: the site serves new code while the build goes red, and the permission-repair step never runs at all. The fix was to take WordPress-managed directories out of version control entirely.

What to take from this

If the build workspace is the live code, then every process that can write into that directory is part of your release process - including the ones you did not start. Either exclude them or account for them.

The other one: on a cached site, a content fix is not finished when you press save. Two layers have to be cleared here, the page cache and the edge, because the edge caches HTML too - and the SEO plugin stores social preview images in its own tables, so changing the database directly does not invalidate them.