Refactoring WordPress Plugins: A Small Example

One of the ways that WordPress plugins come to be is that, at least in my case, they start off as a collection of functions used to help with a particular purpose for a given project. From there, you think “Hey, maybe someone else will find this useful.”

At least that’s been my experience more often than not.

But the thing is that before you release it for other people to try, you want to go through the process of cleaning up the code. I’m not talking about refactoring WordPress plugins, either – at least not yet.

I’m talking about taking the code, bringing it up to something that will work as a WordPress plugin, and then possibly refactoring the code.

Refactoring WordPress Plugins

Going through the entire process of refactoring WordPress plugins – let alone a single WordPress plugin – can be arduous, but sharing how to refactor a portion of a plugin is something that’s doable.

So I’ll be using an example of how I was using something recently (with the code abstracted a little bit so not to bother getting specific about any given project).

Refactoring WordPress Plugins: Diagramming the ideal path.
Charting the ideal output of options.

Before doing so, though, I think it’s important to share my process may differ – or likely – differs from yours (since many of us have different processes).

  1. Design the component (yes, not even the full plugin) in a notebook,
  2. Come up with a checklist of the use cases in which it should pass and when it should fail,
  3. Write out what data is needed, how it’s needed, and when it should be ignored
  4. Convert all of the above to code.

Of course, I don’t convert all of it literally to code, but you get the idea. Perhaps the most succinct way to put it is like this:

  • Start with a long method that serves the ideal use case. Then refactor that code so the functions are smaller and account for cases in which the result would fail.

So with that said, here’s how the code might look.

1. Writing For The Ideal Use Case

In this example, the ideal use case is when the user loads the options, the options are present, and then they need to perform an action if the options have certain values.

This part should be easy to read, but it doesn’t account for anything except the ideal path through the code.

2. Get a Bit Defensive

Next, I like to make sure that the options are set before try to read them. In some cases, you might want to display a notice, throw an exception, or log information.

In this example, I’m just going to return as it’s easy to read and can be most easily adjusted for your use.

So that handles the options, but what about the case when the options are set but don’t have the values we’re expecting? This means we need also to verify they do. And, if not, ignore them, return, log an error, throw an exception, and so on.

You know: The same thing as above. Except, in this case, I’m not going to take any action unless the code has the ideal piece of information.

3. Getting a Little Lengthy

At this point, the method is getting a little lengthy and is becoming harder to read. Sure, if you’re an experienced programmer, you can make the case that “This is code, it’s not English” but why not aim to make it a bit easier to follow?

Plus, it makes it a bit easier to test. But that’s beyond the scope of this post. Take the options evaluation as the first example of the code.

  1. This is something that can be wrapped up in its function that not only isolates this check but also makes the resulting call a bit easier.
  2. Next, take the second block of code that checks for the ideal option values. This can also be abstracted for the same reasons above.
  3. And finally, set up a function to make sure the expected values are set for each of the values that are specified:

So now you have two smaller methods encapsulating the same check you were doing.

4. The Final Function

At this point, the final function is much easier to read since it has two helper functions that encapsulate their responsibilities while this one is back to evaluating the ideal path through the code:

Suffice it to say that when it comes to refactoring WordPress plugins, this is but one example how to do just a segment of it. But it’s a start, right?

Entire Plugins?

I know, right? Refactoring WordPress plugins is no joke. But if you start with small functions like this and gradually work your way around the codebase, it gets easier.

And if you spend time planning out the project from the get-go, it can save a lot of time in going back and refactoring this kind of stuff.