The Ultimate WordPress Development Environment
The Ultimate WordPress Development Environment
Over the past couple of years, I’ve written loads of tutorials here on the WPMU DEV Blog in which I share tidbits about the development environments I use.
So today, I thought it’s about time I share a full environment, the kind I would put together and use for larger scale development.
Roll up your sleeves and get ready to get your hands dirty! Because below is a full walkthrough of the kind of development environment I set up, and how you do can it, too.
Note: This tutorial is not for beginners. If you’re new to WordPress development you won’t need such an elaborate environment as it might introduce unnecessary complexity. Also note that this article is meant specifically for WordPress. The ideas and goals might be the same for non-WordPress projects but the approach and the tools used would vary.
Table of Contents
What Makes a Good Development Environment?
In my eyes a good development environment has the following three properties:
- Highly portable
- Highly configurable
- Highly automated
Portability is an important factor because in addition to sharing the theme/plugin I’m developing I want to be able to share the dev environment as well.
I want other developers to be able to check out the source from GitHub and get started right away, including the use of any tools like Gulp or Grunt. This makes projects easy to jump into and if you support better collaboration you have a higher chance of making something successful.
Portability can also help you out if you need to work on another computer or you want to show your colleagues what you’ve been up to. The ability to set things up anywhere within a few minutes has helped me more times than I can count.
The ability to configure your environment is paramount. On the server-side, WordPress is extremely forgiving but being able to fine-tune your build settings, Grunt tasks and other options is a huge benefit.
Configuration options and portability together mean that you can test your work easily under different circumstances. How about switching PHP version or even HHVM just to make sure? Perhaps you can check compatibility with older versions of WordPress and popular plugins? These are things you should be able to test.
Automation is one of the main drives in creating a development environment for WordPress work. I don’t want to worry about my scripts, stylesheets, saving my work, deployment, and so on.
Command line tools form the back bone of my automation suite, which can do everything from setting up WordPress with one command to packaging my product.
A Work in Progress
Before we dive into the specifics, I thought I’d go off on a tangent about how development environments are dreamed up by those who use them.
If you’re a relative newcomer to the world of the command-line, build tools, version control systems, and whatnot, it might seem like I am the professional who knows everything and uses the perfect tools for every task.
This is pretty far off from the truth! I am well-versed in all things WordPress but everything else is just some extra I tacked on or needed/wanted to learn to make my life faster. I copied others, figured out bits on my own, and modified things as needed (sometimes failing miserably!).
My development environment (and many others’) is a mix of the following:
- Well-honed personal knowledge
- Great tips from others
- Just some random thing I found that works
- Steps that could be done much better but I couldn’t be bothered to figure it out
In other words: It’s not perfect but it gets the job done. There is plenty of room for improvement and places to use other tools, which you may like better. If you know of more helpful tools or workflows feel free to use those and let me know in the comments!
A Local Server
WordPress runs on PHP, which is a server-side coding language, thus we need a server to run WordPress. The most popular options are:
I started out with XAMPP years-and-years ago. I then moved to MAMP when I became a Mac user and then eventually switched to Vagrant about two years ago. The web and the tools used are evolving as always and now I tend to use Vagrant and MAMP as well. I’ll explain why below.
The “AMP” in MAMP, XAMPP and WAMP stands for Apache, MySQL and PHP. These tools all install services and a GUI to help you manage the processes used by the server. You download and install the app, press the “on” button and everything will work as expected.
It’s fast, it’s easy, it’s intuitive and will work on all systems all the time. It has a great user interface, which you can use to tweak PHP settings, switch to Nginx, configure Memcached, Postfix, set up virtual servers and more.
While there are many things you can tweak, control is limited. You can’t change the operating system or make other changes that full SSH access would allow you to do.
All AMPs lose in portability for the same reason. They are popular enough that anyone can install them, but they aren’t self-contained and minimal like Vagrant configurations.
Vagrant is a bit different. Instead of pre-packaging and environment for you, it gives you full control. It’s built upon VirtualBox (or other VM apps) and allows you to grab a “box,” which is essentially an operating system. You can then use scripts to configure these for yourself.
Configuration is self-contained in as little as two very small files. If you’re used to the command line setting up an environment can be as simple as
vagrant up – the system is extremely portable.
You can configure to your heart’s content. Any operating system, any software, from different caching methods to compiling your own PHP. You can replicate your actual host’s environment exactly to make sure your site will run in exactly the same way on your local machine.
If you’re not up to speed in command line usage Vagrant can have a steep learning curve. When everything works out it’s smooth sailing, all you need to do is issue one command. If something refuses to work, for whatever reason, you’ll find yourself in deep water.
Tools exist to create virtual hosts and perform other common tasks, the UI of MAMP is more convenient, at least for me. If I need a quick new virtual host with a WP install I can do it with MAMP + WP-CLI much faster than with Vagrant + WP-CLI.
Which One to Use?
If you work exclusively with WordPress, a tool like MAMP offers more than enough flexibility and power. It allows you to work with non-WordPress sites of course, so if you have the odd-job which falls outside the WP sphere MAMP will still serve you well.
If you work with large teams on non-WP projects I recommend grabbing Vagrant and giving it a go. It will teach you a lot about how servers work internally and allow you to share environments exactly.
My preference is to use both. When I need to (or have the time), I can configure my environment down to the last detail with Vagrant. When I need something simple or for a WordPress project, MAMP is my preferred option.
Rachel McCollin, another writer here at WPMU DEV, has written a great guide on how to set up up MAMP and I’ve contributed a Guide to WordPress Development With Vagrant, which you can use to set up these environments.
Command Line Tools
I don’t use a huge number of CLI tools, but the ones I do use are a large part of my workflow. The most prominent ones are WP-CLI, Gulp, ngrok and Ultrahook let’s go into a little detail.
WP-CLI is an extremely powerful command line tool, which allows you to automate everything about WordPress. I’ve already written a tutorial about Advanced WordPress development with WP-CLI so I’ll show you just some of the magic it can do.
Setting Up New Sites
You can download, configure and install WordPress in a few simple commands like
wp core download and
wp core config. Documentation is plentiful and easy to follow.
I use WP-CLI together with bash scripts to create little templates for new site creation. You can use commands to remove default plugins and themes and download and activate plugins you use regularly.
Search and Replace
Database search and replaces are sometimes needed but can be a pain. Changing to https, moving to a new domain, renaming urls and others can all bring with them some mass changes.
Since the database contains a number of serialized arrays you can’t just to an SQL search and replace (unless the old and new value is the same length).
wp search-replace oldval newvalue will work all that out for you, unserializing and then re-serializing your arrays.
1.6 million WordPress Superheroes read and trust our blog. Join them and get daily posts delivered to your inbox - free!
WP-CLI has built in SSH to help you manage sites over SSH. This has the potential to allow you to manage hundreds of sites with a single command (ie: updating a theme or plugin across multiple sites).
So Much More…
Gulp is my automation workhorse. I use it to manage my scripts, styles, images, even mobile testing and browser refresh mechanics. I wrote an extensive article about Using Gulp With WordPress, take a look there for detailed instructions.
I prefer Gulp to the other popular choice – Grunt – because of the syntax differences. Take a look at my Grunt For WordPress Development article and make up your own mind!
Gulp uses Node and Node packages for its functionality, making it extremely portable and powerful, due to the community-driven extensions. My work process with Gulp usually involves the following:
- Find an extension that fits my needs
- Install the node package with npm
- Require the package in the Gulpfile
- Write a short automation task
The only part of this that requires any thinking at all is number four. Even then, most extensions have copy-paste examples which will probably only need to be modified a tiny bit.
Here are the extensions I use most:
- gulp-sass for compiling Sass to CSS
- gulp-clean-css for minifying CSS
- gulp-autoprefixer for adding vendor prefixes automatically
- gulp-include for concatenating JS files
- gulp-uglify for minfying JS files
- gulp-imagemin for optimizing images
- Browsersync for creating dev servers which help with mobile testing
- gulp-sourcemaps for creating source maps for minified files
ngrok is a small service and command line tool I use to share my local work over the internet. ngrok creates secure tunnels to a local environment, exposing your application on a special URL like
Ultrahook is kind of the reverse of ngrok. Where ngrok routes your localhost to the web, ultrahook routes the web to your localhost. This is extremely useful for testing third party APIs like Stripe for example.
You can set Stripe up to send test webhooks to
http://stripe.danielpataki.ultrahook.com which will be passed securely to your local server.
For most of us WordPress development is synonymous with plugin and theme development. The repository is full of plugins that help developers create better work faster. Here are some I use or used regularly.
A must-use plugin for theme creators. Theme Check will analyze your theme and spit out reasons it doesn’t meet the WordPress standards. It looks at deprecated code, extraneous files, bad practices, common errors and tons of other potential problems.
Do you think supporting right-to-left languages is easy? Think again! It’s not so much a technical challenge but those who read/write exclusively from left to right find RTL so alien that it’s difficult to see issues without actually testing. RTL Tester makes it super easy by allowing you to put your site in RTL mode with the flick of a switch.
Advanced Custom Fields
Advanced Custom Fields or ACF is my all-time favorite plugin. It allows developers to create beautiful custom fields for their themes and plugins in an intuitive and quick UI. Once you’re done you can hide ACF altogether and paste the generated PHP code into your work to keep the fields intact. A well-executed and hugely useful plugin!
The Query Monitor allows you to see exactly what’s going on in your WordPress environment from a database access point of view. You can catch potentially slow or redundant queries before they go out into a live product and optimize existing ones to make your code that much faster.
Bash scripts contain a bunch of commands that are run one after the other and can be used to further automate tasks. For example, it’s already easy to install WordPress with WP-CLI. All it takes is the following:
These commands must be issued one after the other, which takes a bit of time. By placing this in a file, let’s call it
install.sh, you can create a template for creating a WP install.
Place the file in the folder you want to create the installation in and type
bash install.sh. All the commands will be issued and in a few seconds you’ll have a site up and running.
By adding parameters you can make it even more useful. If you issue the command like this:
bash install.sh newsite you can use the parameter to fill out the database name, the URL and site title.
Bash files can also be useful for creating final builds (removing extraneous folders and files, moving directories, etc. ) and other similar tasks. They can even be run from Gulp tasks which gives you a lot of flexibility in your workflow.
Browser extensions are a great help when testing a site. Here are some that I use in my workflow.
Postman is a chrome extension for building, testing and documenting APIs. I find that whenever I need to shoot a quick request to see how an API works Postman is far faster than any other tool.
The ability to save and manage requests is particularly useful. API testing is something I do less frequently but when I get around to it, it takes up most of my day, using something like Postman makes my life so much easier.
EditThisCookie is another example of a Chrome extension which I don’t use a whole lot, but when I do it saves me hours upon hours. It lets you see/clear/edit a single site’s cookies. That’s all, but oh my, how handy it can be!
Page Load Time
Page Load Time does what you’d thing, it analyzes the page load. It can go into important details like DNS/Request and response times, but what I like is that it shows the overall load time right there in the toolbar. Super-handy for quick comparisons.
My final browser extension entry into the misc tools category is JSON Formatter, which detects when a response is simply a JSON string and formats it all nice and proper instead of just plopping out a block of text.
This one actually has nothing to do with development! Franz is a tool that can aggregate a number of web services under one roof. My Messenger, Slack, Skype, Inbox by Gmail, Trello, Google Calendar and Todoist apps all run in one window instead of their native apps.
It all looks exactly as if I ran them in their usual environments but I don’t need to have all those icons and I can switch between them more easily. I mention Franz because it has helped me focus more while also communicating better.
Varying Vagrant Vagrants or VVV for short is an open source Vagrant configuration for developing for WordPress and WordPress itself. It contains all the tools you’ll need to get started, including development builds of WordPress.
So Much More!
There are so many tools I haven’t mentioned, mostly because I simply don’t use them. They are great tools but I just haven’t gotten around to them, don’t need them or they don’t fit in my workflow. Here’s a short list of some greatness you should take a look at:
- Underscores for a great theme boilerplate made by the WordPress theme department
- Roots for a whole WordPress stack including server, application management and starter theme. I find this too elaborate for my taste, but it may be up your alley.
- WordPress Plugin Boilerplate for standardized object-oriented plugin development.
- Upfront for creating beautiful themes via an amazing interface
Make Your Development Environment Your Own
In conclusion, these are the tools I use – they might not necessarily be the best fit for you, nor are they the best fit for every situation. This setup is flexible enough for my needs, so please do take the time to research options and create a workflow that feels right to you.