In a previous article, we discussed how to design a class representing a WordPress admin page. This was important because almost every plugin or theme needs an admin page. But this isn’t the only common thing that plugins or themes add to the WordPress admin.
Another one of those is the meta box. If you’re not familiar with meta boxes, they’re the draggable boxes that you see on the post editing screen. It’s quite common for plugins and themes to add post-specific functionality through them.
This makes them a good topic to discuss with object-oriented programming. (Is there really a bad topic to discuss with object-oriented programming!?) And, as we’ll see, meta boxes have a lot of in common with admin pages. This means that designing a class to represent them will be a lot like what we did for admin pages.
Continue reading Designing a class to represent a WordPress meta box
That means that this is still a great excuse to use object-oriented programming with WordPress. (Yay!) In fact, it’s an excellent opportunity to piece different object-oriented concepts together. This will let us design a system to extend the WordPress REST API!
Continue reading Designing a system: WordPress REST API endpoints
A WordPress plugin can have a lot of different components. For example, some might need to use shortcodes to achieve their purpose. While others might need to create custom post types.
But one component that almost every plugin needs is an admin page. (Or they might even need more than one!) That said, designing an admin page using object-oriented programming isn’t that straightforward. There are a lot of different moving pieces that you have to take in consideration in your design.
A well-designed admin page class will combine these different moving pieces into a cohesive class. The key to achieving this is to understand the role of these different moving pieces in the larger picture of an admin page. We’ll do that by analyzing what makes up an admin page in the first place.
Continue reading Designing a class representing a WordPress admin page
Much like the plugin API, it’s almost impossible to build a plugin without using the options API. This can be a problem if you’re trying to learn object-oriented programming with WordPress. You need a way to build a class around it.
Lucky for us, this is a lot less complicated to do than with the plugin API. The options API is really nothing more than an API around a data store. Our job as designers is simple. We need to design a class that mirrors this API.
That said, we don’t have to limit ourselves to just copying the options API as is. We can also push things further by adding some extra functionality around it. This is what makes designing a class around the options API so interesting.
Continue reading Designing classes for the WordPress options API
If you use object-oriented programming, there’s a good chance that you’re familiar with the constructor. It’s this special method that an object-oriented programming language uses to initialize a new object. In PHP (and a lot of other object-oriented programming languages), the
__construct method is a special method reserved for the role of constructor.
The role of the constructor isn’t always well understood. This is especially true when you’re new to object-oriented programming. You know the method exists, but you’re not too sure how to use it.
This can lead to some less than ideal practices around constructors. This is especially true in the WordPress world where two such practices are popular. First, there’s the habit of putting hooks in the constructor. And, because of that habit, WordPress developers tend to overuse the singleton pattern.
These two practices show a misunderstanding of the role that a constructor plays inside a class. This isn’t how object-oriented programming wants you to use constructors. There are other ways to solve those problems without sacrificing the role of a constructor.
Now, this isn’t to say that constructors don’t have any problems either. They do! In fact, that’s why we’re looking at the static factory method pattern. It solves one common problem that constructors have in PHP.
Continue reading Using the static factory method pattern with WordPress
As WordPress developers, we often have to generate HTML content for our plugins. (And, if you’re building a theme, that’s pretty much mandatory!) But generating HTML inside a function or method is messy. You have to close your PHP tag, write your HTML, reopen your PHP tag and so on.
This combination of HTML and code isn’t ideal. You’ve coupled your templating to your code in a way that often doesn’t scale well. That’s why it’s common to see such functions or methods grow out of proportion.
The common cause of that is adding conditional logic into the HTML code. This increases the complexity of the code and reduces its readability. So we’d like to avoid that if possible.
It’s worth pointing out that mixing HTML and PHP isn’t bad per se. After all, PHP is also a templating language. We just want to create a proper delimitation between what is regular PHP code and what is PHP template code.
So let’s find a solution to this problem! The twist (well it’s not really a twist for this site…) is that we’re going to use object-oriented programming to do it. We’ll design a class that generates HTML using PHP template.
Continue reading Designing a class to generate HTML content in WordPress
So let’s talk about coupling! Coupling is a complicated problem because you can never get rid of it completely. All that you can do is control how much it spreads. And there’s more than one way to do that.
One of these ways is the dependency inversion principle. It’s one of the most important principles in object-oriented design. And it’s why it’s part of the famous SOLID design principles. (It’s the “D” in SOLID.)
The dependency inversion principle isn’t something that you see with WordPress. That’s because most WordPress developers don’t use object-oriented programming. (But it’s always a good time to start if you’re not using it!) And the dependency inversion principle only helps when you’ve been using it for a while.
But what makes the dependency inversion principle special? Why is it such almost a mandatory aspect of object-oriented design? These are good questions that you deserve an answer to.
Continue reading Dependency inversion principle and WordPress
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