Rescuing an abandoned community site and making publishing a three-step job
Going Overtown had been left behind by its previous developer, was failing on unmaintained plugins, and had grown to 30 GB of hosting. We rebuilt it on owned code, cut the media library by 96%, and made posting an event something you finish in three steps.
See the live site →Going Overtown tells the story of today's Overtown, Miami: community news, a neighbourhood events calendar, a local business directory and a photo archive, run by a small team who are not web developers.
The site had been built on a premium directory theme and then abandoned by the developer who set it up. What was left behind still worked, technically, but nobody could extend it, several of its plugins had stopped being maintained, and it had quietly grown to 30 GB of hosting.
The brief was not a redesign. It was to make the site something its owner could actually run.
TheChallenge
Five problems, and only one of them was about how the site looked.
Abandoned. The developer who built it had moved on. Nobody who could change it was still involved, and the knowledge of how it fitted together had left with them.
Structurally stuck. A premium directory theme dictated what the site could be. Modern layout ideas could not be expressed without fighting it, and every add-on was another dependency on a vendor's roadmap.
Failing plugins. Parts of the stack had stopped being maintained and were throwing errors on current PHP. Unmaintained code on a public site is a security question, not a tidiness one.
Eating the hosting plan. Years of bulk uploads had pushed the media library to 30 GB, most of it files never placed on any page.
Too hard to post. The clearest requirement of all: publishing an event or a story had to take three steps, with nothing to memorise. If the owner has to keep notes on how to use her own website, the website is broken.
TheAnalysis
The governing decision was what to build and what to adopt. Custom code is a liability as much as an asset: every line of it is something somebody has to maintain later.
Adopt what is proven
Calendaring is a solved problem. The Events Calendar handles recurring events, venues, organisers, time zones and schema, and thousands of people maintain it. Writing our own would have been a year of work to arrive somewhere worse. The same logic applied to email: Mailchimp already does list management, segmentation and delivery properly.
Build only what is genuinely specific
What no plugin sells is the way this particular publication works: its neighbourhood structure, its sponsor placements, its four-week calendar view, its front-end submission flow. That is where custom code earns its keep, and it is the only place we wrote any.
Design the workflow before the interface
A three-step limit is a real design constraint, not a slogan. It rules out anything that needs a settings page, a taxonomy decision or a lookup table at the moment of publishing. Everything the site needs to know has to be inferred, defaulted, or asked for in plain language on one screen.
TheSolution
Getting off the abandoned stack
The premium directory theme and its add-ons were retired, and the listings they held were migrated into a directory we wrote and the client owns. Nothing the site depends on today is a product that can be discontinued out from under it.
Ten plugins, written for this publication
Each one exists because nothing off the shelf did the job, and each is small enough to read in an afternoon.
Contributors and the community submit stories and events from the site itself, without a WordPress admin login or a training session.
A rolling month view built on top of The Events Calendar rather than instead of it, so the data stays standard and the display fits the publication.
Local business listings, named rotating photo galleries with a front-end manager, and sponsor placements that the team schedules themselves.
Stages the weekly Mailchimp campaign from the site's own content against a saved template, so the newsletter is assembled from what was already published rather than rebuilt by hand.
A structured topic and resource library, so reference material can grow without becoming another pile of unstructured pages.
Reclaiming the hosting plan
Auditing an image library on a live site is easy to get wrong and expensive to get wrong. Candidates were identified two ways, then every single one was re-checked by searching its filename across post content, post meta, options, term meta, user meta and comment meta. That second pass rescued 5,168 attachments and 6,145 files that the first pass had called orphans. Only then was anything deleted.
TheResults
The site is owned, maintainable and small enough to host anywhere, and the person who runs it can publish without help.
This was a rescue, not a growth campaign. The measures that matter are what the site costs to keep, what it can be extended to do, and whether its owner can use it.
a 96% reduction
with zero failures
owned outright
nothing to memorise
Search performance is not claimed here. Traffic to the site was already declining before the rebuild and the work was commissioned to fix ownership, maintainability and workflow, not rankings. Publishing an honest zero is better than dressing up a number that will not survive being checked.
Do not reinvent the wheel because you can. Build the part nobody sells, and adopt everything else.
Inherited a site nobody can maintain?
We take over abandoned builds, retire what is failing, and hand back something you own.
