Plugins in POS are collections of classes that will only be loaded if the plugin is enabled. In some cases like input parsing, all classes that descend from a given parent class are automatically loaded when POS runs. This kind of module becomes functional as soon as the plugin is enabled. In other cases, classes provided by a plugin will show up in configuration options where a user can choose one of the default classes or a replacement provided by a plugin.
At minimum, a plugin should have:
- A directory under pos/is4c/plugins/
- And a class extending Plugin whose name matches the directory
- For example, a plugin folder named "MyPlugin" should contain a file named "MyPlugin.php" which defines the class "MyPlugin".
The remainder of the plugin file/directory structure is entirely up to the author.
Plugins should be free of side-effects when included. The unit test PluginsTest.php will verify all plugins (enabled or not).
Packaging a plugin with Composer
Packaging your plugin with composer makes it easier for other users to install and update your plugin.
- First, get Composer.
- Second, create a new github repo to hold your plugin
- Third, in your new repo run
- Set the
typeof your package to
- Require the
corepos/composer-installerpackage as a depedency
- Set the
- Fourth, add or write your plugin's PHP files.
The MemberCard plugin is a simple example that includes a few additional, optional bits that appear in many plugins.
noautodirectory contains unit testing scripts. The directory name is chosen to exclude those files from CORE's normal class autoloading.
noauto/bootstrap.phpcontains mock versions of CORE API classes
noauto/self.phploads your plugin's classes
noauto/Test.phpcontains PHPUnit tests.
phpunit.xmlfile tells PHPunit about the test scripts in
composer.jsonfile contains an extra
"exclude-from-classmap": ["/*.php", "/noauto/"]. This tells Composer not to autoload your plugin classes; CORE will be responsible for autoloading them instead.