 creating plugins there are two primary pieces to using plugins the first is getting the data and the second is using the data getting the data to create a plugin a module only has to execute ctoolsgetplugins with the right data ctoolsinclude plugins ctoolsgetplugins module type id in the above example module should be your module s name and type is the type of the plugin it is typically best practice to provide some kind of wrapper function to make this easier for example panels provides the following functions to implement the contenttypes plugin fetch metadata on a specific contenttype plugin param content type name of a panel content type return an array with information about the requested panel content type function panelsgetcontenttype contenttype ctoolsinclude context ctoolsinclude plugins return ctoolsgetplugins panels contenttypes contenttype fetch metadata for all contenttype plugins return an array of arrays with information about all available panel content types function panelsgetcontenttypes ctoolsinclude context ctoolsinclude plugins return ctoolsgetplugins panels contenttypes as a plugin creator your module can also implement a hook to give more information about this plugin and to enable a few features that are not normally enabled if you need any of these features simply implement hookctoolsplugintype where type is the same type sent to ctoolsgetplugins this isn t a true hook it will only be called for the module that was given this hook returns an array inform ctools that the layout plugin can be loaded from themes function panelsctoolspluginlayouts return array load themes true the following information can be specified cache defaults to  false if set to true the results of ctoolsgetplugins will be cached in the cache table by default thus preventing inc files from being loaded ctoolsgetplugins looking for a specific plugin will always load the appropriate inc file cache table defaults to   cache  if cache is true then this value specifies the cache table where the cached plugin information will be stored defaults defaults to  array  an array of defaults that should be added to each plugin this can be used to ensure that every plugin has the basic data necessary these defaults will not ovewrite data supplied by the plugin this could also be a function name in which case the callback will be used to provide defaults note however that the callbackbased approach is deprecated as it is redundant with the process callback and as such will be removed in later versions consequently you should only use the array form for maximum crossversion compatibility load themes defaults to  false if set to true then plugins of this type can be supplied by themes as well as modules if this is the case all themes that are currently enabled will provide a plugin note due to a slight ui bug in drupal it is possible for the default theme to be active but not enabled if this is the case that theme will not provide plugins so if you are using this feature be sure to document that issue also themes set via customtheme do not necessarily need to be enabled but the system has no way of knowing what those themes are so the enabled flag is the only true method of identifying which themes can provide layouts hook defaults to   dynamic value the name of the hook used to collect data for this plugin normally this is  module type  but this can be changed here if you change this you must be sure to document this for your plugin implementors as it will change the format of the specially named hook process defaults to    an optional function callback to use for processing a plugin this can be used to provide automated settings that must be calculated perplugin instance ie it is not enough to simply append an array via defaults the parameters on this callback are  callback plugin info  where plugin is a reference to the plugin as processed and info is the fully processed result of hookctoolspluginapiinfo extension defaults to   inc  can be used to change the extension on files containing plugins of this type by default the extension will be inc though it will default to info if info files is set to true do not include the dot in the extension if changing it that will be added automatically info file defaults to  false if set to true then the plugin will look for a info file instead of a inc internally this will look exactly the same though obviously a info file cannot contain functions this can be good for styles that may not need to contain code use hooks defaults to  true  use to enable support for plugin definition hooks instead of plugin definition files note using a central plugin definition hook is less optimal for the plugins system and as such this will default to false in later versions child plugins defaults to  false if set to true the plugin type can automatically have child plugins meaning each plugin can actually provide multiple plugins this is mostly used for plugins that store some of their information in the database such as views blocks or exportable custom versions of plugins to implement each plugin can have a get child and get children callback both of these should be implemented for performance reasons since it is best to avoid getting all children if necessary but if get child is not implemented it will fall back to get children if it has to child plugins should be named parent child with the being the separator so that it knows which parent plugin to ask for teh child the get children method should at least return the parent plugin as part of the list unless it wants the parent plugin itself to not be a choosable option which is not unheard of get children arguments are plugin parent and get child arguments are plugin parent child in addition there is a module and type settings these are for internal use of the plugin system and you should not change these using the data each plugin returns a packet of data which is added to with a few defaults each plugin is guaranteed to always have the following data name the name of the plugin this is also the key in the array of the full list of plugins and is placed here since that is not always available module the module that supplied the plugin file the actual file containing the plugin path the path to the file containing the plugin this is useful for using secondary files such as templates css files images etc that may come with a plugin any of the above items can be overridden by the plugin itself though the most likely one to be modified is the path the most likely data beyond simple printable data for a plugin to provide is a callback the plugin system provides a pair of functions to make it easy and consistent for these callbacks to be used the first is ctoolsplugingetfunction which requires the full plugin object get a function from a plugin if it exists if the plugin is not already loaded try ctoolspluginloadfunction instead param plugin the loaded plugin type param callbackname the identifier of the function for example settings form return the actual name of the function to call or null if the function does not exist function ctoolsplugingetfunction plugin callbackname the second does not require the full plugin object and will load it load a plugin and get a function name from it returning success only if the function exists param module the module that owns the plugin type param type the type of plugin param id the id of the specific plugin to load param callbackname the identifier of the function for example settings form return the actual name of the function to call or null if the function does not exist function ctoolspluginloadfunction module type id callbackname both of these functions will ensure any needed files are included in fact it allows each callback to specify alternative include files the plugin implementation could include code like this callbackname actualnameoffunctionhere or like this callbackname array file filename path filepath optional will use plugin path if absent function actualnameoffunctionhere an example for pluginexample type plugin array name myplugin module mymodule examplecallback array file mypluginextrafileinc function mymodulemypluginexamplecallback to utilize this callback on this plugin if function ctoolsplugingetfunction plugin examplecallback function arg1 arg2 etc  document your plugins  since the data provided by your plugin tends to be specific to your plugin type you really need to document what the data returned in the hook in the inc file will be or nobody will figure it out use advanced help and document it there if every system that utilizes plugins does this then plugin implementors will quickly learn to expect the documentation to be in the advanced help  