If you work with WordPress on a small site, you probably started with a fully FTP (or SFTP) based workflow, editing your site directly on the server with a combination of an FTP client such as CyberDuck or Transmit and a cool code editor like Sublime Text, or perhaps you’re already using an integrated development environment that includes all of that, like Coda or Espresso.

I’ve been there and done that, and it has served me nicely for small websites in the early days, but it gets to hit hard limits when you are using WordPress as a CMS or as a framework for a larger web app, especially if it syncs with mobile apps.

The main issue in this FTP-based workflow is that you risk to introduce bugs on a live server, that is being visited by actual people and on which your users, potentialy paying customers, are actively using and relying on to carry out the activities you offer through your app.

So what happens in this scenario when you need to fix a bug, and what are the risks?

Yeah, you get it, an image is better then 1,000 words. This does not look good, right?

A better development workflow will work like this:

Your workflow needs to start from your local machine.
You need to have a local development environemnt setup to test your features and work on breaking changes.
Nowadays this is a very easy task to acocmplish on both Mac and Windows, thanks to MAMP.

MAMP installs a local server environment in a matter of seconds on your computer. It comes free of charge, and is easily installed. MAMP will not compromise any existing Apache installation already running on your system. You can install Apache, PHP and MySQL without starting a script or having to change any configuration files! Furthermore, if MAMP is no longer needed, just delete the MAMP folder and everything returns to its original state (i.e. MAMP does not modify any of the “normal” system).

So you can work and make breaking changes locally, on a machine that is optimized for development (i.e. showing PHP errors and warnings either on the page or easily in your Console app) — once a beta version is completed, you will just deploy the code changes to the server.

You can either sync changes via FTP or use another deployment tool. I personally like to use GitHub with the sites hosted on WPEngine.

But wait, if your development server is on your local machine, how will the site owner test and approve the new features?

You need an online server for that, but you don’t want to deploy the changes to the live server until these are approved, so you need a “staging environemnt”, which is just a slave copy of your production server.

A staging server is the place where the stakeholders (the customer) will verify the new features and changes and approve them for production.

While my local development server database is usually a bit stale compared to the live site, I personally like to wipe and recreate the staging environment from a live copy of the production server every time I need to test some major new feature, so that the testers work with fresh, recent data, and don’t get confused reporting issues just because they don’t see this or that database record they are used to see every time they log-in.

Once the changes are tested and approved, I deploy the changes on the production server.

Many providers have a staging feature built in their systems. WPEngine makes the process a snap, and the latest CPanel has a “Staging” feature.