One of the first and easiest “tests” that distinguishes established WordPress developers from those who are still getting into it is whether or not they’re using a remote server for development. You can build lots of WordPress sites before you need to have an alternate, personal place to experiment with theme and plugin code. But eventually everyone tries local development, and then they rarely go back to remote-only.
DevKinsta makes local site creation and development quick and easy. Spin up a single or Multisite WordPress site with Nginx, MariaDB, and more with a single click. Take advantage of local database and email management tools to develop themes, plugins, and custom sites, all on your local machine. Powered by WordPress Log in to your WordPress.org account to contribute to WordPress, get help in the support forum, or rate and review themes and plugins. Username or Email Address.
Understanding local development is something that has gotten harder in WordPress in the last five years. The options have multiplied, and many are meaningfully better than what came before. A newbie can feel swamped with very good choices whose trade-offs aren’t clear. That’s what this piece is for: Mr. Trade-offs (that’s a nickname I just gave myself) will tell you what options exist for doing local WordPress development and why you might want to go with each one. But before we run them down, a bit more about WordPress, servers, and why local WordPress development is good.
Serious About Learning WordPress Development?
Get Up and Running Today
Up and Running is our complete “learn WordPress development” course. Now in its updated and expanded Third Edition, it’s helped hundreds of happy buyers learn WordPress development the fast, smart, and thorough way.
{% if condition: learning-wordpress-development %}
You’ve seen we know what we’re talking about, and can help you learn WordPress development. But, here’s one of our customers – who’s now a full-time WordPress developer – telling you about the course:
“I think anyone interested in learning WordPress development NEEDS this course.
Before I purchased Up and Running, I had taught myself some WordPress code, but lacked direction. Watching the course’s videos was like a bunch of lights being turned on.
Local/wp-admin
I went from being vaguely familiar with how themes, functions and WordPress itself worked to mastering these. Everything became much clearer.
I very happily recommend this course to anyone willing to listen.”
– Jason Robie, WordPress developer
{% endif %}
Take the next step in your WordPress development journey!
Why Local WordPress Development is Good
Because of how easy most web hosts have made WordPress to install, people don’t need to work too hard to get a site running. And so most people are most comfortable just making changes to their live site on the main server. And it’s easier, for sure. (In some ways, it can seem like WordPress was designed to make syncing a remote version of a site with the live one hard.)
But there are important disadvantages to tweaking your live site and using it as the location of code changes. Some that quickly come to mind are:
- Your visitors can see all the changes you make. If you’re trying themes (and are using the customizer preview) this is less true than it used to be, but many plugins that require changes to your sites cannot be shown to you alone. If you’re just trying a plugin or feature out, that’s not a great situation.
- When you break something, you’ve broken the real thing. The invocation not to “cowboy code” is all about this. When “cowboy coding” goes right, it’s not a problem. But when it goes wrong it’s at least three times worse than just breaking the local version. Sometimes it’s up to 4729 times worse. (I measured ;p)
- You have a slower feedback cycle. Making changes show up on a remote server is slower than making them show up on your local machine, no matter how you slice it. The most common FTP workflows are both slower and more error-prone, but even if you streamline the process (by using a local-save-as-automatic-upload workflow) it’s still slower.
- Caching can get you. One of the biggest problems these days with using a default WordPress install on a good host for development is that caching (which is necessary/great for site performance) may make it hard or impossible for you to confidently tell that you’re making changes and what effect they’re having.
- Public stack traces are embarrassing. Or worse, they can be a security problem. But if you’re turning on
WP_DEBUGremotely, that’s at best a good part-time solution to white-screen of death, which is the more secure way for you to have your public site fail.
Local Wpb Radar Weather
WordPress Runs on a Server, So You Need a Server
To really understand local development, and what that means, you have to start to understand WordPress as more than just an application that is at your beck and call. You must understand that it is a PHP application that runs on a web server that responds to requests made to it by browsers.
Fortunately, most of the options for local development we talk about in this article don’t require a deep understanding of what all is going on under there, and none of them require you to master all the complexity or be able to put it all together yourself. (Though understanding that better is a fun use of nerd-time.)
The essential things to know about WordPress for this article are the following:
- WordPress is, from a server perspective, a PHP and MySQL application. PHP is the programming language, and MySQL is the database that WordPress stores posts in.
- Apache, or more recently Nginx, is the server that bridges the gap between PHP and web browsers.
- The operating system that WordPress runs on can vary. Linux is the most common, but it can also run well on both macOS and Windows.
I’ve already written a longer primer on understanding the technologies that underlie WordPress. If that’s interesting to you, check it out:
How You Do Local Development
You’re now at a convenient point to watch the above video, where I run down my preferences for local WordPress development.
The holy grail of local development, which all the the options we’ll cover below give you, is the idea that you save a file in a folder on your computer, and the server is immediately updated with the change. Because your computer is the server.
As we’ll talk about a bit more later, in some situations that possibility is a bit more abstract than in others, but in all cases that is why you’re going though the hassle of setting this up: to get a personal copy of WordPress which’ll show your changes quicker.
WAMP, MAMP, XAMPP, etc
The first stop when considering local development options are to me the classics: WAMP and MAMP. When I was a Windows user about a decade ago, WAMP was how I first got WordPress running locally. And it remains a great option. Today, I still use MAMP on my Mac. I’ve never used it personally, but XAMPP is a popular cross-platform version of this same basic idea.
For the uninitiated, MAMP stands for macOS, Apache, MySQL, and PHP. WAMP is the same, but Window stands in for macOS. In both of these cases, you’re basically running a single self-contained application put together by someone else as your web server. It uses your underlying operating system for support.
For most people with most uses, this will mean that you’ll default to developing on sites with URLs like http://localhost/my-dev-site, or http://localhost:8888/wpshout-dev. It is both possible and pretty easy to change this if you know what you’re doing, but out of the box this is what you’ll see.
The great thing about WAMP and MAMP is what they have in common: they’re both relatively well designed systems whereby you can have a simple single “app” you launch to start doing local development. Because of their atomic nature, they’re (relatively) simple to install and control.
A Quick Note on MAMP
MAMP is an interesting and much more commercial product than WAMP and XAMPP. You don’t have to pay for “MAMP Pro” to use “MAMP” though. I personally have paid for it a few different times, because I appreciate a lot of the Mac-specific design niceties of MAMP (PRO). Neither version is perfect, but I feel they’re useful enough to me to throw the maker $60 once and a small upgrade price every few years. Some people are ideological about paying for software, and MAMP is clearly an ecosystem intended to have you pay. But I feel it is worth the price.
I go into this in more detail in this video. Give us an email address and you can watch practical a comparison of it and VVV (discussed below):
WordPress Specific Variants: DesktopServer
I’ve never used it, but I know a lot of people in the WordPress community use and love DesktopServer. The reason? Imagine you got all the features of _AMP and also a lot of useful features specifically for WordPress users and developers? If I’d known about it earlier on in learning about this stuff, I have little doubt I’d really appreciate some of the WordPress-specific polish that DesktopServer contains. Just taking a quick perusal of their marketing site, some features that I don’t get with MAMP that I think sound cool:
- Automated WordPress installation (both free and paid)
- A ByPass Login plugin
- LAN Sharing for Mobile Testing
- Assisted Deploy of Your Sites
Like MAMP, DesktopServer encourages you to pay for a product. Unlike MAMP, it runs on Windows.
A Mac-Only Option: Laravel Valet as a Thin Wrapper
Another way to deal with the need to create a server is to use your underlying operating system and string together the PHP, MySQL, and web server yourself. I’ve done this before on a Mac, and while I don’t recommend it—it required lots of low-level maintenance at random times, and I always had permissions issues because I am not an expert and probably did something wrong.
But, it is a quicker and lighter solution than MAMP, DesktopServer and the like. And while I said I rejected continuing to do this, I recently tried out an alternative which assists in doing just this and has lots of niceties my version of this never did. It’s called Laravel Valet. (For those curious, Laravel is a popular PHP MVC framework, but you don’t have to know or use it to use Laravel Valet.)
What Laravel Valet does is give you a CLI tool to quickly create and manage new projects on yours local machine. It installs the server and hooks up to MySQL for you. This is great for WordPress, and it’s got everything ready for use with it out of the box. To use this you must be on a Mac and must be comfortable with the command line. But if you are, it’s pretty great.
Vagrant is a Virtual Local Server
So far, we’ve been talking about using your local operating system for your local server to run on. That’s the quickest and easiest way to get a server running. But it’s not the most reliable, if you’re worrying about differences between the production server and your local install. For 80% or more of WordPress projects, I feel confident that server configuration isn’t a big issue. But for the small percentage where it is, the difference between running on Windows or a Mac and the Linux OS that your server runs matters.
The first popular and common way to address this was by creating “virtual machines” on your computer. What this means is that you install some software on your Windows or Mac to emulate a Linux server on your machine. This virtual Linux server could then be used for the web serving you needed, and it could read the same local files that you have on your own computer.
Ways to emulate operating systems and tools to configure them varied a great deal, but in the last few years most developers have decided that Vagrant is the free combination is the tool they want to use to give a standard configuration to a virtual machine. Generally, especially for the cost-conscious folks, Vagrant emulation runs atop a free tool called VirtualBox, but part of the appeal of Vagrant is that it inter-operates with other emulation systems, like Parallels or VMware Fusion, which are both popular for people switching to Mac wanting to still run some Windows software.
Reasons to Skip Vagrant for Local WordPress Development
Vagrant is a great tool for virtual machine management. But it’s also got some downsides. Across all the various virtual machine systems you might use of local WordPress development, you will generally find these problems:
- Resource Intensive—Emulation of virtual machines is CPU and especially memory intensive. If you don’t have a reasonably modern and powerful computer, these solutions are guaranteed to be much slower than a WAMP-type solution.
- Hard to Install—If you know the CLI, and already have a virtualization solution installed, installing Vagrant isn’t too complex. If you don’t, that’s two hurdles before you get to productively tinkering with a site.
- Hard to Configure—Vagrant is relatively simple and easy to configure if you’ve been a programmer for years and is pretty comfortable with YAML and the CLI. But if that’s not you, you can quickly find yourself down a long and complex rabbit-hole.
- More Fragile—It doesn’t strictly need to be the case that Vagrant-based solutions are more finicky and fragile than MAMP, etc. But in my experience they have always required more babysitting than MAMP.
Why Use Vagrant for Local Development?
Despite those drawbacks, many people use and love Vagrant-based virtualization. Here are the primary reasons:
- Consistency—A well-configured VM will behave identically whether it’s atop Windows, Mac, or Linux. This means that you don’t have to sweat that Windows is weird as much as you did before you worked with virtual machines. And on a team, Mac vs Windows issues go away, if it runs in the VM it’s good.
- Matching Production—When running, a properly configured VM can very closely match the environment of production code. So if you’re, say, developing for WordPress.com VIP, testing your code in their environment is easiest with VIP Quickstart.
- Access to Cooler Features—This goes along with the above, but WAMP isn’t necessarily going to help you see and try object caching or WP-CLI and make sure your code works with it. A well-configured VM will have that out of the box.
- Street Cred—This is half-joking, but I can’t exclude it. Part of the reason people have flocked to Vagrant (and are now starting to do the same with Docker) is that it’s a cool and new technology both inside and outside the WordPress ecosystem.
VVV, Trellis, Local, Chassis and more for Customized WordPress Local Dev
There are, around the WordPress ecosystem, too many Vagrant projects for me to catalog for this article. I’d guess there are at least a dozen that have been updated in the last year. However, here are some I’ve heard of and thought notable:
- Varying Vagrant Vagrants (VVV): Jeremy Felt manages the “mama bear” of Vagrant projects for WordPress. This originally had the branding/backing of 10up, a large WordPress agency, but has since spun off on its own. It’s the most cited and used example by a good distance.
- Trellis: The people behind the Sage (née Roots) starter theme are big backers of a specific WordPress development style, and their Vagrant box is most often advocated by people who use the rest of their philosophy. I’ve never used it, but I trust it’s good.
- Local by FlyWheel: This is a cool standalone app (think DesktopServer) which uses VirtualBox (and Docker, actually) to give you a slightly more reliable and WordPress focused experience than _AMP packages. It’s pretty, has a GUI (neither VVV or Trellis do), and used to be called “Pressmatic”.
- Chassis: Human Made have put out a new “ecosystem” for Vagrant. The cool part of it, to me, is that it comes with a desktop app. Seems like it could turn into a more-open-source version of Local.
Did I miss your favorite Vagrant-based WordPress workflow? Tell us about it in the comments!
Local Wp
Docker Does Lighter Virtualization
If you read the above Vagrant section, you probably caught a theme: virtual machines are great for consistency, but kind of not-great for slow computers. To address that issue (and another security one we’ll leave aside), “containerization” has come along. The idea of containerization is that if you can make an app think it’s in its own machine, without having to put it in its own machine, it’ll have the benefits of virtual machines, and even more.
There are a number of tools and technologies by which one can do these things, but it’s most often rounded up to “Docker,” the name of the most established technology for this purpose. (Just as Vagrant is the brand often wrapped around the entire idea of virtual machines for developers.) So why use Docker? Because it gives you the consistency wins of virtual machines, without as much overhead in memory and other resource usage, because each “process” is virtualized more intelligently than it is with classic VMs.
For a while, Docker was a Linux-only proposition, but in the last year both Windows and Mac apps have become available and so this is now a viable and increasingly popular solution to the biggest downside of virtual machines.
Docker does introduce a new complexity—you’re not running your database on the same “machine” as your PHP or server, so you have to explicitly wire them all together. But after you pass that hurdle, it’s faster than a VM and just about as reliable. And you can just deploy Docker to production, if you’re real fancy.
I neither know nor understand enough about Docker to go into much more detail than this. But I have diddled with it a bit, and if you leave the configuration to professionals (as you mostly do if you use VVV, Trellis, etc), it’s comparably easy to get running as a Vagrant solution.
A few months ago 10up’s Taylor Lovett published a post about a project he calls “WP Docker”. It’s basically and explicitly positioning this solution as the VVV for Docker. I recently installed his version, and it was quick and painless to have a WordPress site running. (In looking this story up, I also see that XWP, another large WordPress agency, also had a public repository called wp-docker.)
So Many Options for Local WordPress Development
Local Wp Import Site
The core thing to understand from this article, as with most things in technology, is that there is no single right answer. If you’re new to the idea of doing local WordPress development, I would start with Local, DesktopServer, or the _AMP variant that fits your preferred operating system. They’re the easiest thing for most people to understand and get running.
If you’ve been doing that for a while though, maybe you’re feeling ready to give VVV or Docker a try. If that’s true, splash out. But don’t be shocked when you hit a bit of learning curve. It is pretty substantial if you don’t already have a good grasp of what these technologies you’re wading into are. And if you aren’t comfortable on a CLI.
But none of these options are bad. And all are definitely better for you than cowboy coding. When you have a site working locally (ideally with version control), you can then go ahead and do the FTP dance that you used to do in the past. It’s not perfect, but it’s a clear improvement to your workflow, and that’s no small thing. Happy hacking!
Image credit: reynermedia