Basic structure of a WordPress plugin
Writing a WordPress plugin is not difficult with a little bit of 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 which method to use. At least that's how I felt at first.
Therefore I would like to show a basic structure or boilerplate plugin that I use for my WordPress plugins . I am primarily a front-end developer and I am much more familiar with HTML and CSS than with PHP. So if you have any suggestions for improving my approach, please leave a comment. Thank you 🙂
Basic structure of a WordPress plugin
Basically, a simple WordPress plugin can only consist of a single file. All that is required is a header comment with the plugin information so that the plugin can be recognized by WordPress. You can find all possible variables for a WordPress plugin 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, so 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 instantiated with new Class_Name()
.
The construction of a WordPress plugin with the singleton pattern is also very popular, which ensures that only a single object instance of the plugin class exists. If you want to dig deeper into object-oriented programming and design patterns in WordPress plugins, you should read Tom McFarlin's blog .
Especially these posts:
- Object Oriented WordPress Plugin Development
- An Introduction To Design Patterns in WordPress
- Singleton Design Pattern and Dependency Injection
My basic framework for WordPress plugins
At the moment I mostly use a static class as the basic setup of my plugins. Since no plug-in is really complex, the singleton pattern seemed too exaggerated. Its advantages would not come into play in my plugins. I haven't needed an object instance for the base class either. But I can certainly 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 tons of other plugins and their implementations. The following code is inspired by these many different sources. An explanation of the functions follows under the code snippet.
The plugin is set up in the Plugin_Boilerplate
class. The setup()
method of the class is called at the end of the plugin file. Basically, most of the code could be located directly in the setup function. For the sake of clarity we use several methods.
First of all, all constants of the plugin are defined in the constants()
method. 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. Here, too, it is important to execute the translation()
function in the plugin early so that all texts can be translated.
If the plugin consists of several files, these are then integrated with the includes()
method. The code snippet uses files as an example for settings in the WordPress backend and the actual features of the plugin.
With setup_actions()
further basic functions of the plugin are called. The method therefore usually consists of a series of action and filter hooks that hook into WordPress. A typical function is, for example, the loading of CSS and JavaScript files.
Conclusion
There isn't one preferred way to create a WordPress plugin. What approach or design pattern do you use?
Hello Brian,
I find it very interesting that you mention object-oriented programming in connection with WP. This is done far too rarely.
I will read your other posts.
many Greetings
Mauricio
Hello Mauricio,
Thank you for your comment.
I think which approach is followed also depends on the complexity of the plugin.
Very small plugins with very few functions can save themselves object-oriented programming, but with larger plugins, object-oriented elements often make sense.
I also have to say that I am a frontend developer and mainly create themes, not plugins. That's why I'm not an expert in the OOP field.
LG,
Brian