Alright, it’s time to continue our journey building our awesome
WP_Query_Builder class! So far, we’ve only designed it to build simple WordPress queries. But not all WordPress queries are simple or easy to model using just a cascading method.
It’s even possible that you’ve run into the limits of the
WP_Query_Builder already. The class that we created then wasn’t a complete solution. It had some serious limitations if you were a
WP_Query expert. You couldn’t use it to perform complex WordPress queries.
What do we mean by complex WordPress queries? We mean queries that use a complex
WP_Query query parameters. At the moment, there are three of them:
So, for this article, we’re going to back to our
WP_Query_Builder class. We’ll add support for one of these complex
WP_Query query parameters. We won’t go over all three due to how complex they are. But you can apply what you’ve seen for this one query parameter to design a fluent interface for the other two.
Continue reading Designing a class to create complex WordPress queries
In a previous article, we looked at how you could create a class to manage WordPress posts. We ended creating a class who’s job it was to interact with the WordPress database. And it did that quite well!
As part of its job, our class also had to be able to query the WordPress database. To do that, we made it easier to reuse code around the
WP_Query class. We achieved that by creating methods that used predefined query arguments.
But have you ever looked at the codex page for
WP_Query? Holy Moley, there are a lot of query parameters in there! It’s pretty intimidating and not always easy to use in practice.
That’s the problem that we’re going to look at in this article. We’ll design a class to simplify how we build
WP_Query objects. It’ll handle all the complexity around
WP_Query query parameters for you. The result should be an easier way for you for you to create WordPress queries.
Continue reading Designing a class to build simple WordPress queries
Learning object-oriented programming with WordPress is a lot like embarking on an epic journey. You’ll experience some lows, some highs and some downright frustrating moments. But it’s all part of the learning process.
And, so far, we’ve done quite a bit of progress on our journey. We’ve looked at various WordPress problems. And we then solved them using a class or combination of classes.
We call this process “object-oriented design“. It’s been the focus of a lot of the articles on this site. Because of that, there’s a good chance that you’ve begun using it in your own projects. (And if you haven’t, you should try it!)
When that happens, you’ll start to notice that your project has a lot of classes. This tends to become a problem for a lot of developers. They wonder, “How do I assemble all these classes together!?” It’s not unusual for them to revert back to the standard WordPress way of doing things when that happens.
This is the problem that we’re going to explore in this article. We’ll look at how you can solve it using a dedicated class for it. To do this, we’ll start thinking about the job of the main plugin class.
Continue reading Designing a class to assemble plugin classes
In a previous article, we went over the concept of events and event listeners. These were classes who were in charge of a specific aspect of an application. This was a more abstract job that touched several parts of an application.
We also saw how you could design these event listeners in WordPress. It required that you rethink how you use the plugin API. (Yes, this is going to be another plugin API article :P)
We’re going to keep going with this idea of events and event listeners. We’re going to design a system for them. We’ll call it an “event management” system. It’s an important tool in your journey to master object-oriented programming in WordPress.
Continue reading Designing a system: WordPress event management
The plugin API is one of the cornerstones of WordPress development. There’s no understating its importance. That’s why it’s such a common WordPress development topic (even here).
This importance doesn’t stop when you start using object-oriented programming. If anything, it gets worse! There are quite a few challenges with using the plugin API with object-oriented programming. The first one often being “What do I do with them?”
It’s the type problem that can stop you in your tracks. You want to learn to use object-oriented programming, but the plugin API gets in your way. You get frustrated with it and go back to what you’re comfortable with. Lucky for you, we’ve already explored it here (using the same link for emphasis!).
So we know how to handle WordPress hooks in a class. That’s good, but, now, we’re going to dig a bit deeper. We’re going to start thinking about the jobs of our classes. Where does the plugin API fit when we start thinking about the responsibility of our classes?
Continue reading Designing classes that use the WordPress plugin API
When building a plugin, it’s not uncommon to need to fetch posts from the database. After all, you might be using your own custom post type. Or maybe, you built a special functionality on top of posts and you want to find them that way. Those are just a few reasons why your plugin might need to query WordPress for posts.
Regardless of the reason, the standard way of doing that is to use the
WP_Query class. This lets us create WordPress queries in a safe way outside the loop. The problem is that they’re not easy to reuse.
For example, let’s say that you want a query to fetch only one result. You’re always going to need to add the
'posts_per_page' => 1 and
'no_found_rows' => true query arguments. That last one removes the
SQL_CALC_FOUND_ROWS query used by WordPress pagination. (You don’t need to paginate one result!) This lets us improve performance a bit by removing the unnecessary query.
Now, you’d need to copy these two query arguments whenever you create a query to fetch a single result. This is far from ideal. So let’s look at designing a solution to this problem. Using object-oriented programming, of course!
Continue reading Designing a class to manage WordPress posts
Developers use WordPress to build all sorts of solutions. They can range from a small website to large application platforms. The larger the project gets, the more common it is to have the need for WordPress to handle custom URLs.
You might want to map a custom URL to a new template, a specific hook or both. These situations get more and more common as you work on larger WordPress projects. This type of problem is a bit of a growing up pain with WordPress.
In framework land, there’s a tool that helps you with that problem. It’s called the routing system. It’s a critical component of most frameworks. It lets you map URLs with different parts of your application.
It’s a tough problem to solve, but a good example of object-oriented design. That’s why we’re going to build one. It’ll show you how object-oriented programming helps you solve harder problems.
Continue reading Designing a system: WordPress routing
Getting proficient with object-oriented programming can feel like falling down a rabbit hole. You break down problems into more and more classes. You feel like it’s neverending and that you could go on forever. You need guidance to make sense of it all.
This is where architectural patterns come in. They’re similar to software design patterns which you use to solve a specific problem. In contrast, you use an architectural pattern to address a set of them at once.
This confers certain benefits to architectural patterns. You get a higher level view of how your classes interact with each other. You then have an easier time piecing everything together.
This is why it’s not uncommon for developers to skip over software design patterns. Instead, they start looking into architectural patterns right away. This is even something I’m guilty of doing (insert audience gasp).
One of the most important architectural patterns is the “model-view-controller” (known as MVC). It’s used by most modern frameworks from Rails to Angular. But does it have a place in WordPress?
Continue reading Thoughts on WordPress and the MVC pattern
Have you met this “Carl” guy? He’s always blabbing about “object-oriented this” and “object-oriented that”. You decide to dip your toes into the subject (maybe he’s on to something…).
You try to apply a subset of what he teaches by creating a class. You start to code it. Life is good. And then it happens. You need to use a WordPress hook.
What do you with them?
Continue reading Designing a class around WordPress hooks
Custom post types are a powerful WordPress functionality. Everyone that works with WordPress long enough ends up using them. A custom post type can be anything. That flexibility is the source of much of its power. When using custom post type, you’re only limited by your imagination (trademark pending).
This flexibility also makes it a great use case for designing an interface. This article will put you in the interface creator seat. Exciting, I know!
As the interface creator, you’re in charge of designing the interface contract. This means that you get to dictate how someone use your interface (insert evil laughter here). It’s not all (evil) roses though.
The job gives you quite a lot of responsibility. This can make it hard for you to know where to start or what to do. Lucky for you, that’s what this article will help you with.
Continue reading Saving WordPress custom post types using an interface