WordPress Widgets: Refactoring, Part 6 There's a problem we're facing with namespaces and autoloading and that's what we're going to review.

You should be well-versed in the refactoring we’re doing regarding the WordPress Widget Boilerplate. If not, I recommend catching up on the series thus far by:

As far as the code base goes, we’re in a good place right now. We’ve begun to refactor much of the code into smaller, more focused classes. And we’ve just set up a Registry so that we can begin working with instances of objects throughout the plugin without the need for too much coupling.

But there’s still a problem we’re facing and it deals with namespaces and autoloading. I’ve talked a bit about this a couple of years ago but not as it relates to Composer.

And that’s what we’re going to look at in this post.

The WordPress Widget Boilerplate: Refactoring, Part 6

In the second post of this series, we started talking about Composer. If you ask most PHP developers (including those who work WordPress), you’re likely to hear that Composer is a package manager or a dependency manager.


In short, it’s a way for us to bring third-party libraries into our project and then utilize their features (so we don’t have to write our own code to do so).

But there’s another feature that Composer offers that’s of immense utility especially when you’re using a lot of classes and don’t want to use require_once statements throughout your code base.

And that’s the autoloader.

⚠️ Hey, Wait!

Thanks for your interest in this article! Note that it's available to members only. If you'd like to review this (and have access to all previous and future articles), check out the membership benefits.

Adding Functionality

Now that we have all of the necessary pieces in place, it’s time to start using Composer, the autoloader, our abstract classes, and our Registry to begin adding some basic functionality to the WordPress Widget Boilerplate so that we have something to show for our work.

For those who are curious, right now I’m planning to keep the branches organized as such:

  • master will be what’s available for anyone and everyone who wants to build a WordPress Widget,
  • develop is strictly for developers include those who know how to use Composer and the topics discussed in this post,
  • release is what will be used to provide a working demo.

For now, though, review what’s covered in this post and we’ll resume this in the next post.