Ask anyone who’s been to a WordCamp and one of the things that you’re likely to hear that has the most benefit is “The Hallway Track.” The’s debatable on if it’s the most benefit, but it offers a lot.
For those who’ve never been to a WordCamp, then think of it this way: WordCamps are usually divided into tracks throughout the day.
These may include (but aren’t, of course, limited to):
The Hallway Track, though, is an unofficial name given to the time spent in between sessions where you get to meet people, see people you already know, or talk more about the things you’re working on, you’re learning, or just find out about new things that are happening in the various facets of the WordPress economy.
What does this have to do with WordSesh, though? Considering not everyone can make it to a WordCamp (for a variety of reasons), quite a bit.
I’ve talked about the importance of using coding standards (whatever standard you opt to use it up to you) and how to get PHP CodeSniffer (especially with Visual Studio Code) set up in several posts.
But there’s an interesting challenge that comes if you want to configure multiple coding standards with PHPCS. And this isn’t that strange a scenario, either.
Imagine you have several different projects on which you’re working – one uses WordPress’ coding standards, one uses PSR2, and one uses some other set of rules defined by the organization for which you work.
And you want to add them all as options to your configuration.
How many times have you looked at someone’s code and stated:
I’m not using this because it doesn’t look well-written.
And in this case, “look well-written” might either be a substitute for:
“look like how I would write it,”
“seem to make sense to me.”
Sure – there are times where using open source code is risky. We know this from the various software and services that show up with vulnerabilities. But, at least for this post, treat those as the exception – not the rule.
This means we’re left with looking at something we may use but opt not to use because it doesn’t seem to be written in a way that we think it should be written.
This is yet another post that’s going to be an illustration of how to use $wpdb to quickly update information based on metadata.
And the code provided in that post works but if you’re looking to make it more object-oriented, then there’s more work that can be done.
Before jumping into the actual post, though, it’s important to note that when it comes to object-oriented programming, there’s a lot of work that can go into the class design and creating levels of abstraction.
At some point, you have to draw the proverbial line between when you’re going to use interfaces, how granular your classes are going to be in terms of what they are abstracting, and the like.
And the purpose of this post is to help provide a better object-oriented design but it’s not an exercise is making this as optimal as possible. I do discuss topics like this in another series of posts.
But keep that in mind when reading through the code throughout the rest of the post.