WordPress Workflow Environment – Development, Staging and Production

There seems to be a movement against so called Cowboy Coding for WordPress over the last year. This is probably a sign that WordPress is maturing. Developers are using more development tools to streamline their process, user repositories and limit downtime. No more putting up a “Under Maintenance” screen and hacking away at a customer’s WordPress for hours. This point was driven home for me when creating a redesign and realized the site needed to be moved out of Multisite. The move turned out to be a serious challenge and ended up requiring more downtime than I would have liked. I tried to stage the site under a different domain name, but still struggled when moving to production.

Resources for Creating Development and Staging areas

The best article I’ve found for this is Ultimate WordPress Development Workflow by Zach Adams. I’m following his suggestions closely with a few changes.

WordPress Development Server

Vagrant seems very popular right now, and even things like Docker and Wocker are popular. It seems creating a LAMP environment in the quickest, easiest way is a big focus of the WordPress development community. Personally I run an Ubuntu (Kubuntu actually) workstation and have for years. It’s not difficult to setup Apache and MariaDB under Linux if you know how, so I’ve done this. Not sure if there are advantages to the Vagrant process, but looking forward to doing this later.

Syncing Production, Staging and Development

wordmove (https://github.com/welaika/wordmove) is a Ruby gem that will pull and push WordPress from one server to another. It’s a really neat little app, but a bit trick to get to work. It doesn’t seem to have much for error handling, so troubleshooting configuration issues has been challenging. Interestingly, what it does is fairly simple, and could probably be recreated in any language. It uses ssh and rsync to make backups and migrate them.

Revision Control

Git using bitbucket or some similar service, there seems to be many. Not too much wiggle room here, Git seems to be the tool of choice.

Switching Browser from Development to Production

The biggest obstacle for having multiple environments for a WordPress site is switching your browser from one environment to another. WordPress is designed to be configured under a specific domain name, moving sites to new domains has long been a challenge. The traditional way to make a site work in multiple environments is to change your hosts file and manually enter the IP address. This has a couple problems. First is that you can only see one site at a time. You can’t look at the production www.foo.com and the development www.foo.com at the same time unless you have multiple computers. The second, and more dangerous problem is that it’s easy to mix up which server you are on resulting in lost time from not seeing your changes or potentially making a change to a production site without knowing it.

There seems to be some FireFox and Chrome plugins that address this, but none of them have very good reviews. What sounds like a better solution is the Studio 24 WordPress Multi-Environment Config This setup modifies WordPress to include multiple config files which can setup the domain name the site is being run under, so the development server could be setup as dev.foo.com, staging as staging.foo.com and production as www.foo.com. These config files would not be moved from site to site and should solve the problem. The domains would still have to be in the hosts file, but that would be a one time change. The downside is it would require some modification to the core WordPress, which is something I’m personally against in a general sense. The good thing is it wouldn’t be too weird, unlike some directory renaming and things that are done in the name of security.

Plugins for Development Environment

There are some great development plugins for WordPress, but these shouldn’t be installed on a production server. Additional plugins can slow down a site, require additional resources, be a potential source of vulnerabilities and create a poor user experience. The question is how can a dev server be setup to include these plugins by default and make sure the developer plugins don’t get pushed up to staging or production. At one time there was a plugin to deal with this, https://wordpress.org/plugins/environmental-plugin-manager/, but it is not currently active.

Staging

Staging seems pretty straightforward as well. Linode has hosting accounts for $10 per month. Seems cheap enough for a decent staging server. One thing I would be concerned about is making sure that only authorized visitors are accessing that server. Keeping both hackers and bots at bay. Last thing you need is Google indexing the staging server site and penalizing the production site for duplicate content or something, plus dealing with Brute Force attacks is no fun for anyone.

It’s tough to have a good workflow process, revision control can be challenging and migration error prone, but done right it should make you a better development team and more productive.

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>