If you’ve not read last weeks post (and you’re a member of the site), then I urge you to do so now as this one picks up exactly where the previous one left off.
In short, we’re going to start talking about configuring Visual Studio Code for professional WordPress development. Of course, that raises a question: What is professional WordPress development?
If you ask ten different people, you’ll probably get 8-10 different answers; however, I’d define it as using professional software development practices within the context of WordPress.
Naturally, right? But what does this entail?
Off the top of my head, I think of:
- Using proper dependency management tools such as Composer, NPM or Yarn,
- Debugging using breakpoints (over var_dump and echo),
- Knowing how to format code using a given standard (PSR in the case that I’ll be using),
- File organizational structure,
But before getting into all of that, I think it’s important to get the IDE set up in such a way that looks good, plays well with the way that we want, and that we understand how it works so we can further tweak it as the need arises.
So in today’s post, we’re going to look at exactly that: Understanding how Visual Studio Code manages settings and a proposed list of configuration options that will help make your experience as solid as possible.
In the previous article, I walked through the process of setting up a local development environment using a package manager. Specifically, I talked about using Homebrew to install Valet and Composer.
The former offers the Nginx web server, a MySQL database server, while Homebrew allows you to install PHP. Composer gives you the ability to deal with PHP dependencies. If you’ve not read the post, I highly recommend it as this post is predicated on that entire environment.
Specifically, I’m going to be talking about IDEs. It’s a hot topic, I guess, but if you don’t have a preference then I’m going to walk you through the process of picking one that I think is best (at lest to start with), configuring it, and using it in the context of the environment established last week.
I’ve not been coy about my appreciation for Visual Studio or how it performs as an IDE for WordPress, but there are always things here and there I think are worth sharing either for the sake of making it a better experience or for improving our workflows.
Case in point:
How many of us work on codebases large enough that we’re writing comments, code, or other features that yield us dropping TODOs or FIXMEs throughout the code so we can focus on the task at hand?
I think our intentions are good. I mean, we do plan to come back to these, but if they aren’t documented in some way, it’s far too easy to come back and do then.
And sure, you can always do a “find all” at the end of a sprint or before the end of a project of whenever works best for you, but there are extensions that can do this for you.
Yesterday, I walked through the process of sharing databases in Dropbox so it makes sense to follow that up with how to go about sharing Visual Studio Code settings in Dropbox.
That is if you use Visual Studio Code (and I’ve had some people ask Twitter how to do this).
As the same is in the previous post, the same disclaimer that I work on macOS. So this dictates the commands I use, how I create symbolic links, and how I go about sharing settings among machines.
Since this is following up a similar post, why not jump right in?
In earlier posts, I’ve talked a bit about Visual Studio Code the least of which not being the importance of debugging your code with Xdebug.
One of the questions I’ve received (and seen elsewhere around the web) is how to actually setup Visual Studio Code debug configuration. That is, you have Xdebug installed, you have the module specific in your PHP configuration file, but there’s no way to actually activate the debugger within the IDE.
Instead, you see something like this:
This is an easy fix.