Arthur C. Clarke famously said, “Any sufficiently advanced technology is indistinguishable from magic.” That’s always been one of our favorite quotes. We love making stuff that looks like magic. But even more than that, we like understanding how it works under the hood. If you’re wondering how we did it, here are some of the geeky details.
Creating a Staging Site
Jonathan, our founder and systems administration whiz, has always had the mantra “If you have to do something more than twice, automate it.” When his partner, Morgan, started building a lot of WordPress sites for clients, she was constantly asking him to create new development sites for her. He didn’t want to do that over and over, so he wrote a script for her. All she had to do was type in one command on the development server, and the script would automatically download the latest version of WordPress, create a database, configure the wp-config.php file, and set up the DNS.
When Jonathan set out to create WP Stagecoach, all he had to do was modify those scripts. (“All”, we say, as if this were trivial for anyone but Jonathan!)
When you click that little “ride the stagecoach” button to make your sandbox site, WP Stagecoach takes all the site files and compresses them into a single file, and then transfers that to WP Stagecoach’s servers. Of course, some sites have gigabytes upon gigabytes of images, which would take forever to transfer. That’s why we use hotlinking: instead of transferring all the media files to the staging site, WP Stagecoach just links to the media on the live site. It’s usually totally seamless, and makes staging site creation go a lot faster (but in the rare cases where hotlinking breaks things, you can turn it off).
WP Stagecoach has a whole team of staging servers, each with different versions of Apache, MySQL and PHP. Those servers are secured in a Tier-I data center near Seattle, Washington (we’re working on getting some servers in Europe and Canada to speed things up for customers outside the US!). WP Stagecoach checks to see which versions of Apache, MySQL and PHP the live site is using, and then moves a copy of the live site’s files to the staging server with similar versions to make sure that the staging environment matches the live environment as closely as possible.
After the files are transferred, WP Stagecoach sets up unique DNS for the staging site, creates an SFTP user account, and securely displays the SFTP password within an iFrame so that even on un-encrypted websites the passwords is not transferred in clear text. From there, you have complete control over your new staging site – you can test your plugin updates, change your themes, or do whatever you need to do in your WordPress test environment!
Importing changes from your staging site to your live site
Importing is WP Stagecoach’s special sauce. Making a website isn’t all that tricky, but getting imports to work reliably is tough, because of how WordPress and plugins spread data across many tables and files.
There are two kinds of changes to track: file changes and database changes. File changes are relatively easy to track: we use Git to record which files are added, deleted, and modified. When you import your file changes, we just copy over the files that have been added or changed, and delete the files that have been deleted.
Database changes are a bigger challenge. We can’t just copy over the database from the staging site, because doing that would over-write any new blog posts, e-commerce transactions, or forum activity that have happened on the live site.
We came up with a clever solution to database imports. WP Stagecoach keeps a record of every single change that you make to your staging site’s database. Every time you add a post, changes are made to several tables, and WP Stagecoach makes a record of each one of those changes. When you update plugin settings or theme settings, WP Stagecoach records those changes. Then, when you import to your live site, WP Stagecoach goes through the list of database changes, and incrementally makes the exact same changes on your live site. It’s like we have a little robot that watches over your shoulder and remembers everything you do, and then does it again on the live site.
When WP Stagecoach moves database changes from the staging site to the live site, it does make one important change: any references to the staging site’s URL are changed to the live site’s URL. That means that as long as you are coding your links properly, you never have to worry about rogue links to your staging site.
Sometimes, things go haywire. We’ve done everything we can to make sure that WP Stagecoach will work in any environment, but since we have no control over the live site’s hosting environment, we can’t always predict what will work and what won’t. So we have built in lots and lots of backup plans and contingencies to make sure that even if things go wrong, your live site will never go down.
Before WP Stagecoach imports any changes, it makes a backup of your live database and all of the files that have been modified on the staging site. So if the import fails, we can always revert to the backups. WP Stagecoach does a lot of error checking before the import begins, and if there is any suggestion that the import will fail, the plugin stops.
Of course, we can’t leave you stranded. If WP Stagecoach can’t do the import automatically, we have an option for a manual import as a last resort. With a manual import, you use SFTP and phpMyAdmin to copy the changes from your staging site to your live site. It takes a little bit more work on your part, but we’ve provided detailed instructions, and if you aren’t comfortable doing it yourself, we’re happy to do it for you.