I maintain the WordPress site of the FeelMore nature-focused accommodation network, running in five languages (Hungarian, English, Romanian, Slovak, German): six operating locations and several more being built, a filterable interactive map, booking per location and a franchise programme. The site grows with every new location.
The challenge
FeelMore is a growing accommodation network with six operating locations (Nagylóc-Hollókő, Eger, Szarvas, Pusztakisfalu, Békésszentandrás and Karancsalja), several more under construction, and a franchise programme that keeps bringing new ones. The site runs in five languages: Hungarian, English, Romanian, Slovak and German. I did not build the site. I took it over, and I am responsible for maintaining and developing it.
My contribution
- Takeover: mapping the existing system: a custom map plugin, JetEngine-based content types, separate header and footer templates for every language.
- Ongoing fixes on the live site, with a backup and a restore point before every intervention.
- Fixing the interactive map: page scrolling no longer gets trapped inside the map, and nearby locations now appear clustered.
- Unifying brand elements across the headers of all five languages. What is one setting on a single-language site is the same change in fourteen places here.
- Removing a redundant caching plugin so that two systems no longer work against each other.
The result
The site stays extensible: adding a new location is not a developer task, the map and the listings follow it on their own. And fixes ship without any one of the five languages drifting away from the others.
Why a five-language site is harder to maintain
On a single-language site the header is one template. Here there is a separate header and footer per language, plus separate mobile menus. A logo swap or a font-size adjustment therefore means fourteen changes, and if one is missed, the error stays on exactly the language I check least often. That is why every header-level change is done from a list: every template, every language, checked one by one.
A custom plugin: blessing and risk
The locations are shown on a custom, Leaflet-based map with filters: jacuzzi, sauna, dog friendly, forest, waterside, panorama. It does exactly what this site needs and does not depend on an external provider. In exchange it is custom code: there are no vendor updates, and its bugs are ours to find and fix. On takeover, the first thing I did was read through and back up the plugin, before any modification.
Fixing on a live site, with a net
For this site a full local copy is not worth it: the media library is large, the database is large, and licensed plugins do not activate on a copy. Front-end fixes therefore happen live, but not without a net: a database export before the intervention, editor revisions as a restore point, and a copy of every modified file. What matters is having somewhere to step back to, not where the fix takes place.
A network's site is not a single property's site
A guesthouse site can stay unchanged for years. A growing network's cannot: a new location arrives, another moves from "under construction" to bookable, the franchise programme targets a new country. On a site like this, maintenance means updates and security, and also a structure that can carry the growth. Adding a new location should stay data entry, with no development needed.



