Tag: Object-Oriented Programming in WordPress (Page 2 of 6)

Though the last post in this refactoring series wasn’t incredibly long, I do think it was a bit dense. That is, it required a fair amount of work to get the code in a place that we can more easily work with it.

But that’s just it: All the work we did should make it easier to move forward with the rest of the code we need to write.

And to make sure that we’re taking advantage of the work and the foundation we’ve laid thus far, we’re going to round out the series with a set of shorter, more focused articles that should take less time to read, implement, and understand what we’re doing with the code.

Continue reading

When it comes to refactoring the WordPress Widget Boilerplate, we’ve done a lot of work to bring the code base up to more object-oriented standard. Further, we’ve introduced a variety of other tools that allow us to bring our code up to more modern standards

Now that we’ve spent time doing that, it’s time to jump back into the code and begin refactoring it in such a way that allows for the use of abstract classes and subscribers (that work as part of the event-driven design pattern).

At the end of the previous post, I wrote:

In the upcoming posts, we’re going to look at how we can implement subscribers for the public-facing side of the site (that is, where the widget content is displayed). And we’ll do the same for the administration area of the site.

So in this post, we’re going to do exactly that. Specifically, we’re going to start with working on a subscriber for the widget and then getting the base widget to display on the administrative side of the site first.

Continue reading

In the last few posts, we’ve done a lot of work to bring the code up to the point of refactoring that’s going to be covered in this article.

Specifically, we’ve covered:

• hooks,
• a Registry,
• and Subscribers.

All of these are going to play a role in what we’re going to do today.

Continue reading

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:

• reading the previous post,
• or reading the entire series up to this point,
• and looking at the development branch of the project on GitHub.

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.

Continue reading

In the previous post, we created a Registry that is going to be used to store all of the various classes responsible for giving our widget its functionality.

To do this, there’s going to be a variety of other classes introduced, but before going there, we need to add the Registry to the plugin’s bootstrap (let alone create a bootstrap for the plugin).

Specifically, here’s where we left off:

As mentioned earlier in the post, we need to add this to the bootstrap of the plugin. To do this, though, we need to define our own filter so that we can easily pass the registry around the rest of the plugin (when the time comes to do that).

So in this post, we’re going to focus on doing exactly that.

Continue reading