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.
In previous posts, I’ve talked a bit about why using a proper debugger versus some of PHP’s built-in statements are important. In the last post, even, I walk through how to set up Xdebug with Visual Studio Code (and MAMP Pro, if you’re using).
But if you’ve never used a tool like this before, you’ve never seen how it works, or you’ve never seen why it’s so powerful, I want to cover that a bit in this post.
So I’m going to be walking through a bit of doing this within the context of a few definitions and screenshots as well as a short screencast at the end so I can show the Visual Studio Code debugger working in action.