Setting Up a Custom WordPress Website Development Project Workflow
If you are a custom WordPress developer, getting a good workflow together to tackle custom WordPress projects is a must. Here’s a look at my own development workflow and recommended steps for creating your own:
#1) Create a local WordPress development environment
Local WordPress environments are copies of WordPress that run locally on your computer. Because you’re the only one who has access to these files and they’re not reliant on a working internet connection to function, local WordPress environments make for perfect initial staging grounds for any custom WordPress project.
I personally use DesktopServer to quickly get local environments up & running and it saves me start up time by using their super handy “blueprint” capabilities. Essentially, this allows me to create an initial starting point that has the few standard plugins I use (Advanced Custom Fields Pro, Gravity Forms, a SEO plugin, WP Migrate DB Pro) plus my starter theme. With blueprints, I don’t have to waste my time installing the same plugins repeatedly or always dropping in my starter theme so I can get moving much quicker. If you don’t like DesktopServer, plenty of alternatives there — Local by Flywheel is another app route but you could also install MAMP or similar — but in terms of the most simplistic way to dive into local development, I’d recommend going the app route with DesktopServer or Local!
#2) Create a repository for the theme
Version control is your friend, kids. As someone who is usually a solo dev on projects, it took me way longer than I am proud of to see the benefits of version control. These include things like: having an easily accessible backup of all code, being able to revert changes (like a client decides they don’t want a feature anymore then later decide actually they DO want it), easily tracking modified files, building a foundation of best development practices that make working with a team down the line via Git easier and much more.
If you’re considering whether you should be using Git for your projects, just do it. If you aren’t comfortable in the command line or just prefer a GUI, I’d recommend Sourcetree. For WordPress projects, I personally just put the theme under version control and then make a separate repository if I do any custom plugins for the project.
Some people choose to version control the entire wp-content folder or everything in WordPress. There are plenty of opinions out there about what should be done but my approach is mostly theme only.
#3) Create a public staging environment
It is possible to allow a third party to tunnel in to view your local install with something like ngrok, which is integrated in both DesktopServer and Local. However, I prefer to have a public staging environment up & running elsewhere.
This may exist on my own server — I have a dedicated hosting account for staging projects — or this may exist on a client’s server or dedicated staging environment. While this isn’t necessary to start development, it’s put into place ahead of sharing initial progress with the client.
#4) Configure DeployHQ or another automated deployment route (optional)
I personally use a service called DeployHQ to push from local > staging or local > production. When starting a project, I’m frequently configuring DeployHQ to do automatic pushes from my repository to the staging environment on every commit. From the point I set this up onward, I’m just coding and then when I make a commit to the project repo, it pushes the modified files to the staging server and I don’t have to manually do anything there. DeployHQ also allows manual control of deployments, which is recommended for production environments.
Using a tool like DeployHQ just greatly speeds up deploying updates throughout the development process.
#5) Get a plan for your database migration
All of the content powering a WordPress site lives in the WordPress database. That being said, as you’re developing a site, just pushing changes to something like the theme alone won’t get everything from Point A to Point B, you need to involve the database.
You can manually export and import the database via PHPMyAdmin every time you need to transfer. However, that’s a giant pain.
WP Migrate DB Pro is a plugin that I would probably be brought to tears without as it saves so much time and just makes shooting WordPress databases around utterly painless. It allows super simple pulling & pushing of databases between environments as needed. My go-to route for setting up projects initially is making sure this plugin is up & running on both my local environment and staging to field WordPress database migration throughout the course of the project.
#6 ) Start coding
Once all those pieces are in place, you’re ready to dive into the actual WordPress development! Happy coding!
Have a project you want to discuss?
I’m a senior WordPress developer with over a decade of experience specializing in the CMS. I’d love to talk about how I can help with any of your professional WordPress development needs. If you have a web development project in mind, let’s chat!
This post was updated & modified from a version initially posted in October 2016.