I’ve been developing WordPress websites for a while now. After breaking many sites, I’ve learned the value of local WordPress development. Developing locally can make our build process faster, easier, and more accurate. These are all good things, but local development is not perfect and brings with it it’s own set of headaches.
It wasn’t until recently that I found a local development process that I’m actually very happy with. First, let’s look at some of the steps along the way…
How I Used to Develop for WordPress
If any of this is familiar, feel free to skip ahead to the good stuff.
WordPress File Editor
Baked into WordPress is an editor screen where you can access theme and plugin files. It’s an OK idea for very small changes, but if you make one small error, it could break the entire site (including the file editor screen). When I first stared out, I learned this the hard way by breaking our biggest clients’ site and not being able to fix it. For the love of God, don’t touch it.
After my experience with the WordPress editor, I found the benefit of using FTP. I still made changes on live sites and still broke live sites, but the fixes were much easier. Don’t do this either. This is what staging sites are for. You can make changes, test them, fix broken things, and THEN push the working changes to production.
Staging sites are a good practice, but for a development workflow, it’s not enough. File transfers are slow, so making changes takes time. You also have to be connected to the internet to get any work done.
What I don’t like is that I needed to manually install WordPress every time, and I can’t change the software in the stack. If my production environment uses an older version of PHP, but my WAMP version is a newer version, my site might break when I push up my new theme (This actually happened to me. More broken sites!).
An excellent improvement which I definitely recommend for most users. There is a free version but you only get up to 3 WordPress installs, and the pro version is very affordable. DesktopServer is built on top of the same technology as WAMP or MAMP, but is easier to set up a new WordPress install. It also comes with WP-CLI which is a nice bonus for advanced users, and can route a custom domain (like http://localbuild.dev) to my local server.
It’s worth the price for the pro version, but the cost might be a deal breaker for people on a budget. Like WAMP or MAMP, you can’t change the software to match your production environment (yet).
There’s a lot to cover here, so I’ll be brief. Vagrant lets you to create a virtual machine locally which is similat to a blank server. You can then install software however you want to match any environment. VVV tells Vagrant which software to install for WordPress (Ubuntu, nginx, MariaDB, PHP 7, WP-CLI and more). VV uses VVV to set up new WordPress installations locally.
I hope I didn’t lose anyone.
The bottom line is that this setup is highly configureable, comes with modern, powerful tools, and is all free. The result is very similar to DesktopServer, but gives us more flexible options for local environments. It also supports xDebug, but it’s not on by default. Here’s the directions to enable it.
The big problem is that sometimes things break. It may be just because I work on Windows, but I get some errors in spinning up new sites from time to time. I’m no computer science expert when that happens it can take hours to figure out. And even though VV makes it simple to create new WordPress installs, it’s not as fast as I would like. It can take a few minutes to download all the files.
Local WordPress Development Now
Today I’m actually pretty happy with my process. I keep just one WordPress install on my Vagrant machine which still runs on the box set up by VVV, but I no longer use VV to generate new WordPress installs for each new project. However, I found that if you simply edit one line in your wp-config.php file, you can generate a whole new site in a couple seconds.
Some of you may be thinking that I am creating a WordPress multisite instance, but you would be wrong. Multisite is cool, but creates other challenges that I won’t get into now. Basically, if your production site is not multisite, your development site should not be either.
Instead, I change the
$table_prefix variable. When you install a new instance of WordPress, it needs a few things to access the database: the database name, username, password, and the table prefix. The database table prefix determines where in the database all your data is stored.
If we change the table prefix, WordPress can’t locate your data and has to run a new install. It skips all the file downloads since they are still there, and just adds the new data to the database in new tables. If you look at your database now, you will see tables with the new prefix as well as tables with the old prefix. (Note: after changing the table prefix, you will usually get a warning on the install screen which you can ignore).
This method is pretty cool because it will also works with any WordPress environment: WAMP/MAMP, DesktopServer, Vagrant, whatever. It’s not something that only works on Vagrant.
- Creating a new site is as simple as adding one line to the wp-config.php file.
- Swapping between sites is as simple as commenting out one line, and uncommenting another.
- All your favorite developer plugins are already installed since it’s the same file system.
- Updating plugins on one site will update it on all sites.
- I do all my local development form the same URL instead of changing between projects (which I personally like).
- Less disk space is used since all the WordPress core and plugin files are on one install instead of spread over several.
- Shared file-system means you can’t manage different versions of the same files (but you could use Git).
- I suppose your database could get very large at some point, but I haven’t had an issue yet.
What The Workflow Looks Like
Most of my days look like this: I come in, turn on my machine, open up my command line, navigate to my projects folder, and run
vagrant up to fire up my virtual machine. At this point, my local development environment is ready and I can continue working from where I left off.
When a client request comes in for a different project, I open the wp-config.php file, comment out my current table prefix variable, and uncomment the respective client’s table prefix variable. Refreshing my local dev site will let me pick up where I left off on that project (including active plugins, themes, page content, menus, etc.).
If we get a new client and I have to start a new project, I open the wp-config.php file, comment out my current table prefix variable, and create a new table prefix variable with a name that matches the client. (Note: use names that are easy to identify, and don’t delete any unless you don’t mind losing the data).
When you are finished working on your local plugin or theme, push the changes where they need to go however you would normally.
This works well for me because of a few things: I only work on plugin files or theme files locally; I don’t manage content locally; I prefer to build out all the content on the staging site. My co-worker, on the other hand, likes to build out the entire site locally, including content. This system doesn’t work for him.
The other consideration is that I generally build for individual clients. If you build plugins or themes for the general public, you have to test your code against many different versions of WordPress, or plugins, or themes. If, for example, you needed to test your plugin on an old version of WordPress, you would have to manually install it.
This process keeps all the sites on one file-system, so updates to files on one site will affect all of them. But an easy solution to this is to create completely different installs (files included) for the different versions you want to keep. So instead of a new install for every single project, you can set up each different environment and test your project accordingly.
I like to keep one WordPress website as a sandbox where I can play around or work on personal projects like plugins and themes. For local development, I also recommend these plugins to make the development process faster and easier.
- Advanced Custom Fields PRO – For working with custom fields. The Pro version let’s you quickly import/export between sites.
- All-in-One WP Migration – The best migration option for WordPress. Includes database search/replace.
- Code Snippets – Create a library of snippets to turn on and off. Supports import/export so it’s easy to copy files to new dev sites.
- Custom Post Type UI – Generate new custom post types easily. Also supports import/export so managing CPT’s across sites is easy.
- Duplicate Post – Clones posts/pages/CPTs. This is nice for generating duplicate content easily.
- FakerPress – Rapidly generate placeholder content to test out your local sites.
- Query Monitor – Probably my favorite developer plugin. Shows you all sorts of data.
- Simply Show Hooks – Does what the name implies. Shows you all the hooks firing on a page.
- Custom Plugin – Similar to Code Snippets above, but if you have certain functions you like on all sites you can make a custom plugin.
If you have any thoughts on this, you love it, you hate it, let me know. I’d love to hear what you think.
Originally published on austingil.com.