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

De-coupling Domain Logic in WordPress

May 5, 2020 / Tom

Remember that WordPress uses the event-driven design pattern and although we often refer to actions and filters, the concept comes down to hooks. The flow of control through the program goes something like this:

Execute the program,
Whenever the program comes upon a hook (in WordPress, we’ll see do_action or apply_filters), iterate through all of the registered hooks,
Return control back to the program,
Execute until the end.

This isn’t completely different from the Publisher/Subscriber Pattern (or PubSub, for short) but there’s a key difference: The Event-Driven Pattern simply signals that something has happened and if there are hooks, they will fire. The PubSub Pattern will tell a registered subscriber to do something.

Anyway, back to hooks in WordPress. Keeping the two concepts of hooks that we have may be most easily done by thinking of them like this:

Actions are for doing something,
Filters are for processing data.

If you’re looking to approach WordPress development in an object-oriented fashion, tightly coupling your code to WordPress core by registering your classes via hooks to the core application is not a good idea.

In other words, don’t register your business logic with WordPress. Keep them separate. Here’s a litmus test for if your work is tightly coupled with WordPress: If you can’t run a unit test against your class without loading WordPress, it’s tightly coupled.

So what’s the solution? Delegation.

WordPress Widgets: Refactoring, Part 13

March 13, 2019 / Tom

We’re finally at the final post of the series on refactoring the WordPress Widget Boilerplate. By the end of this post, we’ll have the development branch of our code done, and we’ll be ready to merge everything into the master branch.

There is, however, still a bit of work to do. Namely:

The last thing we’re going to look at after this is tightening up some of the conditional logic along with a word about caching data (since we’re already doing a bit of that in earlier posts).

So those are the two things we’re going to be looking at in this post. Specifically, we’re going to look at handling conditional logic for the front-end and then how to implement basic caching.

WordPress Widgets: Refactoring, Part 12

March 7, 2019 / Tom

As far as refactoring the WordPress Widget Boilerplate is concerned – especially given how far we’ve come since the project started eight years ago – we’ve done a lot of work.

We’ve brought it up to a far more modern standard and we’re making it far easier to work with it such that building future widgets should be easier. And this is not only from the standard of the boilerplate but from an object-oriented standard so that maintenance and code quality is higher.

In the last post, we wrapped up much of the work for the administration area and are ready to begin our work on code for the front-end.

We said:

Next, we’re going to look at rendering content on the front-end. We’re nearing the end, of the refactoring of the Boilerplate but there’s just a bit more to do before we’re ready to merge it into the master branch of the codebase.

So in this post, we’re going to pick up there. Now if you’ve been following along up to this point then you should have everything you need from the develop branch.

If not, be sure to pull it as that’s where we’re going to pick up in the remainder of the post.

WordPress Widgets: Refactoring, Part 11

February 20, 2019 / Tom

In the previous post, we walked through a lot of refactoring that separated concerns into their own classes.

Ultimately, this helps show how we can maintain a high level of cohesion while not only working with classes in WordPress but doing so alongside pre-existing APIs.

Because the last few posts on refactoring the code base have been so long, the current set of posts are focused on small, incremental changes and thus shorter, more focused posts.

As mentioned in the previous article:

But if you refresh the page, you may notice that the sanitization and serialization do not seem to work when retrieving the data. And that’s what we’re going to look into in the next post.

So that’s where we’re going to pick up in this article.

WordPress Widgets: Refactoring, Part 10

February 13, 2019 / Tom

As far as the WordPress Widget Boilerplate refactoring goes, we’re at a good place. A lot of work has been done such that introducing new classes, features, and functionality should be much easier.

And not only that: It should be easier to follow.

Thanks the work in the last post, we have a lot of work to build off of – namely, an basic administrative interface.

Finally, the last post said:

Over the next few articles, this is going to continue to evolve but, as you can see, we’re making sure that we have a single base class of functionality for talking with WordPress and a class specifically for rendering the administrative form.

And that’s where we’re going to pick up in this article. Specifically, we’re going to look at sanitizing and serializing the data as well as retrieving the data saved in the widget.