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.
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.
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.