A few years ago, I wrote a post about Setting Up PHP CodeSniffer in Visual Studio Code (and I’ve recently updated it, too).
But it’s been four years since that post was originally written and, in that time, a lot can change in terms of how we write code.
Four years is roughly an Internet Age, isn’t it?
Anyway, the basic points of that article still stand, but if you’re working on a variety of projects and some of them require different configurations, settings, and standards, then the way you go about installing and configuring PHP CodeSniffer may be different than how you configure it on a system-level.
So if you’re in that position, here’s how you can configure PHP CodeSniffer on a per project basis using Visual Studio Code.
One of the more challenging aspects of working with WordPress is working the fragmented nature of documentation. And I don’t necessarily mean the Codex nor do I mean the Developer Resources.
But I mean the fact that there’s a ton of information spread across blogs (mine not exempt), subreddits, questions and answers on Stack Exchange, and shares via Twitter, and so on.
I’m not making a case that this is inherently bad or good but I am making the case that when given the opportunity to provide a central repository of information for a feature, set of APIs, or tools that it can be extremely helpful especially if it’s written an maintained by the author of something like one of the aforementioned issues.
Case in point: WP-CLI and Alain Schlesser.
Everyone has a different git workflow set up but for the purposes of this post, assume that you’ve got something like the following:
- A branch in which all of your assets, unbuilt, reside.
- A system of continuous integration that builds the assets and creates a new branch or perhaps a new version.
- A branch that’s created by the continuous integration system that contains the built assets.
The main component of this workflow is the continuous integration system. That is, if it fails, then the work responsible for building the assets and creating a new branch no longer work.
And when that happens, we’re left having to do it manually. It’s tedious, sure, but not difficult. If you find yourself in this position, here’s how you can go about building assets, merging git branches, and creating a versioned release.
But as both my family [and I] have grown and as WordPress has changed over the past half-decade (let alone decade), that entire perspective has changed.
Not just that, though.
A few months ago, I reluctantly started to try out using the dark theme that comes with macOS and iOS. I’d already been using a similar theme in my IDE and my terminal, so why not take the plunge for the whole experience across the OS?
Like anything new, it took some getting used to but it’s definitely grown on me up to the point where I spent time looking for something that would allow me to really tweak the tools I used the most to make sure that I’m actually enjoying the day-to-day work that I do.
And that’s where Dracula, hat tip to my colleague Mike England, really got the ball rolling for me.