The WordPress plugin bootstrap file contains the name of the plugin, version, author, description, links, etc. all in a header. All plugins begin with this information. What follows is usually unique; there are security concerns and decisions made by the developer to follow procedural or OOP design patterns.
XenWord has gone through numerous revisions. The first file, though, has rarely been modified. This weekend, I decided the file needed updating. The PHP version of the server needed to be detected and the plugin deactivated gracefully if the PHP version was not at least PHP 5.3. My hope in making the change was to stop people from trying to activate the plugin when the server doesn’t meet requirements.
After fussing for quite some time, I settled on a class named XenWord_Pro, and instantiating it at the end of the file. Five methods within the class are the constructor, php_check, load the required files, show a notice if something goes wrong as well as gracefully deactivate the plugin.
I’m not happy with the lack of adding a namespace at the top of the file but my understanding is too rudimentary. Too many issues were caused with the plugin when a namespace was added to the top of the XenWord class.
The nicest part of the changes is that the skeleton can be used for future plugins.