Occasionally, I’m asked for two quick tips or suggestions that I have for those who are just getting started with writing WordPress plugins.

WordPress Plugins

The assumption is that they’ve done all of the necessary leg work to get to the point where they are comfortable writing code and working with WordPress, but they want to avoid some of the pitfalls that many (or most?) of us experience when we first get started on our own projects.

Two Tips for Writing WordPress Plugins

There’s a plethora of tips that I could be shared so maybe this will end up with some additional comments, or maybe this will lead to a series of posts. Whatever the case, there are two completely arbitrary things that I think most developers should know if they’re writing WordPress plugins.

In this particular post, I’m assuming that you’re writing object-oriented PHP with your WordPress plugin.

1. One Class Per File

Whenever you’re creating classes that will be used in your plugin, make sure that each file only contains a single class. In other words, don’t put multiple classes in one large file.

  • A class should have a single responsibility (this is a topic in and of itself) and the files containing the class should reflect that
  • It increases cohesion whenever you’ve got your classes separated into separate files
  • It makes documentation easier to write
  • It makes it easier to navigate the structure of the plugin
  • It improves the readability of diffs when working with source control
  • It makes it easier to maintain as the project grows
  • …and many more.

Otherwise, this can become just as difficult to navigate as a god class. I’m not for blind dogma when it comes to keeping your classes separate – this is more of a strong rule of thumb than not – but there are far more reasons to keep your classes separate than together.

And the latter is the topic for another post.

2. Define Hooks Outside the Constructor

If you’ve taken a computer science or computer programming course at the introductory level, then you’re likely familiar with the idea that the constructor is used to initialize the object such that all of its properties and dependencies are prepared so the instance of the class can be used.

Hooks are not properties of an object. Instead, they are functions provided by the object and, in the WordPress world, they are basically responses – or handlers – to events that occur during WordPress’ execution.

To that end, placing the hooks in an initialization method and then explicitly calling it when it’s ready to be fired makes more sense than forcing all of the hooks to be set whenever an instance of an object is created.

Perhaps there are times in which you won’t need the handlers that a class defines – just the properties and business logic that it offers (which also raises the question as to why your class has hooks, as well – another topic for another post).

When it comes to unit testing your classes, having the handler functions accessible via a public interface and not registered with any particular dependency (like WordPress itself) can be much easier.

There are advanced topics such as dependency injection, containers, and design patterns that are worth covering in more detail and which would likely go well in their own post, but they are worth mentioning here.

There Are More

As I said at the beginning of the post, there are many, many, many, many more things that can be shared. If you feel so inclined, please feel free to add your own comments to this post so that others have a reference that they can use when getting started.

On the other hand, I’ll consider making this a little bit more of a common series on the blog.


Join the conversation! 2 Comments

  1. Thx for sharing your thoughts. Especially the second point it interesting. I read this several time now but couldn’t grasp why it is better to remove hooks from your constructor. Few days ago, I started Unit Testing my plugin and now it makes sense to me :)

Leave a Reply