Plugin.xml

From Cerberus Helpdesk Wiki

The plugin.xml file tells the platform about your plugin. Every plugin must have a plugin.xml file. The format for the plugin.xml file can be found below.

• <id> must be unique across all Cerb4 plugins. This is a dot-delimited namespace string. The namespace should follow the format "zyxcompany.myplugin"
• <name> is a human-readable name for your plugin. This is displayed on the 'Plugins and Features' tab of 'Helpdesk Setup'.
• <author> is the author of the plugin. You should put your name, or perhaps your company name here.
• <revision> this node is currently unused. Instead, see the <patches> section below.
• <link> A link to a page containing information about your plugin.
• <dependencies> is a list of the dependencies required by your plugin. Each <require> node has a plugin_id and a version attribute. The plugin_id attribute is the ID of the plugin your plugin depends on (not an extension point!). The version attribute tells the platform the minimum version required for your plugin to operate.
• <patches> is a list of all of the patches associated with your plugin. Each <patch> node has a version, revision, and file attribute. The version attribute specifies the human-readable version information. The revision attribute is used by the platform to determine if the patch needs to run. The file attribute contains the path of the file relative to your plugin.xml containing the patch code. Patches are typically a combination of PHP logic and SQL, but you could theoretically do anything inside a patch. If you want a patch to run again, increase the value for the revision attribute.
• <uri_routing> provides a list of the top-level routes your plugin supplies to the platform. Each <uri> node has a name attribute and a controller attribute. Name defines the top-level URI and controller defines the extension point that should handle processing all requests made to that URI.
• <class_loader> allows your plugin to provide classes to the rest of the platform. Each <file> node has a path attribute which specifies the path relative to your plugin.xml that contains the defined classes. You can define multiple <file> nodes in your plugin.xml. Each <file> also contains one or more <class> nodes which have a single name attribute. The name attribute is the exact name of the class to load.
• <event_points>
• <acl> contains a list of permissions your plugin should register with the permissions plugin. You can then use these permissions in your code. Each <priv> node has an id attribute and a label attribute. The value for theid attribute should be used in your code to test permissions, while the value for the label attribute should point to a namespaced ID from the translation system; you can also use literal text, but it is preferred to use the translation system instead.
• <extensions> is a list of all the your plugin provides. Each <extension> has a point attribute which specifies the ID your extension point binds to.
  • <id> must be unique across all Cerb4 plugins. This is a dot-delimited namespace string. The name is entirely up to you, but the namespace should follow the name of your plugin, and the ID itself should have a hierarchy. If your plugin is named xyzcompany.myplugin then your extension IDs should follow the convention xyzcompany.myplugin.point.name where point.name represents the extension point and a unique identifier for each particular extension.
  • <name> is a human-readable name for your extension. This can be anything you want. There are situations where you'll want to retrieve your extensions name and use it in functionality exposed to the user (e.g. in a dropdown list); and it's a great approach because the name can be quickly retrieved from the manifest (in memory) without running any plugin-level code.
  • <class> contains the definition for the file and class that hooks in to the extension point. Each <class> node contains one <file> node and one <name> node. The <file> node contains the path relative to your plugin.xml file. The <name> node contains the name of the class to load.
  • <params> allow the manifest to pass information to each implementation of an extension. Each <param> node has a key attribute, and a value attribute or a <value> node. Each <value> node contains a <data> node with a key and value attribute. These are static values that are not expected to change.