MyPlugin
, you will need to create a MyPlugin.cfc
and an index.cfm
file. Then zip these together as MyPlugin-x.x.zip
, where x.x
is the version number of your plugin.MyPlugin.cfc
must contain a method named init
. This method must set a variable called this.version
, specifying the Wheels version the plugin is meant to be used on (or several Wheels version numbers in a list) and then return itself.init()
rather than config()
index.cfm
file is the user interface for your plugin and will be viewable when clicking through to it from the debug area of your application.MyPlugin.cfc
, and Wheels will inject it into Wheels on application start.(access="public")
. If you have functions that should only be called from the plugin itself, we recommend starting the function name with the $
character (this is how many internal Wheels functions are named as well) to avoid any naming collisions.core.functionName()
.mixin
attribute.mixin
attribute can be set either on the cfcomponent
tag or on the individual cffunction
tags.application, global, none, controller, model, dispatch, microsoftsqlserver, mysql, oracle, postgresql
.environment
attribute. Using this, you can tell Wheels that a plugin should only inject its functions in certain environment modes. Here's an example of that, taken from the Scaffold plugin, which doesn't need to inject any functions to Wheels at all when it's running in production mode.plugins
folder. Each plugin then has its own expanded subfolder. If a subfolder exists but has no corresponding zip file, Wheels will delete the folder and its contents.?reload=true
to the URL.overwritePlugins
setting to false
development` environment.deletePluginDirectories
setting tofalse
for your development
environment.application scope
. One example of a stand-alone plugin is the PluginManager. If you check out its view code, you will see that it calls itself like this:@parameter
lines give a helpful hint to the user2.x
, a box.json
is required for new plugins. Read the Publishing Plugins chapter for more details on that. One advantage is that CFWheels now includes the version and meta data for each plugin when there's a box.json
file.box.json
file, should you wish to use it for storing ancillary data and settings.2.x
means you can add a .class
or .jar
file, and it will be automatically mapped into the this.javaSettings.loadpaths
setting when the application starts.2.x
is the tighter integration with command-line tools such as Commandbox. We can take advantage of the new testing suite JSON return type and the new CFWheels CLI in Commandbox 2.x to easily build a Travis CI test. It's perhaps easiest to just show the .travis.yml
file - this goes in the root of your gitHub plugin repository, and once you've turned on testing under Travis.org, will run your test suite on every commit.