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.
Stop PHPCS From Indexing All PHP Files.
Granted, this is true of likely any PHP-based project, but how many of those do I write about here? 🙂
We’re celebrating Thanksgiving in the United States today. If you’re doing the same, Happy Thanksgiving!
Meghan did an awesome job with the table – if was left to me, there’d be no photo. :)
If not, I hope your day is going well and that maybe you’ve still got a thing or two or nine for which to be thankful. 🙂
For those who have read my Atom and WordPress Coding Standards post, then you should have everything you need when it comes to setting up the editor to evaluate your code with the WordPress Coding Standards.
Recently, though, the 0.10.0 release of the coding standards were published on GitHub, and it brings a lot of changes.
If you’re looking to begin upgrading to this new change, there’re a few caveats that you may experience when working with Atom and the WordPress Coding Standards.
They’re easy to address, though.
Custom data validation in WordPress is something that many who have built custom solutions for others have likely used.
In fact, anyone who has made a theme or a plugin has probably used some form of data validation even if it’s just escaping some attribute that will be part of the rendered markup.
This is a major step in making sure that anything you’re creating is securely managing information coming from the database.
But whenever you’re working on a custom solution that requires you use various elements and attributes, how can you specify only the supported attributes?
If you’re working on a theme or a plugin for WordPress and you want to highlight an active submenu item, then your implementation is going to vary based on where you want to highlight the actual item.
An overexaggerated menu to help drive this point home.
This is one of those times where it’s helpful to have clear terminology for what you’re trying to modify:
- Are you working on trying to highlight an active submenu in the admin menu,
- Or are you working to highlight an active submenu on the front-end of the theme?
There’s no consistent way to do this. For what it’s worth, I don’t think they should be as they are two completely different entities (for lack of a better term). Perhaps having some semi-consistent filter names would be nice, but that’s about it.
Regardless, when you set out to highlight an active submenu item, it’s important to note which part of the project you’re working on and then go from there.