Before getting started, some terminology may be helpful.

• Instantiated vs Non-Instantiated is defined in Writing Registry Plugins.
• Instantiated plugins have a Supporting Model in the main codebase. The Supporting Model is the link from the main codebase into the plugin, on the main codebase side. For example, the Supporting Model for provisioner plugins is CoProvisioningTarget.
• All plugins have a Configuration Model, that contains basic configuration information, such as what type of plugin it is. The name of the Configuration Model matches the name of the Plugin, for example LdapProvisioner.LdapProvisioner.
• All plugins have a Core Model, which is the link from the plugin into the main data model. (Plugins that don't maintain database state still have Core Models, they just don't have any linkage.) The Core Model is usually, but not always, the same as the Configuration Model. For example, the Core Model for LdapProvisioner is CoLdapProvisonerTarget.
• Instantiated plugins may have a Backend Model in the main codebase. The Backend Model provides common functionality to the plugin. Examples include AuthenticatorBackend and OrgIdentitySourceBackend.

Adding a New Plugin Type

1. Determine if the new plugin type is Instantiated or Non-Instantiated.
2. Add the new type to Writing Registry Plugins.

3. Historically, the Core Model of the plugin type has sometimes matched the plugin name (FooPlugin.FooPlugin), while some plugin types have added prefixes and/or suffixes (FooProvisioner.CoFooProvisionerTarget). Going forward, only the first style should be used. Plugins can still define additional models with relations to the core model. For Instantiated plugin types, define the Core Model format in the Supporting Model:

   // eg: in Authenticator.php: public $hasManyPlugins = array( // The array key is the plugin type "authenticator" => array( 'coreModelFormat' => '%s' ) );

   
   

4. For Instantiated plugins, add the Supporting Model to Co::delete() so that proper cleanup can happen when a CO is deleted.