Published:

What makes up a professional WordPress development environment?

First of all a little disclaimer: I do not consider myself a PHP or WordPress developer. I rather feel home in Java, JavaScript, web app development in general and a little bit in data visualization mostly with d3.js.

So why do I even bother learning WordPress development?

In short, in some of my client projects customers just don't want to pay the price for developing a custom web application. In many cases WordPress offers a viable alternative in terms of functionality, extensibility and budget.

In preparation for an upcoming project, I asked myself these three questions in terms of establishing a professional WordPress development environment:

  • Which local WordPress development environment solutions do exist?
  • What should I put under version control?
  • How to keep development and production in sync?

If you're just getting started in WordPress development, the following article might save you some tedious research time.

Here we go.

Which local WordPress runtime environment solutions do exist?

If you don't want to do WordPress cowboy coding (read the article, it's good), then there exist a couple of solutions to setup a local WordPress runtime environment.

But first, what components does a WordPress runtime environment consist of?

  • Apache / Nginx
  • MySQL / MariaDB
  • PHP

Sure, there might be some more components. But these three are the basic ones.

Here are the in my opinion most promising solutions that can help you with setting up a proper WordPress runtime environment on your local machine:

  • MAMP: My Apache - MySQL - PHP
    • Seemed to be the go-to solution for a long time.
    • Disadvantage is that all software runs on your machine. You might consider this as a pollution of your host system.
    • I heard people saying on the web that working with it are still quite comfortable.
    • Drawback might be that you're bound to one runtime environment (i.e. Apache in version X, PHP in version Y etc.), which could become a problem when production environments are varying amongst your projects.
  • DesktopServer
    • It's a XAMPP stack (so comparable to MAMP) claiming to make it really easy to setup WordPress instances.
    • Haven't taken a closer look at it because they seem geared towards selling their premium product. However, I've came across some posts and comments in which developers recommended it.
    • Might be an option if you plan to become a fulltime WordPress developer.
  • Varying Vagrant Vagrants
    • Also called VVV.
    • A Vagrant based environment for WordPress development.
    • Comes with Nginx, but you can edit the Vagrant provisioning of course.
    • You need Vagrant and VirtualBox installed.
    • Nice thing about Vagrant is that all is based on virtual machines, thus no pollution of your host system.
    • Second nice thing is that you can have different software versions for different projects.
    • Third nice thing is that you can share the Vagrant file, which describes the whole runtime environment, between developers.
  • Trellis, sort of a competitor to VVV
    • Also based on Vagrant.
    • Uses Ansible for provisioning and configuration.
    • Claims that dev and production boxes are identical, which is also called development & production parity.
    • Looked appealing to me. But it seems that the creators base a business upon this (selling consulting or whatever, I don't know exactly), which is kind of a smell for me.
  • Docker
    • Personally I'm not a big fan of Docker due to my experiences at my old job. Biggest struggle back then was to understand the concepts and setting things up correctly.
    • Vagrant vs Docker: Which is better for WordPress development? is describing some of the differences between Docker and Vagrant for WP development. Also see the article comments for various opinions and further runtime environment options.

VVV - my choice

I've chosen to give VVV a try. Here are some of my experiences after a few days using it:

  • VVV is heavier I thought it would be. It comes with a ton of stuff in the virtual machine I don't know if I will ever need it. The consequence is that vagrant provision is painfully slow. Slow means a couple of minutes.
  • When you need to change configurations, e.g. when you begin a new website, you need to run the slow provisioning step repeatedly.
  • What I like is that once provisioned, things are working really well.
  • When setting up the MySQL database for my test site, I had a short struggle
    • You need to edit an init-custom.sql script to setup the new database, basically. My problem was that I wanted to create a new database user as well.
      • But MySQL does not support CREATE USER IF NOT EXISTS until lately in version 5.7.8. Because IF NOT EXISTS isn't supported when creating a user, the script would throw an error on each provision execution in case the user already exists. Therefore I had to create the database user manually. That's it.
  • What is really nice about Vagrant, and thus VVV, is that you're editing code in the file system of your host machine. This means that you can work with your trusted development environment, for example PhpStorm, on your primary OS. This by the way is facilitated by Vagrant Synched Folders.
  • Of course Vagrant, and thus VVV, allows connecting to the WordPress site with the browser on your host system.

What should I put under version control?

In WordPress you're able to extend functionality in various ways. So if you've chosen to use a certain theme, you can override it by putting your own files into a specific place in WordPress' folder structure. You sure agree that putting your own files under version control is a good thing.

However, the question is what else to put under version control. There are people saying that you should also put WordPress code itself into your git repository. Some people say you should rely on Composer, a dependency management system for PHP, instead.

Here are some resources that talk about that aspect:

What I put into git

To be honest, I've not yet decided what to do in this regard. For now I've chosen to keep it as simple as possible: I only git-control my own files. That keeps the repository size to a minimum. And I can go another, more sophisticated route later on as well.

How to keep development and production in sync?

If you've chosen to rely on WordPress, you are probably using some thrid-party plugins or themes. As a consequence you probably would install those in your local WordPress instance, configure these via the WordPress admin page and so forth. This probably will add new tables and change configuration data in the database.

Because you don't want to configure plugins twice, how do you move those plugins and settings onto your production server?

FTP, SFTP or SCP help you to transmit the plugin and theme files. It's a different story with plugin and theme settings stored in the database. This article suggests using the WP Migrate DB Pro. Cool thing about it is that you can synchronize databases in both directions. In the first project phase you might want to push the local database to the production one. Later on, when the website is in production, you can reverse this process. However, there's is one little concern: does using WP Migrate DB open up a security risk?

Conclusion

These were three questions I asked myself while preparing my first WordPress project and I hope, my findings are useful for one or the other as well.

Published by Robert Möstl

« Back to Blog