Object-Oriented Autoloading in WordPress, Part 3

In the last tutorial, we reviewed the original state of our autoloader and then went through a process of object-oriented analysis and design. The purpose of doing this is so that we can tie together everything that we've covered in this series and the introductory series. 

Secondly, the purpose of doing this in its own tutorial is so we can spend the rest of this time walking through our class, seeing how each part fits together, implementing it in our plugin, and then seeing how applying object-oriented programming and the single responsibility principle can lead to a more focused, maintainable solution.

Before We Get Started

At this point, I'm assuming that you've been following along with this series. If not, then please review part one and part two. This one assumes you've been following along thus far.

If you're a beginner, I recommend reading the initial series in its entirety, as well. Once you're caught up, you should be in a good position to finish out the series as we conclude with the remainder of the source code covered in this tutorial.

What We've Done Thus Far

To provide a quick summary and to make sure we're all on the same page, we've covered the following topics in this series:

  • reviewed the definition of a class interface
  • seen how a class implements an interface
  • reviewed the single responsibility principle
  • analyzed our existing autoloader
  • created a roadmap for our object-oriented version of the autoloader
  • and designed a basic implementation for an object-oriented version of the autoloader

At this point, we're ready to swap out our existing autoloader with the object-oriented based code. Note, however, that this will not be a simple matter of changing out files. 

What We Need to Do

Instead, we're going to need to create the files, make sure they are following the WordPress Coding Standards, implement them, test their implementation to make sure the plugin still works, and then remove the existing autoloader.

It sounds like a lot of work, but if our analysis and design from the previous tutorial was done correctly and proves to be accurate, then we should have little problem doing everything listed above.

Your Development Environment

Before we jump into the implementation, I want to provide a quick rundown of the development environment you should have on your system. Technically, this is something you should already have running as per directions in previous tutorials, but I want to be as complete as possible.

  • a local development environment suitable for your operating system
  • a directory out of which WordPress 4.6.1 is being hosted
  • a text editor or IDE
  • knowledge of the WordPress Plugin API

With that said, let's get started.

Object-Oriented Implementation

In this section, we're going to revisit all of the code that we reviewed in the previous tutorial; however, we're going to be looking at each individual file along with complete documentation.

Additionally, we're going to be including it in our project so that by the end of the tutorial, we'll be able to use this code in place of the single, procedural-based code we used earlier.

Note that each of the following files should be named as listed and should be included in the inc directory. Furthermore, all of this is available for download by using the blue button in the sidebar of this post.





Including the Files, Starting the Autoloader

Now that we have our files created, we need to make two more small changes:

  1. We need to include all of the classes in the inc directory.
  2. We need to get rid of the old autoloader code.
  3. And we need to use our new autoloader with the spl_autoload_register function.

Ultimately, the final version of autoload.php should look like this:

And it will accomplish exactly what we've outlined above.

But Wait, I'm Getting an Error!

At this point, you've done a lot of work. You've refactored your entire autoloader to use object-oriented programming. You've documented your classes and functions. You've created new files, removed code from old files, and you're ready to make sure everything is working as expected.

So, as any developer would do, you launch the browser window to refresh the page, only to be shown an error message:

Undefined function error message

Luckily, this is an easy fix. The problem is that we're attempting to add our meta box too early. To fix this, we'll update the init method in our Meta_Box class to include this:

And then we'll introduce a function that will be hooked to the work we just did:

At this point, you should be able to execute the new code with no problems, no warnings, no notices, and no errors.


Working through all of this might have seemed like a lot—and it was! But the nice thing is that it covered a lot of ground in three tutorials, and it built on the work of a previous series. In that regard, a lot of new topics were covered and new techniques were learned.

Note that I write regularly for Envato Tuts+, and you can find all of my previous tutorials on my profile page. Additionally, I often discuss software development in the context of WordPress on my blog and on Twitter so feel free to follow me on either place.

With that said, study the code we've covered throughout this series (and perhaps the one prior to it), and see if you can't employ some of these techniques in your existing or future work.




Related Articles