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
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.
Let’s say that your client is running a server that uses a combination of:
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:
- 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?
- Whatever they are running, are you able to set it up as a staging environment, too? If not, why?
- 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.