When working in an object-oriented fashion and trying to de-couple certain pieces of logic such that you can use them without having to rely on other hooks, it’s important to find ways to handle this.
Otherwise, the code becomes tightly-coupled, and you can have hooks, do_action calls, or anonymous functions all over the place.
To simulate the nature of cookies and their feature of expiration, using WordPress transients via the appropriately named Transients API may be a viable solution.
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):
Development,
Design,
Business,
and more.
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.
This is the second, and final part, in a series about – as the title suggests – direct database queries. Specifically, it’s about changing post statuses (but it’s relevant to more than that).
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.
This is not the first time I’ve mentioned this, but one of the challenges that come with talking about writing direct database queries to update information in the WordPress database is that you leave yourself open to something like:
Yeah, but there’s an API to do something just like that.
And, in many cases, that’s right. I’m a big fan of using ’em, too. But there are times where direct, parameterized database queries can be a more optimal choice.
No, it’s not a database but wouldn’t it be awesome if they looked like this? Photo by Tobias Fischer on Unsplash
This is, of course, contingent on the environment in which you’re working the requirements of your project.
So this is yet another post that’s going to be an illustration of how to use $wpdb to quickly update information based on metadata (without using something like WP_Query or WP_Meta_Query to handle it).
I took 2018 off of speaking for several different reasons, and I’m not planning to do much in 2019 (especially with another kid making her debut later this year ❤️).
But given the work I’ve been doing with WordPress over the past few years, it seemed fitting to apply to at least speak at my local WordCamp.
