Carl Alexander shares his year in review -- a great read on the dedication to sharing that powers one of my favorite writers about WordPress.
I feel I should have done this a few years ago. I know that it’s pretty common for writers to do these “year in review”. At this point, I think it’s good for me to be open and transparent about what I do. I always admired Buffer and their values so it’s my way to emulate them a bit. That said, it’s also useful that I have something written down. Our memory has a tendency to alter facts when we just tell the story over and over. This creates a historical record that I can refer to. (Why yes, I am a history geek! What makes you think that?)
In order for this review to make sense, I’m going to have to give you a bit of a background on my current situation. I don’t want it to appear to you that I got to where I am overnight. There’s a story and that story will give you some context about where I am today. It’ll also help you understand how I’m reviewing my year.
With that out of the way, let’s begin!
The story so far…
I quit my job in April 2012 to “start my own software business”. That’s a bit more than three and a half years ago. It’s a bit crazy to think that. It feels like it was longer ago (I have a weird perception of time).
The main reason why I did that is because I get bored with
Each attempt took the MVC pattern and tried to shoehorn it into WordPress. They didn’t take in consideration how WordPress works. It isn’t something that you can neglect or ignore. Does WP API changes this?
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?
So what is the MVC pattern?
The MVC pattern divides your application into three broad components: Models, Views and Controllers. These
Morning full of great dev posts. Carl Alexander covers a full range of options available to the modern WordPress developer.
I gave a talk at WordCamp San Diego 2016 on the modern WordPress server stack. This is the companion article that I wrote for it. If you’re just looking for the slides, click here. Do you remember when you could run a “fast” WordPress site with just an Apache server and PHP? Yeah, those were days! Things were a lot less complicated back then.
Now, everything has to load lightning fast! Visitors don’t have the same expectations about loading times as they used to. A slow site can have serious implications for you or your client.
As a consequence, the WordPress server stack has had to evolve over the years to keep up with this need for speed. As part of this evolution, it’s had to add a few gears to its engine. Some of the older gears have had to change as well.
The result is that today the WordPress server stack looks quite different from a few years ago. To better understand it, we’re going to explore this new stack in detail. You’ll see how the various pieces fit together to make your WordPress site fast.
Before we dive in, let’s zoom out and look at the big picture. What does this new WordPress server stack look like? Well, look no further!
Click for full size
The diagram above gives
Carl explains how Rewrite API serves as a translator between the disney story of WordPress and You.
The story behind rewrite API plays out almost like a Disney movie. You have WordPress and the human (played by you!). Two different worlds. Two different languages. WordPress is a machine and only understands if you talk to it as such. You need to use a cold language of numbers and code so that it can understand you. Do you need to see a WordPress post? You need to ask him using query variables like p=123.
On the other hand, humans are friendly and talkative. They expect to talk to someone using words. They want to see URLs with the post-title and not query variables.
The rewrite API is the translator that brought these two unlikely friends together. Rewrite rules convert your post-title into the p=123 query variable WordPress wants. Both sides get their happy ending (yay!).
How does the rewrite API do this?
At its core, the rewrite API is about rewrite rules. WordPress uses rewrite rules to convert your human-friendly URLs into ones it can use. There’re two components to a rule: a regular expression and a redirect URL.
The regular expression is what makes the rewrite API so complicated (and also intimidating). WordPress attempts to match any URL it receives to a regular expression.
Unit Testing is a must for any professional and robust WordPress plugin. Carl walks you through the basics of the How's and Why's of Unit Testing. Great resource for plugin authors.
I gave a talk at WordCamp Toronto 2015 on WordPress unit testing. This is the companion article that I wrote for it. If you’re just looking for the slides, click here. “But this worked the other day!”
I don’t know about you, but reading that sentence just frustrates me! Don’t you hate when things worked one day and it doesn’t the next. It’s the stuff of (developer) nightmares.
What if there was a way to ward yourself against that evil? Well, you’re in luck because that’s the goal of software testing! It prevents this situation from happening over and over again. On top of that, it helps you improve the quality of the code you write. Awesome!
Now, software testing is a HUGE field. You have a ton of different types of testing. Each with its own purpose (and, sometimes, philosophy). Today, we’re going to focus on just one type of testing. It’s called unit testing.
Well, in the full spectrum of testing, unit testing focuses on testing at the smallest scale. In most cases, that means inputting values into a function (or object method). You then check at what comes out at the other end.
“Checking what comes out at the other end” tends to boil down to two things. You can verify that the function
You don’t have to find any more excuses. You can give yourself and your client a fast and secure server with: Nginx MariaDB (MySQL replacement) HHVM PHP-FPM (automatic fallback) Redis WP-CLI Varnish (optimized for WordPress)
Hosting your WordPress site is an annoying problem. You can’t go far to see a discussion about it. Every week, someone asks who’s the best host. And each week, you never know if you’ll see conflicting answers or a consensus. It’s not like you can live without hosting either. That puts you at the mercy of hosting providers. This isn’t to say that hosting providers are evil. I think a lot of them are good and mean well.
It’s just that, regardless of their intentions, it doesn’t change things for you. Hosting is a critical part of your client’s experience with your service. They’ll call you if their site is slow, down or even hacked. They’ll question the quality of your work because of it.
But it’s more often than not a result of their decision. Clients skimp on hosting all the time. It’s one of the aspects of a project that your client tends to neglect the most. You know this. You’ve lived it many times.
Your client thinks: “Why should I pay $50/month (or $100/month with SSL!!) for premium hosting? I can get something for half or a quarter of the price.” Of course, it sounds great to them.
Except you’re left holding the bag when things go wrong.
You need your Apple experience
Managing WordPress hooks properly with OOP programing is tricky. Carl Alexander shows us smart system for managing the plugins API. #carl2016
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.
Before we begin, let’s do a small recap on the plugin API language. When we talk about the plugin API, we often talk about action hooks and filter hooks. Actions are is a type of signal that the plugin API emits. Anyone can listen for those signals and react to them.
Filters are a bit different. They’re also a type of signal that the plugin API emits. But that signal also contains data that you can change and send back.
Now while those two types of signals do different things, they’re the same under the hood. They use the same system
Most of the time when you are programming with OOP in PHP and following the Single responsibility principle for classes you end with a lots of classes. Here is Carl's idea about how to assemble those into main class.
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
Looking at how, what and when files are run by WP in the load process. Understanding this is critical to understanding the code you're developing and how it plays with the code of others.
I’m sure you woke up thinking “I wish I knew more about WordPress loading.”. Ok… maybe not (it’s just me isn’t it?). It’s just not something you deal with every day. No, plugins and themes make up your days. That’s what you use to build your custom WordPress solutions. There’s no need to know about the internal process that starts up WordPress.
Yet you can’t ignore it once you start building complex WordPress solutions. Or if you plan on distributing a plugin or theme. That changes the dynamic of things.
Your little world with the plugins and themes you know is gone. You’re in the larger (and messier) WordPress world now. That means you have to play nice with everyone else (damn).
That’s why loading is important
A good understanding of the WordPress loading process helps you navigate these troubled waters. It’s where you can make the changes required to make your plugin play nice with others. You can also use it to detect potential issues that might affect how your plugin works.
The loading process is also the starting point to build advanced functionality into WordPress. Your plugin is preparing to change WordPress in a fundamental way. You can make global changes such as:
An object-oriented approach to building a routing system for WordPress by Carl Alexander. Great write up!
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.
But isn’t this the job of the rewrite API?
Not quite. (But excellent question!) The rewrite API allows WordPress to understand human-readable URLs. There’s no question that it’s an important task.
That said, a routing system is a large enough problem that it’s made up of smaller sub-problems. Solving these sub-problems is necessary for
PHP conditionals are so common and easy to use that most of us ignore how easy it is to develop bad habits around them. Luckily, we have Carl Alexander to remind us that "easy to learn" is not always equal to "easy to master".
No set of control structures is more pervasive in programming than if, elseif and else. With a few exceptions, you’ll use at least one per function or method that you write. There’s just no way around it. But conditionals (that’s what we call these control structures) fit in the “easy to learn, hard to master” category. In fact, they’re so easy to use that you can develop some bad habits around them. (This is also a problem with loops.) This can lead to code that’s complex and hard to read or even test.
That said, it’s possible to develop good programming habits with conditionals. This is what this article will try to help you with. We’ll go over some programming techniques that can help make conditionals more manageable.
First, let’s take a look at how PHP evaluates conditionals. This is so often misunderstood when using conditionals. But knowing how PHP evaluates them lets you remove and/or combine conditionals. This, in turn, makes your code simpler.
Evaluation order of a conditional
The first thing that you should always keep in mind is the order that conditionals get evaluated. Most programming languages evaluate conditionals
Another great & really detailed article from Carl about REST API and how to build your endpoints with OOP. Grab a coffee, sit and read.
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!
If you’re already familiar with the WordPress REST API, you might know that it already has a class called WP_REST_Controller. You might be wondering why we’re not just using that class and moving on. Well, that’s a good question that’s worth discussing!
If you look at the code for the WP_REST_Controller class,
Carl Alexander walks you through exactly how to handle AJAX in WordPress while also showing you how to construct your own class to extend.
Learning object-oriented programming has its fair share of challenges. One of them is the large variety of problems and their solutions. That’s why a lot of solutions revolve around using design patterns. Sometimes a problem has a clear solution like the WordPress API client. Other times it’s more abstract like how to interact with the plugin API. These abstract problems are a lot harder to define and solve.
That’s why I want to share how I’d design a class to solve one of those abstract problems. I decided to look at AJAX communication. You can use AJAX to do anything. This means that we can only create a generic outline of what an AJAX handler class would look like.
Before we go any further, let’s go over the idea behind AJAX. AJAX is a way for a rendered web page to communicate with a server without needing to refresh.
For more details, you should take a look at the codex. It does a good job at
Carl Alexander talks details of doing OOP in WordPress, specifically in combination with working with the WordPress Plugin API to avoid coupling and streamline your code. Excellent and highly detailed piece.
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. This means that you can’t build an object-oriented plugin without taking it in consideration. That’s also when the headaches starts. You try to find a solution to the problem. You often go back to the usual solutions such as:
None of the these are great solutions to the problem (especially that last one). That’s because you’ve been focused on your problems. You want that sweet plugin you’re coding to be object-oriented (who doesn’t?).
Meanwhile, you didn’t stop and think about the plugin API. What does it want?
What does the Plugin API want?
You see the plugin API didn’t just appear there. Someone decided that WordPress needed a way for you to alter its behaviour without “hacking core”. This wasn’t a new requirement either. The ability to add filters was around when Matt forked the b2 project in 2003.
That’s because the ability to extend a platform is what gives it strength. You get a community of developers to build for it. This creates
Level up your game by getting deep into the subject. Want to be a pro-WordPress developer? Start reading WordPress core code.
As developers, programmers, software builders, solution creators, we tend to focus on the output of our work. It’s the code we write. It’s also the outcomes that we create for ourselves, our clients and/or our work. How do we get better at it though? That’s what we care about in the end. The obvious answer is to write more code (duh!). What I’ve learned goes against that common logic.
Here’s what you need to do. You need to read more code. Yup, you heard that right. This is what’ll give you the largest skill gains. That’s the secret sauce.
I can hear your disbelief all the way through the internet! Of course, writing code is necessary. After all, you have to practice what you learn… from reading code.
What are you doing when you’re writing code?
You’re solving a problem. Writing code is just a process that you use to do it. So let’s say you hit a problem you’ve never seen before. What’s your first instinct? You google it, right?
You don’t sit down and write code out of nowhere. That’s because you know there’s a solution out there. You can just use it and move on. It’s just human behaviour.
Why is reading code more useful?
To understand that, we have to take a look at how we (humans)
I may or not agree with some of Carl's points but I am thankful for the 'strong opinions, weakly held' reference.
This site has grown a lot in the last year or so. We’ve spent a lot of time going over object-oriented solutions to WordPress problems. So much so that, we have a small library’s worth of material that you can refer to. With any type of growth, criticism will arise. This is a good thing. I’m a big proponent of “Strong opinions, weakly held“. But this can’t happen without discussion and debate. In the long run, I always feel it leads to a better outcome. (Well, that’s as long you don’t get stuck just debating!)
Recently, there was a debate on the nature of the solutions that you’ll see on this site. They’re overengineered. I think this is a valid criticism and I wanted to share some of my thoughts on the whole thing.
We can’t talk about overengineering without first discussing my current teaching thesis. The thesis attempts to answer these two questions:
Why is it hard to teach object-oriented programming to WordPress developers?
Why have so many tried and failed (in my opinion) at it?
This could have been a post by itself. That said, I don’t think it makes sense to explain why we’re using overengineering without
An interesting article about how important WordPress Plugin API is, and how it works. Let's discuss Actions and Filters!
Let’s say that you ran a poll through the WordPress developer community. It asked the following question: “What defines WordPress?”. The odds are that the plugin API would come up near the top. From a developer’s perspective (and for the sake of my introduction), there’s nothing that defines WordPress like it. It’s the workhorse of the WordPress ecosystem. You use to build anything that you want with WordPress.
There are plenty of articles out there that show you how to use it, but little on how it works. That makes it a bit misunderstood and lonely (APIs have feelings you know).
It’s time we showed some love for this hard worker.
Actions vs Filters
The first thing to look at is the concept of Actions and Filters. It’s an important aspect of the plugin API. Actions and Filters serve two different purpose for WordPress. That said, they leverage the same system within it.
Let’s start with the purpose of the “action hook”. When WordPress calls an “action hook”, the plugin API notifies anyone interested in it. Those interested parties can then decide if they’d like do something or not.
That something always relates to how WordPress works. Someone might want to add new functionality
Carl Alexander delivers again walking developers through the best way to build a class for the WordPress Plugin API.
WordPress and OOP don't need to be enemies. I welcome Carl to this site and hope he contributes more of these type of development articles in the future.
As a WordPress developer, you’re always looking for ways to better reuse your code between projects. Your time is valuable and you don’t want to reinvent the wheel each time you start a new project. Object-oriented programming can help you with that. In a previous post, I covered why you should learn it. Now it’s time to take things further by going over the main feature for code reuse. You’ve probably heard about it before. It’s called “inheritance“.
Inheritance is about maximizing the code reuse between your classes. It allows you to create a hierarchy between your classes. That hierarchy creates a “is-a” relationship between your classes.
That’s why a lot of examples follow the formula:
class Car extends Vehicle (Car is a Vehicle)
class Dog extends Animal (Dog is an Animal)
They aren’t practical examples, but they highlight that relationship.
The take away from those examples is that you need to learn to see the relationship between your classes. Once that happens, you’ll be able to leverage inheritance to create reusable code for your projects.
When I covered encapsulation, I mentioned three possible access levels for properties and methods.
“Public” meant that anyone could access
Creating a class to manage how you query posts makes your work more efficient and flexible. Great tutorial for advanced usage for developers of any skill level.
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 the query variables 'posts_per_page' => 1 and 'no_found_rows' => true. 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 variables 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!
But first, let’s take a step back for a moment and think about the
Have you ever built a PHP interface to create WordPress Custom Post types and handle post metas the same way? So, here you go. Learn it.
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.
Before we go any further, let’s look at WordPress post data management. In particular, we want to look at post data in two contexts. What WordPress does when it retrieves and saves post data. The two (retrieving and saving) are quite different.
Retrieving a post
WordPress has a few ways to retrieve a post. You can use functions like “get_post” or a query. Whatever
An expert delivers extraordinary outcomes with WordPress That’s the conclusion I came to after going through the thought experiment. You’re not trying to help someone build a site on a budget here. You’re paid a lot because you deliver expert level outcomes.
This all started with a thought experiment about WordPress recruiting. Something I’ve done a fair amount of in the past. Let’s say I’m looking to hire a WordPress expert. What defines that person as a top tier WordPress developer? What knowledge or characteristics am I looking for?
WordPress powers a large part of the web. It’s also the livelihood for thousands of developers. Those are amazing things, but it also creates problems. One of them is that it’s hard to evaluate your or someone else’s skill level.
So we’re going to look into that. It’s worth noting that there’s no definitive or objective answer to that question. We’re all biased. We have our own opinions on what it means to be an expert.
That doesn’t mean that you shouldn’t try to answer the question. The goal here is to help you think about where you stand on the topic. It’s also an opportunity to think about where you are and where you’d like to be.
Let’s focus on things you can learn
It’s not that soft skills like a “strong desire to learn” or “problem-solving attitude” aren’t important. They’re mandatory for achieving any mastery (not just WordPress) and employers love them too. They’re just not something you can teach
Carl Alexander walks you through designing a basic Class for WordPress queries. Useful for theme and plugin authors alike, this really helps level up your knowledge not only of WordPress but best practice coding standards as well.
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.
Before we proceed any further, we should take a moment to answer this question. Now, we know that the job of the WP_Query class is to do just that. It lets you query the database without the need for you to know any SQL. You just need to fill an array with query arguments
Carl delivers a great technique for attacking importing data across platforms using the "Strategy Pattern". Check it out.
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 plugins 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.
So what is this strategy pattern and what’s so great about it? Well, let’s go back to the migration scenario that we want to look at. A common way of migrating someone away from another plugin is to create an importer.
In practice, you can break the job of an importer into two smaller jobs. First, it takes data from the other plugin and converts it into data that your plugin can use. Once it’s done that, it saves that converted data into the WordPress database.
Now, let’s say that you wanted to create classes for these importers. Your first instinct might be to create a class for each importer.