Profile picture for user admin
Daniel Sipos
10 Aug 2015

Today I would like to introduce a new module that I released for the Drupal (developer) community to use and share: Info Plugins. This is for developers who are tired of implementing a bunch of messy _info hooks (and their corresponding callbacks), lumping together functionality that frankly shouldn't even touch. I'm talking about those ugly switch statements in which we have cases for the various extensions we provide. Don't get me wrong Drupal, I love your hook system.

With Info Plugins, much (and progressively more and more) of this becomes cleaner by exposing all those extension points to the cTools plugin system. What I mean by this is that using this module you will be able to declare things like Drupal blocks, filters, field formatters and more, as cTools plugins. This way, all the logic related to one plugin (block, filter or field formatter to continue with the above examples) resides neatly within one single plugin include file.

Let us look at an example a bit more in depth: the Drupal block. Instead of implementing up to 4 hooks (_info, _view, _configure and _save) to manage your blocks, you can now define a new core_block plugin within your cTools plugins folder like so:

$plugin = array(
  'title' => t('Example block'),
  // Your own callback for building the display of the block (called by `hook_block_view()`)
  // Leaving this empty, the function name would default to `my_module_example_block_view()`
  'view' => 'my_module_render_example_block',
  // Your own callback for building the config form for the block (called by `hook_block_configure()`)
  // Leaving this empty, the function name would default to `my_module_example_block_configure()`
  'configure' => 'my_module_configure_example_block',
  // Your own callback for saving the config for the block (called by `hook_block_saved()`)
  // Leaving this empty, the function name would default to `my_module_example_block_save()`
  'save' => 'my_module_save_example_block',
  // ... all other options you may want to pass to `hook_block_info()`
);

/**
 * Returns a renderable array that represents the block content, i.e. 
 * the same as you would return from `hook_block_view()`.
 *
 * @param $delta
 *   The block delta
 */
function my_module_render_example_block($delta) {
  return array(
    '#type' => 'markup',
    '#markup' => 'My custom example block'
  );
}

/**
 * Returns a form to be used as the block configuration form, i.e. the same
 * as you would return from `hook_block_configure()`
 *
 * @param $delta
 *   The block delta
 */
function my_module_configure_example_block($delta) {
  $form = array();
  $form['my_custom_field'] = array(
    '#type' => 'textfield',
    '#title' => t('My custom block field'),
    '#default_value' => variable_get($delta, '')
  );

  return $form;
}

/**
 * Saves the block configuration, i.e. the same as you would do inside
 * `hook_block_save()`
 *
 * @param $block
 *   An array of values representing the block with it's configuration, i.e. the
 *   `$edit` array passed to `hook_block_save()`
 */
function my_module_save_example_block($block) {
  variable_set($block['delta'], $block['my_custom_field']);
}

So as you can see, your block definition, render and configuration resides in one file. If you need more blocks, you just define more plugins and you are good to go. There is such a documentation oriented example inside the plugin_examples folder of the module for each available plugin type. Plus, don't forget the README.md file.

Once you install the module, you will have only one administration screen at admin/config/info-plugins where you'll be able to select which plugin types you need. For example, if you need to define a custom block, enable the Core Block plugin type. If you need others, enable them as well. But I recommend you keep them disabled if you don't use them so that their logic doesn't get included in memory (all the relevant hooks and what not). My goal here is to keep a very low foot print.

To see which plugin types are available to use, please consult the project page. And keep checking back because I will add more. And if you want to contribute, please don't hesitate. Take it out for a spin, give it a test and please open issues to let me know of any bugs you find. I will be active on this for a while and want to hammer out all the potential problems before creating a stable release.

Cheers!

Profile picture for user admin

Daniel Sipos

CEO @ Web Omelette

Danny founded WEBOMELETTE in 2012 as a passion project, mostly writing about Drupal problems he faced day to day, as well as about new technologies and things that he thought other developers would find useful. Now he now manages a team of developers and designers, delivering quality products that make businesses successful.

Contact us

Add new comment