A well engineered template for creating plugins using object-oriented programming practices. Uses Settings API, multisite, i18n, PHPUnit tests.
This plugin is coded to be installed in either a regular, single WordPress installation or as a network plugin for multisite installations. So, by default, multisite networks can only activate this plugin via the Network Admin panel.
If you want your plugin to be configurable for each site in a multisite
network, follow the instructions in the docblock at the top of
We add some abstraction around WordPress'
Settings API. All you need to do
is add some elements to two arrays and maybe create a section header if you
want. This is way better than having to write out
calls and creating display and validation callbacks for each and every field.
admin.php in your favorite text editor
Read the docblock at the top of the file
This framework uses PHPUnit, so standard PHPUnit file, class, and method naming practices apply. Our framework requires that your test files and classes:
TestCase.phpat the top of the script. That obtains the PHPUnit and other items needed. It's the only file you need to include.
setUpBeforeClass()method, it must call
setUp()method, it must call
tearDown()method, it must call
tearDownAfterClass()method, it must call
Take a look at the
TestLogin.php script for examples of how to handle
wp_mail() (and translations of mail messages) and
the use of database savepoints, and manipulating user metadata.
Please note that the tests make extensive use of database transactions.
Many tests will be skipped if your
are not using the
InnoDB storage engine.
To execute the tests, install and activate the plugin, then use a shell
cd into this plugin's directory and call
While it is possible to test plugins using WordPress' Automated Testing PHPUnit framework, it is a complex system, is another dependency, and runs in its own environment. The benefit of using my plugin's PHPUnit is that it ships with the plugin and executes in the users actual WordPress installation. This means any end user can easily test how the plugin interacts with their site.
To produce the machine readable translations used by WordPress' gettext
implementation, use the scripts I made for generating all of
.potfile as desired.
touch <plugin-id>-<lc>_<CC>.moSubstitutions: plugin-id: the plugin's identifier ($new_id from above) lc: language code CC: country code
Requires: 3.3 or higher
Compatible up to: 4.4.4
Last Updated: 2 weeks ago
Active Installs: Less than 10
Got something to say? Need help?