In a previous article, we saw how to design a system for WordPress admin pages. The article was an excellent resource for anyone looking for a system to solve that specific type of problem. But it was only a starting point. (That said, you should take the time to read it before reading this article.)
All that we did was convert code from another article into the WordPress admin page system. We didn’t look at any other use cases besides the ones covered in that article already. But the reality is that there are a lot of them.
For example, the article only looked at how to add submenu pages. But there are other types of admin pages besides that one. The admin page system should be able to handle them all.
This is one of several advanced use cases that you might encounter with the WordPress admin page system. That’s why the system as we saw it so far is a great place to start. But handing these uses cases like different types of admin pages might be necessary depending on the kind of project that you’re working on.
Continue reading Improving a system: Different types of WordPress admin pages
In a previous article, we saw how to design a class to represent a WordPress admin page. The article was an excellent resource for anyone looking to design a class to solve that specific type of problem. But it was only a starting point.
For example, we used the settings API to handle forms. But the settings API doesn’t quite do the job for every use cases. For those other cases, you’re going to need to manage the submission of a form yourself.
But to handle these different use cases, we’re going to need a more solid foundation. So we’re going to take the work that we did to design our admin page class, and we’re going to take it one step further. We’re going to design a whole system for WordPress admin pages.
Continue reading Designing a system: WordPress admin pages
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
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
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