The Perfect WordPress Development Stack

The “Perfect WordPress Development Stack” is one of those topics that comes up now and again in various blogs (and here it is again – how meta, right?), talks, tweets, and so on.

And I think it’s a good point of conversation. If you’re working with WordPress in a professional capacity, then you should have a stack that maintains some level of professionalism.

But what does that look like? It’s likely that some of you know where I’m going with us and the answer may sound like a cop-out.

It’s not, though. It’s generally what I’ve found to be true.

Perfect WordPress Development Stack

TL;DR:

The perfect WordPress development stack is the one that works best for the work you’re doing on a day-to-day basis, and that helps meets clients needs in the most efficient way.

There’s justification for this, though.

Perfect WordPress Development Stack
A high-level look at what a traditional WordPress development stack looks like.

Let’s say that your client is running a server that uses a combination of:

  • Nginx
  • PHP7
  • A variant of Linux
  • Some type of caching mechanism

Does it make sense for you to be running Apache, PHP5, Windows (and IIS), and no caching?

You can get by with that, but assuming that you have the proper environments set up for deployment and testing, then the chances are high that when you run into a bug, you’re not going to be able to replicate it locally.

The leads to having to poke around the server a bit more and will likely lead to cowboy coding. And that’s no good.

So the way I look at it is this:

  1. Find out the type of environment the client is going to be running on their server. Is it a traditional LAMP stack? Are their subtle nuances you need to adjust? Are they running something that’s a bit different?
  2. Whatever they are running, are you able to set it up as a staging environment, too? If not, why?
  3. Can you replicate the same setup on your local machine?

You want to be able to make sure each environment – the one on your local machine, the staging environment, and the production environment – are as close in similarity as possible. If not, then why?

That should be a blocker. You want to streamline the amount of time it takes to configure a server.

Ultimately, you want to simplify the amount of time it takes to begin implementing a solution and pushing it to the various places it needs to go (source control, staging environments, etc.) without having to worry about configuration concerns.

This allows for streamlined development, more targeted testing, and a higher level of quality of development than when using a variety of different environments to achieve the same goal.

2 Replies to “The Perfect WordPress Development Stack”

  1. Hi Tom,

    sometimes its hard to replicate a customers production environment and often its nearly impossible to replicate this environment 1:1!

    As you already implied it begins with Operating System, kind of server, php and its version numbers. For e.g. countless times i stumbled over a very outdated php version running on a clients server. Trying to replicate such an environment locally only for very little modifications exceeds the worth of the job often so i am pretty sure that i am not the only developer who was guilty of doing such changes on a live site in the past.

    So what to do, refuse the job or give the customer the ability to create a development site on his production server for testing? There are some great plugins like WP Migrate DB or duplicator but they all need complex configurations and paying of attention and time when using them.

    I was looking for a fire and forget plugin that creates a complete development site on the customer server including files and data with just a simple click but there was none.

    So, this was the idea for a little free plugin called WP Staging:

    wordpress.org/plugins/wp-staging/

    It’ still work in progress and may no fulfill all possible expectations but it is working very reliable and does not mess with the data of the production site.

    It is personally very helpful when i release a new version for one of my other plugins.

    i am now able to ask my user to test the updated version first before they install it on their live site. Before WP Staging there was no way for the average user to create a testing site without hazzle.

    This all is working very well and i am hoping that more (plugin) developers will push their user to test new plugin updates first.

    Tom, i am commenting and writing here about WP-Staging because i have the thought that it fits to the content of your posting. I have no problem when you are shortening my comment or when you do not release it. It is my concern that you are reading it and i am really interested in your opinion about WP Staging. I appreciate your thoughts about this.

    Best regards

    René

    1. sometimes its hard to replicate a customers production environment and often its nearly impossible to replicate this environment 1:1!

      This is true, but it’s possible to get as close to 1:1 as possible. Plus, depending on the nature of your work, you may be able to have more control over the environment than in other situations.

      So though you may not be able to, say, get the operating system the same, you can get the development stack pretty close. And I think it’s important to do that.

      Trying to replicate such an environment locally only for very little modifications exceeds the worth of the job often so i am pretty sure that i am not the only developer who was guilty of doing such changes on a live site in the past.

      For sure — I haven’t always been able to replicate changes on my local development environment either, but this has changed with the type of work I do. So each person’s mileage varies based on the type of work they do.

      So what to do, refuse the job or give the customer the ability to create a development site on his production server for testing? There are some great plugins like WP Migrate DB or duplicator but they all need complex configurations and paying of attention and time when using them.

      I think there are other options than choosing to do it or not to do it. You can find middle ground in terms of perhaps migrating them to a better host (or seeing if the host will even upgrade some of their software). Alternatively, you can also install other versions of PHP and MySQL on your system and have them running in separate directories than the rest of your installations (just make sure to update your path accordingly.

      It’ still work in progress and may no fulfill all possible expectations but it is working very reliable and does not mess with the data of the production site.

      This looks pretty cool and it seems like a great idea. It’s a bit different than how I manage my workflow, but that doesn’t mean it won’t be useful for someone else.

      I’d be happy to take a look when I have the chance and share it with others.

      So thanks for sharing that. I think it fills a niche, solves a problem, and could definitely help out developers who don’t have a chance to control the environment as much as they’d like.

      Thanks René!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.