Document pattern for creating Commons-compatible group content type features

There are several patterns that modules exposing a content type to Drupal Commons 3.x should expect to do.

I've been experimenting with Commons_Posts in a sandbox to get a sense of what these are. Checkout the latest status of the codebase at
http://drupalcode.org/sandbox/ezrag/1721532.git/tree/refs/heads/7.x-3.x

Here's an initial list:

- Add your content type to the Commons browsing widget:

Group home pages include a combination browsing/content creation widget.

Content types (Except for Events) should add themselves to this browsing widget. Notwithstanding #1782656: Panels exports don't revert, group home pages are panelized and include the browsing widget, which is powered by http://drupal.org/project/commons_bw.

Modules can add a tab to the widget by implementing hook_commons_bw() and returning an array of QuickTabs module formatted tabs.

This allows each content type to have its own unique view/presentation for how it should be displayed within its tab on the group homepage.

For example, Commons posts defines a simple view, and adds it as a tab on the group homepage like so:

/**
* Implements hook_commons_bw_group_widget().
*/
function commons_posts_commons_bw_group_widget() {
  return array(
    'commons_posts' => array(
      'title' => 'Posts',
      'type' => 'view',
      'vid' => 'commons_bw_posts',
      'display' => 'page_1',
      'weight' => 5,
    ),
  );
}

It exports the commons_bw_posts view (which would probably be better namespaced as commons_posts_group_bw).

We also implement hook_views_pre_render() to add the "Create a post" link to the tab for users who have access to do so:

/**
* Implements hook_views_pre_render().
*/
function commons_posts_views_pre_render(&$view) {
  if ($view->name == 'commons_bw_posts' && user_access('Post: Create new content')) {
    $group_id = $view->args[0];
    $view->attachment_before = l('Create a post', 'node/add/post', array('query' => array('og_group_ref' => $group_id)));
  }  
 }

We implement hook_strongarm_alter() in 2 places to integrate Commons content types with other Commons subsystems: Radioactivity, Liking and Groups:

Expose your content type to Commons Radioactivity

We alter the rate_widgets variable so that it is configured to include our content type and comments on that content type. For example:

/**
* Implements hook_strongarm_alter().
*/
 function commons_posts_strongarm_alter(&$items) {
  // Expose the Post content type for 'liking' via the Commons_like module
  // by altering the configuration for the Rate.module widget that it provides.
  if (!empty($items['rate_widgets']->value)) {
    foreach($items['rate_widgets']->value as $key => $widget) {
      if ($widget->name == 'commons_like') {
        if (!in_array('post', $items['rate_widgets']->value[$key]->node_types)) {
          $items['rate_widgets']->value[$key]->node_types[] = 'post';  
        }       
        if (!in_array('post', $items['rate_widgets']->value[$key]->comment_types)) {
          $items['rate_widgets']->value[$key]->comment_types[] = 'post';  
        }
      }
    }
  }

Expose your content type to "Liking" via Commons Like and as group content via Commons Groups

We expose our content type to Commons_radioactivity by overriding the commons_radioactivity_entity types variable. Currently, we also expose content types to Commons_groups in another variable with the same format, so we can do (in the same function):

  // Expose the post content type for integration with Commons Radioactivity
  // and Commons Groups.  
  foreach (array('commons_radioactivity_entity_types', 'commons_groups_entity_types') as $key) {
    if (isset($items[$key])) {  
      $items[$key]->value['node']['post'] = 1;
    }
  }

Note: You may need to revert features after enabling a module that alters a strong-arm value that has been stored to the database. We should consider automatically reverting these components or prompting the user to do so. The intended benefit of using Strongarm vs a simple hook to expose our content types is that it makes it easier to expose the variable to configuration through the UI in the future.

Commons Radioactivity and Commons Groups each looks for its respective variable and add its respective field instance onto the content type that requests it.

As a developer of a module that integrates with Commons that's all you need to know ;). However, if you're interested in seeing how this works in practice, for example, see Commons Radioactivity:

/**
* Implements hook_system_info_alter().
*/
function commons_radioactivity_system_info_alter(&$info, $file, $type) {
  // Commons Radioactivity dynamically adds field_radioactivity to
  // content types that implement commons_radioactivity_field.
  // We must add a corresponding line for each field instance
  // to commons_radioactivity.info so that Features is aware of the instance
  // and can sucessfully revert the field_instance component back
  // to its default state.
  if ($file->name == 'commons_radioactivity') {
    $commons_radioactivity_entity_types = variable_get('commons_radioactivity_entity_types', array());
    if (!empty($commons_radioactivity_entity_types['node'])) {
      foreach ($commons_radioactivity_entity_types['node'] as $type => $status) {
        if ($status) {
          $info['features']['field_instance'][] = "node-$type-field_radioactivity";
        }
      }
    }
  }
}

/**
 * Implements hook_field_default_field_instances().
 */
function commons_radioactivity_field_default_field_instances() {
  // Get a list of content types that should have the Radioactivity field added.
  // Modules can alter this list by implementing hook_strongarm_alter().
  $commons_radioactivity_entity_types = variable_get('commons_radioactivity_entity_types', array());
  if (!empty($commons_radioactivity_entity_types['node'])) {
    $field_instances = array();
    foreach($commons_radioactivity_entity_types['node'] as $type => $status) {
      if ($status) {
        commons_radioactivity_field_definition($field_instances, $type);  
      }
    }
    return $field_instances;  
  }
  
}

Panelized content type landing page as a submodule

It would be ideal for each content type to be panelized, to support customization to the page layout through the UI via Panelizer. To make it easier for site administrators to replace the default Commons panelized pages with their own configuration, each module that defines a content type should ideally export any landing pages or panelized content type pages into its own separate feature as a submodule in the main feature's Drupal.org.project.

As an alternative, we could include the default configuration as part of the main content type feature but encourage folks who define alternative Panels pages to alter the Commons default ones and make them disabled.