- Sector
- Community · Automotive
- Year
- 2023
- Role
- Lead developer · rescue
- Outcome
- Google PageSpeed 31 → 89 · plugin hacks undone · CI/CD · moved to PaaS
What needed fixing.
The site worked the way a car with the oil light on works: fine until it isn't. Plugin code had been edited in place, so every update threatened to wipe the fixes. Performance was poor, the update path was broken, and there was no safety net — no CI, no clean environment, no way to make a change with confidence.
How I built it.
I undid the plugin hacks and rebuilt them as maintainable customisations so the update path worked again. I containerised the environment with Docker, moved the site to a managed PaaS, set up CI/CD, and worked through performance best practices — which took the Google PageSpeed score from 31 to 89. The result was a stable, fast, updatable site, and the foundation for the headless Drupal 11 rebuild that followed.
A car-collector social network held together by plugin hacks and optimism. Stabilised, sped up, and made updatable again — the prelude to a full rebuild.
- 01Stabilise a legacy WordPress community running on out-of-date core and plugins
- 02Undo in-place plugin hacks so the site can be updated safely
- 03Restore performance and a working deployment path
- 04Lay the groundwork for a future modern rebuild
- Plugin-hack removal — customisations rebuilt as maintainable, update-safe code
- Dockerised environment and migration to managed PaaS
- CI/CD set up where there had been none
- Performance work: Google PageSpeed 31 → 89
- A stable base for the Drupal 11 headless rebuild (see Eternalgarage v2)
A car community that had seized up
Eternalgarage is a social network for car collectors — profiles, galleries, garages, the back-and-forth of people who measure their weekends in restored sheet metal. It's a real community with real people in it, and by the time it reached me it had stopped turning over. Years of WordPress core, plugin and theme updates had been skipped. The site limped; the admin was afraid to touch it; and "launch" had quietly slipped off the calendar because nobody could promise the thing would still be standing the next morning.
The brief, stripped of politeness, was: make it safe to touch again. A site you can't update is a site that's already dying — it just hasn't been told yet. And it showed: a first load that crawled in at nearly three minutes, dragging forty plugins behind it. So the work wasn't a feature sprint. It was a revival: get it running, get it updatable, get the social layer behaving, and get it back to a launch you could actually stand behind.
The hacks underneath
The social network ran on BuddyPress, with Youzify and Mediapress layered on top — a stack that does an enormous amount out of the box and absolutely resents being edited from the inside. That, of course, is exactly what had happened. To force behaviour the plugins were never built for, someone had gone in and edited plugin internals directly. It worked, briefly, in the way a bolt-on supercharger works briefly on an engine that wasn't built for it. The cost was that the site could no longer be updated: every plugin update would silently overwrite the customisations and break things, so updates simply stopped. And once updates stop on a public WordPress site, the clock starts on security too.
Diagnosing that — separating the genuine custom behaviour the community depended on from the hacks that were holding it hostage — was most of the early work. You can't just revert to stock; people rely on what's there. You have to understand precisely what each modification was doing before you can move it somewhere it'll survive an update.
Putting the customisations back where they belong
So I unpicked the hacks one at a time and moved the behaviour out into the theme and the plugins' proper extension points — hooks, filters, child-theme overrides — the seams these tools give you precisely so you never have to edit them in place. Once the customisations lived outside the plugin code, the long-deferred work could finally happen safely: core, plugin and theme updates that had been frozen for years; custom-theme bug fixes; reworked feature and module behaviour; a handful of new features the community had been asking for; and a responsive theme that, at last, behaved on a phone instead of fighting it.
BuddyPress + Youzify + Mediapress — profiles, galleries, garages — with the customisations moved back out of plugin internals and into proper extension points.
The theme fixed to behave on a phone — where most of a car community actually lives.Off the floor and onto a platform
Stability isn't only a code problem. The site moved onto a proper PaaS with CI/CD, so deployments stopped being a manual act of faith over FTP and became something repeatable — push, build, deploy, and know what's running. With the updates landed and the hosting sane, I worked through the performance best practices the site had simply never had: caching, asset handling, image delivery, the unglamorous list that separates a fast site from a slow one.
The number that tells the story best is Google PageSpeed: 31 → 89. Same community, same content, finally running. Better-looking, far more stable, genuinely faster — and, the point of the whole exercise, a site its owners could run and update themselves without fear.
The rescue bought the time
A rescue isn't the destination — it's what you do so there's still a patient to treat. WordPress, stabilised and updatable, gave Eternalgarage room to breathe and a community that stayed. The long game was always a rebuild on a modern stack, and that became the next chapter: a headless-ready Drupal 11 platform carrying the same community forward. This card is the before. The build is the after.