Basic structure of a WordPress plugin with a static setup class

Writing a WordPress plugin is not difficult with some experience in PHP. However, there are different approaches and design patterns for the basic structure of a WordPress plugin. Especially for beginners in plugin development, it is difficult to decide on a method. At least that’s how I felt at the beginning.

Therefore I would like to show a basic structure or boilerplate plugin here, which I use for my WordPress plugins. I’m primarily a frontend developer and I’m much more familiar with HTML and CSS than PHP. So if you have any suggestions for improving my approach, leave a comment. Thank you 🙂

Basic structure of a WordPress plugin

Basically, a simple WordPress plugin can consist of just a single file. A header comment with the plugin information is absolutely necessary so that the plugin is recognized by WordPress. All possible variables for a WordPress plugin can be found in the Plugin Handbook.

In the simplest case, a WordPress plugin is just a loose collection of PHP functions, comparable to the functions.php of a theme. Another option is to group functions in a static class, which means that not every function needs a unique prefix, only the class itself.

Object-oriented WordPress plugins and design patterns

In addition to the procedural approach with functions and static classes, plugins can also be written completely object-oriented. Object-oriented plugins use a class with a constructor for their setup and are supplied with new Class_Name() instantiated.

The construction of a WordPress plugin with the singleton pattern, which ensures that only a single object instance of the plugin class exists, is also very popular. If you want to delve deeper into object-oriented programming and design patterns in WordPress plugins, read Tom McFarlin’s blog.

Especially these posts:

My basic framework for WordPress plugins

I currently mostly use a static class as the base setup of my plugins. Since no plugin is really complex, the singleton pattern seemed overkill to me. Its advantages would not come into play in my plugins. I haven’t needed an object instance for the base class either. However, I can definitely imagine using the singleton pattern in the future if it makes sense.

Here is the code of my static base class for WordPress plugins. Before creating my first plugin, I looked at countless other plugins and their implementation. The following code is inspired by these many different sources. An explanation of the functions follows under the code snippet.

The setup of the plugin takes place in the Plugin_Boilerplate Class. The setup() Method of the class called at the end of the plugin file. Basically most of the code could be right in the setup function. For reasons of clarity, however, we use several methods.

First, all constants of the plugin are stored in the constants() method defined. This is done at the very beginning so that the constants are available in all subsequent functions and classes. Next, the language files for the plugin are loaded. The early execution of the is also important here translation() Function in the plugin so that all texts can be translated.

If the plugin consists of several files, these are then combined with the includes() method included. The code snippet uses files for settings in the WordPress backend and the actual features of the plugin as an example.

With setup_actions() further basic functions of the plugin are then called. The method therefore usually consists of a series of action and filter hooks that latch into WordPress. A typical function is, for example, the loading of CSS and JavaScript files.

Conclusion

There is no one preferred way to create a WordPress plugin. What approach or design pattern do you use?