Local Development for the Independent WordPress Developer Let's start at the foundational level and work upwards starting with local development.

Last week, I said that I was going to be writing a series of posts explicitly focused on practical tools for freelance WordPress developers who are looking to improve their skills.

Specifically, I will be writing about the tools, processes, and more for the Independent WordPress Developer. Thus, the goal is to provide a series of content geared towards those of you who are freelancers or who work on a team of one but are looking to apply repeatable, solid tools and practices to your workflow.

In other words, it’s about using a set of tools designed to help you create the best solutions possible for your customers (and doing so with next-to-nothing in overhead cost).

The challenge that comes with doing something like this is two-fold:

  1. It’s a lot of content,
  2. There’s a [small] learning curve.

So, yes, technically you can go to different sites or areas and learn bits and pieces about these things, but the goal of the upcoming series of posts is simple:

Focus directly on the independent WordPress developer and do so in a practical, easy-to-understand, applicable way.

And that’s what I’m planning to do in the series starting today.

For The Independent WordPress Developer

Regardless of if you’re new to this or if you’ve been doing this for years (maybe even a decade!), I’m going to be writing these posts in a way that will allow you to grow your practices or refine your practices so that you can be better at what you do through the use of tools, processes, and repeatable, practical tasks that translate from project to project.

A Word About Environments

Of course, there’s always the question of where to start, right?

This series assumes that you’re working on a Mac or a Linux-based machine; however, I’m going to make sure I link to anything Windows-specific when possible.

Secondly, when it comes to any kind of web development you always want to make sure that you’ve got three main areas – or environments – set up for your project:

  1. Development. This is the machine you have – the one on which you start building a project. It has the suite of tools you need to write code, test, and evaluate what you’re doing. That means it doesn’t only have your development tools but also tools like a web server, database, PHP, and WordPress along with other tools I’m going to cover later in this series.
  2. Staging. This is the area where you share a version of your working code with your customer. It’s normally accessible via an address on the web and it contains only what’s needed to run your code. In this case, a web server, a database, PHP, WordPress, and the code you’ve written. Finally, this area is meant for customers to see progress, to interact with your work, and even to break something.
  3. Production. This is where the final version of the product is launched. The way it’s set up is similar to staging (which should also be similar to development) except this is the live version of the project where users, customers, and others will interact. It’s the final version and it’s not a place on which development should be done.

I imagine that most of you reading this are already familiar with each above and how the interact with one another. There are, however, ways to streamline the interaction among them. For example, one way to do so is through continuous integration. And that’s one topic that I’ll be writing about in a future post.

This entire series of posts, though, can be pictured as building blocks so we’re going to start at the foundational level and work upwards.

⚠️ Hey, Wait!

Thanks for your interest in this article! Note that it's available to members only. If you'd like to review this (and have access to all previous and future articles), check out the membership benefits.