Ady Voltedge

WordPress Multisite

About the Project

Ady Voltedge is a business with now over 40+ client websites. When they came to me, each individual website was managed by a fork of a homebrewed CMS. This meant anytime one bit of code needed changing, it needed to be deployed 40 times. Just that fact alone made their current way of doing things un-maintainable.

My Role

My job was to re-build the CMS functionality on a WordPress Multisite installation which made sure every site was running from the same core code. One update = one deploy. I had to not only make sure all of the data was migrated correctly, I also had to deal with a bot-net attack after their old CMS's SQL injection vulnerabilities were discovered.

The Problem

Previously, Ady Voltedge managed their 40 websites by running them off of individual copies of a home-brewed CMS. This CMS was impressive at the time it was developed and featured a front-end editing tool that allowed users to click on content and make inline edits with TinyMCE to their hearts desire.

The major issue with the CMS was the fact that it was not centrally managed.
Every-time one bit of code was edited, the change had to be deployed to every one of the 40 websites individually.

There were also SQL-injection flaws, and maintenance on the CMS was costing Ady Voltedge about as much as hiring a full time developer to re-develop the CMS from scratch would have cost. So that’s what they did.

WordPress to the Rescue!

I chose to develop their CMS from the ground up using WordPress Multisite as a solution to their fragmented CMS issue. Each site had a different design, but the Back-End architecture was very similar. I created the base theme structure and was converting, on average, one site per day over to the Multisite.

Custom field Development

At the core, each website was a different commercial property management system for counties. This meant the core of the system needed to have a mapping component. Advanced Custom Fields did not yet have a mapping field (they have since added one).

I developed a Custom Field for the mapping plugin which would take an address, geocode it, and place it on a map.

If the geocoding is not accurate enough, or if the user doesn’t have an exact address, they can then drag the marker and get live updated results of the geoposition.


Things were going well.

Then their old CMS was hacked using a known SQL-injection because none of the SQL queries were being sanitized.

We woke up one morning to find their old CMS hacked and within hours, every domain running the old CMS was compromised.

At this point we had to completely ditch the old CMS and convert every single website to the new WordPress Multisite as quickly as possible. Using Multisite’s handy subdomain configuration, each site was able to have its own domain to be managed by individual administrators unique to that site.

Hardening WordPress

The attacks did not stop once WordPress was installed. WordPress, at its core, is incredibly secure, and most vulnerabilities come from insecure plugins people choose to install.

Even though we now had a secure CMS, the server itself was not running at top speed. Thanks to some network analysis using Wordfence, we were able to identify a botnet that was specifically targeted at these domains.

Attempts for "user" logins. Clearly something was fishy.
Attempts for “user” logins. Clearly something was fishy.

We were under a brute force attack. I’ve since written a blog post on Securing WordPress beyond the default security.

Once we took additional measures to ban bot nets, the site performance was boosted greatly. Response times went from 30000+ ms back to the usual 300 – 500 ms.


As of writing this in July 2014, almost a year later, over one million brute force attempts have been blocked.