diff --git a/delegator/delegator.admin.inc b/delegator/delegator.admin.inc
index 4e0b4e4d24c197a226059c2e5dc193cb700d0330..285d9c59cead584234a62767f39cbb2e972d0152 100644
--- a/delegator/delegator.admin.inc
+++ b/delegator/delegator.admin.inc
@@ -295,6 +295,7 @@ function delegator_administer_task($task_name) {
'task_handlers' => $task_handlers,
'cache' => delegator_admin_get_task_cache($task, $subtask_id, $task_handlers),
);
+
ctools_include('form');
return ctools_build_form('delegator_admin_list_form', $form_state);
}
diff --git a/help/about.html b/help/about.html
new file mode 100644
index 0000000000000000000000000000000000000000..a3c12c675ba8f57cc5dcbb376c0aa56c3d43374e
--- /dev/null
+++ b/help/about.html
@@ -0,0 +1,31 @@
+<!-- $Id$ -->
+The Chaos Tool Suite is a series of tools for developers to make code that I've found to be very useful to Views and Panels more readily available. Certain methods of doing things, particularly with AJAX, exportable objects, and a plugin system are proving to be ideas that are useful outside of just Views and Panels. This module does not offer much directly ot the end user, but instead creates a library for other modules to use. If you are an end user and some module asked you to install the CTools suite, then this is far as you really need to go. If you're a developer and are interested in these tools, read on!
+
+<h3>Tools provided by CTools</h3>
+<dl>
+<dt><a href="&topic:ctools/plugins&">Plugins</a></dt>
+<dd>The plugins tool allows a module to allow <b>other</b> modules (and themes!) to provide plugins which provide some kind of functionality or some kind of task. For example, in Panels there are several types of plugins: Content types (which are like blocks), layouts (which are page layouts) and styles (which can be used to style a panel). Each plugin is represented by a .inc file, and the functionaly they offer can differ wildly.
+
+<dt><a href="&topic:ctools/context&">Context</a></dt>
+<dd>Context is the idea that the objects that are used in page generation have more value than simply creating a single piece of output. Instead, contexts can be used to create multiple pieces of content that can all be put onto the page. Additionally, contexts can be used to derive other contexts via relationships, such as determining the node author and displaying data about the new context.</dd>
+
+<dt><a href="&topic:ctools/ajax&">AJAX Tools</a></dt>
+<dd>AJAX (also known as AHAH) is a method of allowing the browser and the server to communicate without requiring a page refresh. It can be used to create complicated interactive forms, but it is somewhat difficult to integrate into Drupal's Form API. These tools make it easier to accomplish this goal. In addition, CTools provides a few other javascript helpers, such as a modal dialog, a collapsible div, a simple dropdown and dependent checkboxes.
+
+<dt><a href="&topic:ctools/css&">CSS scrubbing and caching</a></dt>
+<dd>Drupal comes with a fantastic array of tools to ensure HTML is safe to output, but does not contain any similar tools for CSS. CTools provides a small tool to sanitize CSS so that user-input CSS code can still be safely used. It also provides a method for caching CSS for better performance.</dd>
+
+<dt><a href="&topic:ctools/export&">Exportable objects</a></dt>
+<dd>Views and Panels both use objects that can either be in code or in the database, and the object can be exported into a piece of PHP code so that it can be moved from site to site or out of the database entirely. This library abstracts that so that other modules can use this same concept for their data.</dd>
+
+<dt><a href="&topic:ctools/form&">Form tools</a></dt>
+<dd>Drupal 6's FAPI really improved over Drupal 5, and made a lot of things possible. Still, it missed a few items that were needed to make form wizards and truly dynamic AJAX forms possible. CTools includes a replacement for drupal_get_form() that has a few more options and allows the caller to examine the $form_state once the form has completed.</dd>
+
+<dt><a href="&topic:ctools/wizard&">Form wizards</a></dt>
+<dd>Finally! An easy way to have form wizards, which is any 'form' which is actually a string of forms that build up to a final conclusion. The form wizard supports a single entry point, the ability to choose whether or not the user can go forward/back/up on the form and easy callbacks to handle the difficult job of dealing with data in between forms.</dd>
+
+<dt><a href="&topic:ctools/object-cache&">Temporary object cache</a></dt>
+<dd>For normal forms, all of the data needed for an object is stored in the form so that the browser handles a lot of the work. For multi-step and ajax forms, however, this is impractical, and letting the browser store data can be insecure. The object cache provides a non-volatile location to store temporary data while the form is being worked on. This is much safer than the standard Drupal caching mechanism, which is volatile, meaning it can be cleared at any time and any system using it must be capable of recreating the data that was there. This system also allows for object locking, since any object which has an item in the cache from another person can be assumed to be 'locked for editing'.</dd>
+
+
+</dl>
\ No newline at end of file
diff --git a/help/delegator.help.ini b/help/ajax.html
similarity index 100%
rename from help/delegator.help.ini
rename to help/ajax.html
diff --git a/help/ctools.help.ini b/help/ctools.help.ini
new file mode 100644
index 0000000000000000000000000000000000000000..c0c13ddbfaf99da203a18db17b9e6b1ac326c7e7
--- /dev/null
+++ b/help/ctools.help.ini
@@ -0,0 +1,81 @@
+; $Id$
+[advanced help settings]
+line break = TRUE
+
+[about]
+title = About Chaos Tool Suite
+weight = -100
+
+[context]
+title = Context tool
+weight = -40
+
+[context-access]
+title = Context based access control plugins
+parent = context
+
+[context-context]
+title = Context plugins
+parent = context
+
+[context-arguments]
+title = Argument plugins
+parent = context
+
+[context-relationships]
+title = Relationship plugins
+parent = context
+
+[css]
+title = CSS scrubbing and caching tool
+
+[menu]
+title = Miscellaneous menu helper tool
+
+[plugins]
+title = Plugins and APIs tool
+weight = -50
+
+; [plugins-api]
+; title = Implementing APIs
+; parent = plugins
+
+[plugins-creating]
+title = Creating plugins
+parent = plugins
+
+[plugins-implementing]
+title = Implementing plugins
+parent = plugins
+
+[export]
+title = Exportable objects tool
+
+[form]
+title = Form tools
+
+[wizard]
+title = Form wizard tool
+
+[ajax]
+title = AJAX and Javascript helper tools
+weight = -30
+
+[modal]
+title = Javascript modal tool
+parent = ajax
+
+[collapsible-div]
+title = Javascript collapsible DIV
+parent = ajax
+
+[dropdown]
+title = Javascript dropdown
+parent = ajax
+
+[dependent]
+title = Dependent checkboxes and radio buttons
+parent = ajax
+
+[object-cache]
+title = Temporary object caching
diff --git a/help/form.html b/help/form.html
new file mode 100644
index 0000000000000000000000000000000000000000..590de5c9c1fc26453e8179c53a2766af9944662e
--- /dev/null
+++ b/help/form.html
@@ -0,0 +1,36 @@
+<!-- $Id$ -->
+CTools' form tool is a replacement for drupal_get_form() that includes some additional functionality:
+<ul>
+<li> It takes $form_state as an argument, which is accepted as a reference; meaning when the form is complete, you can examine the $form_state to see what the form did.</li>
+<li> It can handle $_GET as an input source, or the input can be provided from some other source.</li>
+<li> It can be told not to render or not to redirect, which can be important during AJAX operations.</li>
+<li> It can provide a special 'wrapper' form which is used by the wizard tool to provide a standard set of buttons to a form.</li>
+</ul>
+
+Usage:
+
+<pre>
+ctools_include('form');
+$output = ctools_build_form($form_id, $form_state);
+</pre>
+
+Previously, arguments to the form builder were passed into drupal_get_form; this is no longer true. You have two options for passing arguments to the form with ctools_build_form: set $form_state['args'] to an array which will then be passed to the builder as before. Or simply set $form_state values and refer to them in the builder.
+
+<h3>Values you can set on $form_state</h3>
+
+<dl>
+<dt>no_redirect</dt>
+<dd>If set to TRUE, completely disables redirecting, no matter what $form_state['redirect'] has been set to.</dd>
+<dt>rerender</dt>
+<dd>Defaults to TRUE. If set, the form will be rerendered after submit if not redirected. If set to FALSE the form will not be rerendered after submit and $output will be NULL.</dd>
+<dt>method</dt>
+<dd>Defaults to 'post'. May be set to 'get'. If 'get' is in use, form ids and tokens will not be used, and all get forms will automatically be assumed to be submitted. Beware as this can have unexpected effects on default values as fapi doesn't quite know how to handle this state.</dd>
+<dt>input</dt>
+<dd>Defaults to $_POST. If using 'get' you should set this to $_GET.</dd>
+<dt>wrapper callback</dt>
+<dd>If this is set to a function name, the form will be 'wrapped' in another form. This changes how the builder callback work! First, $form is set to a blank array. Then the wrapper callback is called with &$form and &$form_state as arguments. Then the form builder is called with &$form and &$form_state as arguments. No other arguments are given.</dd>
+<dt>args</dt>
+<dd>An array of arguments that will be passed to the form builder callback just as though they were passed as arguments to drupal_get_form().</dd>
+<dt>want form</dt>
+<dd>Defaults to FALSE. If set, instead of rendering, the return value will be the $form array. It can then be rendered via drupal_render() normally. This is particularly useful for AJAX operations that may need to process a form and then only render a part of it.</dd>
+</dl>
\ No newline at end of file
diff --git a/help/plugins-api.html b/help/plugins-api.html
index 24a69e80b1c0a02b9be69b1d9da587b662cc72d6..5f0fb91704c97e65e4bccdbc6c0a331c635a7299 100644
--- a/help/plugins-api.html
+++ b/help/plugins-api.html
@@ -1,5 +1,4 @@
<!-- $Id$ -->
-
APIs are a form of plugins that are tightly associated with a module. Instead of a module providing any number of plugins, each module provides only one file for an API and this file can contain hooks that the module should invoke.
Modules support this API by implementing hook_ctools_plugin_api($module, $api). If they support the API, they return a packet of data:
diff --git a/help/plugins-creating.html b/help/plugins-creating.html
index 9baa729c9d6bbf82691c270dac71a301f49cefc8..f4b94880af5ed23e9f642f9f0187a0e8712e5de6 100644
--- a/help/plugins-creating.html
+++ b/help/plugins-creating.html
@@ -1,51 +1,167 @@
<!-- $Id$ -->
-Documentation about the Chaos Tools plugin system:
+There are two primary pieces to using plugins. The first is getting the data, and the second is using the data.
-Currently some scribbled notes to provide a framework for fleshing this out.
+<h3>Getting the data</h3>
+To create a plugin, a module only has to execute ctools_get_plugins with the write data:
+<pre>
ctools_include('plugins');
+ ctools_get_plugins($module, $type, [$id])
+</pre>
- hook_ctools_plugin_plugintype
-
- 'defaults'
- 'cache'
+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 'content_types' plugin:
- ctools_get_plugins($module, $type, [$id])
- best practice: provide a wrapper to make it easier. ex: panels_get_content_type() and panels_get_content_types()
-
-Plugins are primarily just an array of data that describes the plugin. This can be used
-to provide printable data as well as function callbacks. Never make assumptions about
-hook names.
-
-Document your plugins!
- 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.
-
-Automatically filled in data:
- name
- module
- path
- file
-
-Use of hook_ctools_plugin_TYPE to define info about your plugin.
- $info += array(
- 'module' => $module,
- 'type' => $type,
- 'cache' => FALSE,
- 'defaults' => array(),
- 'hook' => $module . '_' . $type,
- 'load themes' => FALSE,
+<pre>
+/**
+ * Fetch metadata on a specific content_type plugin.
+ *
+ * @param $content type
+ * Name of a panel content type.
+ *
+ * @return
+ * An array with information about the requested panel content type.
+ */
+function panels_get_content_type($content_type) {
+ ctools_include('context');
+ ctools_include('plugins');
+ return ctools_get_plugins('panels', 'content_types', $content_type);
+}
+
+/**
+ * Fetch metadata for all content_type plugins.
+ *
+ * @return
+ * An array of arrays with information about all available panel content types.
+ */
+function panels_get_content_types() {
+ ctools_include('context');
+ ctools_include('plugins');
+ return ctools_get_plugins('panels', 'content_types');
+}
+</pre>
+
+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 hook_ctools_plugin_TYPE (where TYPE is the same $type sent to ctools_get_plugins). This isn't a true hook, it will only be called for the $module that was given. This hook returns an array:
+
+<pre>
+/**
+ * Inform CTools that the layout plugin can be loaded from themes.
+ */
+function panels_ctools_plugin_layouts() {
+ return array(
+ 'load themes' => TRUE,
);
+}
+</pre>
+
+The following information can be specified:
+<dl>
+<dt>cache</dt>
+<dd>If set to TRUE, the results of ctools_get_plugins will be cached in the 'cache' table, thus preventing .inc files from being loaded. ctools_get_plugins looking for a specific plugin will always load the appropriate .inc file.</dd>
+<dt>defaults</dt>
+<dd>An array of defaults that should be applied 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.</dd>
+<dt>load themes</dt>
+<dd>If set to TRUE, then plugins 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 $custom_theme 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.</dd>
+<dt>hook</dt>
+<dd>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.
+<dt>process</dt>
+<dd>An optional function callback to use for processing a plugin. This can be used to provide automated settings that require code. The parameters on this callback are: <strong>callback(&$plugin, $info)</strong> where $plugin is a reference to the plugin as processed and $info is the fully processed result of hook_ctools_plugin_api_info().
+</dl>
+
+In addition, there is a 'module', 'type' and 'hook' settings; these are for internal use of the plugin system and you should not change these.
+
+<h3>Using the data</h3>
+
+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:
+<dl>
+<dt>name</dt>
+<dd>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.</dd>
+<dt>module</dt>
+<dd>The module that supplied the plugin.</dd>
+<dt>file</dt>
+<dd>The actual file containing the plugin.</dd>
+<dt>path</dt>
+<dd>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.</dd>
+</dl>
-if 'load themes' is true, all enabled themes will be polled for the plugin as well. This will NOT force loading the template.php and *every* enabled theme will get their plugins regardless of which theme is currently active.
+Any of the above items can be overridden by the plugin itself, though the most likely one to be modified is the 'path'.
-General feature for callbacks:
- either 'function_name' or
- array(
+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 ctools_plugin_get_function, which requires the full $plugin object.
+
+<pre>
+/**
+ * Get a function from a plugin, if it exists. If the plugin is not already
+ * loaded, try ctools_plugin_load_function() instead.
+ *
+ * @param $plugin
+ * The loaded plugin type.
+ * @param $callback_name
+ * 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 ctools_plugin_get_function($plugin, $callback_name)
+</pre>
+
+The second does not require the full $plugin object, and will load it:
+<pre>
+/**
+ * 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 $callback_name
+ * 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 ctools_plugin_load_function($module, $type, $id, $callback_name) {
+</pre>
+
+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:
+
+<pre>
+ 'callback_name' => 'actual_name_of_function_here',
+</pre>
+
+Or like this:
+<pre>
+ 'callback_name' => array(
'file' => 'filename',
- 'path' => 'filepath', // optional
- 'function' => 'function_name'
+ 'path' => 'filepath', // optional, will use plugin path if absent
+ 'function' => 'actual_name_of_function_here',
),
+</pre>
+
+An example, for 'plugin_example' type
+
+<pre>
+$plugin = array(
+ 'name' => 'my_plugin',
+ 'module' => 'my_module',
+ 'example_callback' => array(
+ 'file' => 'my_plugin.extrafile.inc',
+ 'function' => 'my_module_my_plugin_example_callback',
+ ),
+);
+</pre>
+
+To utilize this callback on this plugin:
+
+<pre>
+if ($function = ctools_plugin_get_function($plugin, 'example_callback')) {
+ $function($arg1, $arg2, $etc);
+}
+</pre>
- Using ctools_plugin_get_function() or ctools_plugin_load_function() will take advantage.
+<h3>Document your plugins!</h3>
+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.
diff --git a/help/plugins-implementing.html b/help/plugins-implementing.html
index 5ced6e5a05cca74bdd576e0d42f3b8f4f6e0aea0..3088f9356f0d7376a79f4ff671e6f5922963e327 100644
--- a/help/plugins-implementing.html
+++ b/help/plugins-implementing.html
@@ -1,14 +1,73 @@
<!-- $Id$ -->
+To implement plugins, you need to implement a single hook in your module to tell the system where your plugins live, and then you need to implement one or more .inc files that contain the plugin data.
-Implementing hook_ctools_plugin_directory($module, $plugin)
+<h3>Telling it where your plugins live</h3>
+To implement any plugins at all, you must implement a single function for all plugins: <strong>hook_ctools_plugin_directory</strong>. Every time a module loads plugins, this hook will be called to see which modules implement those plugins and in what directory those plugins will live.
-Creating a pluginname.inc file
+<pre>
+function hook_ctools_plugin_directory($module, $plugin) {
+ if ($module == 'panels' && $plugin == 'content_types') {
+ return 'plugins/content_types';
+ }
+}
+</pre>
-Naming the function properly within this file:
+The directory returned should be relative to your module. Another common usage is to simply return that you implement all plugins owned by a given module (or modules):
-returning 1 or more plugins per file:
+<pre>
+function hook_ctools_plugin_directory($module, $plugin) {
+ if ($module == 'panels') {
+ return 'plugins/' . $plugin;
+ }
+}
+</pre>
-Best practices
- if a plugin will have many files, use subdirectories. This is OK.
+Typically, it is recommended that all plugins be placed into the 'plugins' directory for clarity and maintainability. Inside the directory, any number of subdirectories can be used. For plugins that require extra files, such as templates, css, javascript or image files, this is highly recommended:
+<pre>
+mymodule.module
+mymodule.info
+plugins/
+ content_types/
+ my_content_type.inc
+ layouts/
+ my_layout.inc
+ my_laout.css
+ my_layout.tpl.php
+ my_layout_image.png
+</pre>
+<h3>How a theme can implement plugins</h3>
+Themes can implement plugins if the plugin owner specified that it's possible in its hook_ctools_api_TYPE() call. If so, it is generally exactly the same as modules, except for one important difference: themes don't get hook_ctools_plugin_directory(). Instead, themes add a line to their info file:
+<pre>
+plugins[module][type] = directory
+</pre>
+
+<h3>How to structure the .inc file</h3>
+
+The actual plugin .inc file must be named carefully; the name of the file will conform to the name of the plugin. This name must be unique, so you should try to include your module name at the beginning to make sure you don't bump into other modules trying to create a plugin with the same name.
+
+This file must contain a specially named function:
+
+<pre>
+function YOURMODULE_PLUGINNAME_OWNERMODULE_PLUGINTYPE()
+</pre>
+
+So for example, for module 'example' to implement a 'layout' named 'mine' for the 'panels' module:
+<pre>
+ function example_mine_panels_layouts() {
+
+ }
+</pre>
+
+Finally, your plugin should return an array of data, like this:
+
+<pre>
+function YOURMODULE_PLUGINNAME_OWNERMODULE_PLUGINTYPE() {
+ return array(
+ 'key' => 'value',
+ );
+}
+</pre>
+
+Several values will be filled in for you automatically, but you can override them if necessary. They include 'name', 'path', 'file' and 'module'. Additionally, the plugin can owner can provide other defaults as well.
diff --git a/help/plugins.html b/help/plugins.html
new file mode 100644
index 0000000000000000000000000000000000000000..a85ec3468eb3f6a98d0e3c5c0a6cb9aa8c118305
--- /dev/null
+++ b/help/plugins.html
@@ -0,0 +1,6 @@
+<!-- $Id$ -->
+The plugins tool allows a module to allow <b>other</b> modules (and themes!) to provide plugins which provide some kind of functionality or some kind of task. For example, in Panels there are several types of plugins: Content types (which are like blocks), layouts (which are page layouts) and styles (which can be used to style a panel). Each plugin is represented by a .inc file, and the functionaly they offer can differ wildly.
+
+A module which uses plugins can implement a hook describing the plugin (which is not necessary, as defaults will be filled in) and then calls a ctools function which loads either all the known plugins (used for listing/choosing) or loads a specific plugin (used when its known which plugin is needed). From the perspective of the plugin system, a plugin is a packet of data, usually some printable info and a list of callbacks. It is up to the module implementing plugins to determine what that info means and what the callbacks do.
+
+A module which implements plugins must first implement the <strong>hook_ctools_plugin_directory</strong> function, which simply tells the system which plugins are supported and what directory to look in. Each plugin will then be in a .inc file in the directory supplied. The .inc file will contain a specially named hook which returns the data necessary to implement the plugin.
\ No newline at end of file
diff --git a/includes/plugins.inc b/includes/plugins.inc
index 2ddaf1aac06cff870d4acf86c72fb81dd47feda7..2ca1ba835c667048314d62093d005e5aca9ea0b2 100644
--- a/includes/plugins.inc
+++ b/includes/plugins.inc
@@ -185,7 +185,7 @@ function ctools_plugin_load_includes($info, $file = NULL) {
// For example, 'foo.inc' in the module 'mogul' using the plugin
// whose hook is named 'borg_type' should have a function named (deep breath)
// mogul_foo_borg_type()
- $result = ctools_plugin_process($info, $module, $module . '_' . $file->name, dirname($file->filename), basename($file->filename));
+ $result = ctools_plugin_process($info, $module, $module . '_' . $file->name, dirname($file->filename), basename($file->filename), $file->name);
if (is_array($result)) {
$plugins = array_merge($plugins, $result);
}
@@ -265,8 +265,13 @@ function ctools_plugin_load_hooks($info) {
* The path where files utilized by this plugin will be found.
* @param $file
* The file that was loaded for this plugin, if it exists.
+ * @param $base
+ * The base plugin name to use. If a file was loaded for the plugin, this
+ * is the plugin to assume must be present. This is used to automatically
+ * translate the array to make the syntax more friendly to plugin
+ * implementors.
*/
-function ctools_plugin_process($info, $module, $identifier, $path, $file = NULL) {
+function ctools_plugin_process($info, $module, $identifier, $path, $file = NULL, $base = NULL) {
$function = $identifier . '_' . $info['hook'];
if (!function_exists($function)) {
return NULL;
@@ -276,6 +281,13 @@ function ctools_plugin_process($info, $module, $identifier, $path, $file = NULL)
return NULL;
}
+ // Automatically convert to the proper format that lets plugin implementations
+ // not nest arrays as deeply as they used to, but still support the older
+ // format where they do:
+ if ($base && (!isset($result[$base]) || !is_array($result[$base]))) {
+ $result = array($base => $result);
+ }
+
// Fill in defaults.
foreach ($result as $name => $plugin) {
$result[$name] += array(
@@ -289,6 +301,11 @@ function ctools_plugin_process($info, $module, $identifier, $path, $file = NULL)
if (!empty($info['defaults'])) {
$result[$name] += $info['defaults'];
}
+
+ // Allow the plugin owner to do additional processing.
+ if (!empty($info['process']) && function_exists($info['process'])) {
+ $info['process']($result[$name], $info);
+ }
}
return $result;
}