The longer I work with building custom solutions for others in the form of WordPress plugins, the more I am a fan of having a WordPress plugin bootstrap file.
Honestly, this isn’t anything new, but it’s something I like to discuss periodically because the methods in which we build plugins, the ways posts can become outdated, and the strategies that we employ as we get better at what we do for a living change over time.
At least I hope they do. If you’re doing the same thing now that you were three or four years ago, then you’re a stellar developer. Or you haven’t grown that much. :)
But that’s content for another post.
When it comes to the work I do for others, the work is primarily in the creating plugins (which I enjoy building). So it’s only natural that I’d have things to add continually to this topic, right?
WordPress Plugin Bootstrap File
I know that it’s a trendy thing right now to have boilerplate code for everything. And it’s also becoming fun to hate on this stuff.
That’s the nature of the Internet, I suppose.
But this isn’t about boilerplate code. Instead, this post is about a bootstrap file, and I want to make sure that’s clear before moving any further in the post. And for those who are curious, bootstrapping has been around for a long time in the world of computing.
The Purpose of the Bootstrap
With that said, here’s how I view the purpose of a WordPress plugin bootstrap file:
- Define any necessary DocBlocks,
- Set the plugin header,
- Make sure the plugin file can’t be accessed directly,
- Include any necessary dependencies (though this may be achieved differently based on the version of PHP you’re using),
- Start the plugin.
But walking through the steps only goes so far, so I’ll share an example of how I tend to structure my bootstrap files. And I’ll add some notes on how this may change depending on the work you’re doing.
A Template for a Bootstrap
Generally speaking, here’s how I structure my plugin bootstrap files:
This particular structure adheres to the WordPress Coding Standards and also uses a custom tag, namely
@wordpress-plugin to delineate between the documentation and the content that WordPress reads when displaying the plugin in the administration screen.
Secondly, I always name this file the same name as the plugin as per the file naming conventions for WordPress plugins. So within the plugin directory, this is what you’re likely to see:
First, the file is accessed. Then, it follows all of the steps I’ve outlined and creates an instance of the plugin.
Why Instantiate the Plugin This Way?
Though WordPress affords us the ability to write out plugins in both procedural programming and object-oriented programming, I’m a fan of the latter. Thus, I define a function that instantiates the plugin and then the lifecycle calls the function at the end of the file.
This doesn’t interfere with the $GLOBALS collection, this doesn’t require we add the plugin to any particular hook, and it doesn’t require that the plugin is dependent on any other third-party aspect of PHP or WordPress.
To be clear, this doesn’t mean that it can’t be dependent upon it. In fact, I’ve found this approach to be one of the most flexible.
- If I wanted to hook the instantiation of the plugin into a hook, then I could add the function definition to one of WordPress’ hooks.
- Similarly, if I want to instantiate the plugin in another area of WordPress, I can do that by just removing the function. You would then need to add the plugin file in some other way, but it’s still possible.
- Keeping code separate from dependencies makes it easier to unit test (though it’s easy enough to unit test WordPress plugins through the use of WP-CLI).
That said, there are still other ways in which you may go about bootstrapping your WordPress plugin, and I’m all for hearing what other options there are.
This particular strategy has worked well for me for the last few years and its one that I’ve iterated on, more of less, to make it as consistent as possible.