If you approach a lot of WordPress plugin development from an object-oriented perspective, then you’re eventually going to hit a point where you’re not doing a lot of interaction directly with WordPress core itself.

And, in my mind, that’s a good thing. It’s a sign of an architecture that you’re properly structuring your code. That is:

  1. You have WordPress sitting at the foundational level,
  2. You have a set of classes that are sitting just above WordPress responsible for sending information to and from WordPress between the plugin,
  3. And you have the rest of your code that comprises the rest of the functionality.

How this is implemented can vary, but the general way I picture this is the same way I tend to think of the standard N-tier application where you have the data layer, application layer, and front-end.

Except for this time, you have the WordPress, a layer for communicating with WordPress and the rest of your code, and, you know, the rest of your code.

Stop Plugin Execution: How a plugin may be organized.

How a plugin may be organized.

So what happens when you want to stop plugin execution when it has to interact with a third-party dependency and should only execute if that dependency is present?

Stop Plugin Execution

Because of the nature of PHP and WordPress, there are some ways this can be done. The code I’m going to share doesn’t prescribe the way to do it.

Instead, this is a way to do it (which has been pulled from something that’s in development). Further, I’ll show how it interacts with a few other components of the plugins, as well.

1. The Constructor

If you read enough articles about WordPress and object-oriented programming, then you’re likely going to find that constructors should not be used to define hooks. And I agree.

It creates an unnecessary level of coupling, and it makes testing things harder. What, then, is the purpose of a constructor in WordPress-based code?

I use it for the same reasons you would expect in any other language: To initialize the properties of the class. In the code below, you’re going to see three things:

  1. I initialize a property,
  2. I check to see if a third-party dependency exists,
  3. If it doesn’t, then I add an error message,
  4. I update the property.

Sure, it’s verbose, but it also doesn’t resort to clever code for initializing values.

(The older I’ve gotten, the more I’ve grown fond of specific code as it makes it easier to read, pick up, and get going with at a faster rate than the alternative.)

2. The Initialization Method

Since we aren’t using a constructor to work with WordPress hooks, this functionality should exist within the context of another method.

This gives us a dedicated place to put this type of functionality, de-couple it from the rest of the class, and have it interact with WordPress only when the method is explicitly invoked.

But remember, the whole point of what I’m getting at has to do with stopping the execution of a plugin – not where to place hooks.

So let’s say that the third-party dependency doesn’t exist, then what? Recall in the constructor, a property was set that will allow us to determine if we should move forward with setting up hooks or not:

And when that’s in place, the rest of the code won’t execute.

A Lot of Words, a Little Code

It sounds like a lot of explanation for such very little code.

But a portion of this is also to try to convey the significance of having parts of a WordPress-based project separated from the rest of core so that the parts can interact with themselves without explicitly needing to talk with core all the time.