Being a plugin developer isn’t easy. You have to get your plugin to work with WordPress. But more often than not, you also need it to interact with other plugins.
This interaction can take various forms. For example, you might need to modify another plugin’s behaviour using the plugin API. Or you might want to help customers migrate away from another plugin (or product) to yours.
This second scenario is the one that we’re going to look at in this article. It’s a good opportunity to introduce a new software design pattern. We call it the strategy pattern.
Continue reading Importing data into WordPress using the strategy pattern
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
In some plugin circles (also know as the “cool kids club”), the coolest kid on the block is the
wpdb class. Plugins go out of their way to be his friend. Lucky guy (or class)!
One plugin that has to be friends with wpdb is HyperDB. If plugins could talk, it would sound a lot like a scene from kindergarden.
Continue reading Helping WordPress make friends with the decorator pattern
In a not so distant future, you’ve grown to be quite the WordPress expert. You work for WSIS (WordPress Security Intelligence Service) as an analyst. You’re given your first field mission.
You have to get in deep with WordPress. You need to get intimate information about a WordPress object. Information even WordPress doesn’t want to give you. You need to gain access without detection. The last thing you need is WordPress to know you’re listening to things.
How would your future self do it? Well, he’d use the proxy pattern (good thing you’re reading this article). The proxy pattern is the equivalent of object-oriented tapping. It’s one way to solve the problem of interacting with a class without it being aware of it.
Let’s look at how it works.
Continue reading Spying on WordPress with the proxy pattern
Let’s talk about the plugin API. You can’t write a plugin without using it. Well that’s not quite true. You could, but you’d have a hard (and unpleasant) time without it though. That’s because it’s the cornerstone of your interaction with WordPress.
Continue reading The mediator pattern in WordPress
Today is one of those WordPress days. You’re sitting down at your computer. You’ve got a plugin you want to write. You’ve heard that object-oriented programming is pretty awesome so you want to use it (obviously).
You create your plugin folder. You add your empty “index.php” (right?). You create your “WP_Kickass_Plugin” class in “kickass-plugin.php”. Sweet, you’re in business. Time to get into the meat of things.
Continue reading Singletons and their use in WordPress
As a PHP developer, mastering object-oriented programming can feel like a never-ending challenge. You start by familiarizing yourself with core object-oriented features like:
You start writing object-oriented code and playing with those features. This can leave you with some mixed feelings. You don’t feel that using those features are worth the trouble. You might just drop everything all together and go back to what you were doing before. That’d be a mistake.
Continue reading Moving beyond the basics with software design patterns