If you’re working with PHP CodeSniffer in your WordPress project, then you’re likely familiar with how much time it takes to complete indexing all PHP files.
You start up your IDE, configure PHPCS, point it to your set of WordPress rules, and then wait for it to begin doing its job. Don’t get me wrong: I love having it sniff the code while writing it, but it also takes a bit of time for it to finish parsing it.
Granted, this is true of likely any PHP-based project, but how many of those do I write about here? 🙂
Indexing PHP Files
If you’re using PHP CodeSniffer and the WordPress Coding Standards, here’s a quick way to squeeze a little more performance out of your IDE and get a bit more back in your development time.
A Primer On Rules
Here’s a quick rundown of how all of this works:
- You install PHP CodeSniffer and specify a set of rules against which it will examine your code.
- Upon installation, PHP CodeSniffer will index all of the PHP in your projects so it can generate the errors, warnings, and so on, that help you improve your code.
- The rules against which the sniffer evaluates your code are defined in rule files.
With that said, if you’re working on a WordPress project you may or may not have bumped up against the situation where it indexes all of WordPress, its themes, and your installed plugins rather than just the plugin on which you’re working.
This is largely dependent on how you’ve setup your IDE but I know this is something that people experience from time-to-time, myself included depending on the nature of the project, and I thought it worth sharing how to resolve this.
Updating The Ruleset
In my case, I load my dependencies through Composer. Since these files often reside in the vendor
directory of my plugin, these files get indexed by PHP CodeSniffer.
I don’t want that because:
- I don’t want to fix the coding style of a dependency. I’d rather focus on my code.
- I trust there’s a level of quality to the code I’m bringing into my project. This may be foolish, but it’s the truth.
Thus, I need to exclude the vendor
directory from my WordPress Coding Standard ruleset.
To do this, locate your installation of the WordPress coding standards and then navigate to the directory for the rules that you use. I use WordPress
so my ruleset.xml
is located in wpcs/WordPress
.
Next, add an exclusion pattern to the file, so the complete set of rules looks like this (notice line 4):
It’s easy, isn’t it? You can make this as involved as you want.
But if your project requires all of WordPress, some other plugins, or loads other dependencies, then using this strategy to stop indexing all PHP files and focus only on those relevant to your work can save a lot of time (and even your fan from starting up).
Leave a Reply
You must be logged in to post a comment.