ColdBox Plugins have graduated to become just models. The plugins convention has been removed and all WireBox references to plugin injection or DSL's are gone. You now just place all your plugins in your models directory and request them via getInstance() or getModel() calls.

Plugins are an old ColdBox convention but their baggage doesn't really serve a purpose now that we have modules for easy packaging of libraries and WireBox for easy creation of CFCs. Neither of those existed back when Plugins were birthed. It's time to say goodbye to the concept of plugins, but all their functionality will still be here, just with a slightly different (and more standardized) way of creating them.

// old
getPlugin("MyPlugin")
property name="foobar" inject="coldbox:plugin:foobar";
property name="foobar" inject="coldbox:myPlugin:foobar";

// new
getInstance( "foobar@myModule" );
property name="foobar" inject="foobar@myModule";

You'll notice ColdBox used to make a differentiation between core plugins and custom plugins.   There is no such difference now.  A couple plugins that got baked into ColdBox as model such as the HTMLHelper and XMLConverter plugins are now simply called HTMLHelper@coldbox and xmlConverter@coldbox.  All the rest of the plugins that were shipped off into modules are simply namespaced by the module name which is the standard model convention for modules.

• sessionStorage@cbstorages
• ValidationManager@cbvalidation
• messagebox@cbmessagebox
• i18n@cbi18n
• QueryHelper@cbcommons
• etc...

If a model isn't defined, check and make sure you have installed the module and reinitted.  When you install modules via CommandBox, you can use the handy list command to check and see.

CommandBox> list
Dependency Hierarchy myApp (1.0.0)
├── coldbox-be (4.0.0)
└─┬ cbvalidation (1.0.0)
  └── cbi18n (1.0.0)

Plugin Base Class

With the removal of plugins, coldbox.system.Plugin no longer exists. If have custom-written plugins that used some of the convenience variables such as controller, logbox, or wirebox that came from this base class, you'll need to inject them using the appropriate injection DSL. If you were using any of the convenience methods such as getRequestContext() or getRequestCollection() should be delegated to the appropriate service or the ColdBox controller.  (The request context can be obtained from the RequestService)

Any variables or methods related to instance.pluginName, instance.pluginVersion, etc serve no purpose now and can be removed from the code.

Sharing Code

So now that plugins are no more,  you have two main options for sharing a bit of code with other developers that you want them to be able to easily drop in and use.

1. Put on ForgeBox as a model.   This works well for very small stand-alone pieces of functionality that don't need a load/unload lifecycle and don't depend on anything else.
2. Put on ForgeBox as a module.  Modules can be very simple, but also can allow for multiple models, configuration, a load/unload lifecycle, and other dependencies.  This is the recommended approach for any bit of code you want to share since it's the most flexible.