implement hook_features_pipe_alter() for node component so node type setting gets automatically exported [#2507527]

Strongarm module implements Features' hook_features_pipe_alter() for the node component, in order to ensure that when you export a node type to a feature, all of core's variables related to that node type get exported as strongarm variables. This includes variables such as node_options_$type, node_preview_$type, and so on.

Obviously, Strongarm doesn't cater for contrib-defined variables in the same pattern.

Workbench Moderation has a variable workbench_moderation_default_state_$type, which it would be useful to have automatically exported along with the node type. This can be done by implementing the hook.

(Tagging as novice, as this is pretty simple. Use strongarm_features_pipe_node_alter() as a template -- see http://api.drupal.psu.edu/api/drupal/modules!contrib!strongarm!strongarm... for the source, for example.)

Comment	File	Size	Author
#6	2507527.workbench_moderation.strongarm-features-support.patch	683 bytes	joachim
#6
#3	Screen Shot 2015-06-27 at 11.00.42 AM.png	70.76 KB	foxtrotcharlie

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

foxtrotcharlie CreditAttribution: foxtrotcharlie as a volunteer commented 25 June 2015 at 19:02

Assigned:

Unassigned

» foxtrotcharlie

If this looks right let me know and I'll create the patch:

/**
 * Implements hook_features_pipe_alter() for node component. Add workbench moderation node type variables.
 */
function workbench_moderation_features_pipe_node_alter(&$pipe, $data, $export) {
  if (!empty($data)) {
    $variables = array(
      'workbench_moderation_default_state',
    );
    foreach ($data as $node_type) {
      foreach ($variables as $variable_name) {
        $pipe['variable'][] = "{$variable_name}_{$node_type}";
      }
    }
  }
}

Should it go in at the end of workbench_moderation.module ?

Comment #2

joachim CreditAttribution: joachim commented 25 June 2015 at 19:44

One thing occurs to me now I see your code -- it should check that 'variable' is actually a valid Features type. This covers the case where Features is enabled, but Strongarm is not.

It's *possible* that Features knows to ignore component types it doesn't know about, but that's a wild guess -- it could equally crash ;)

Comment #3

foxtrotcharlie CreditAttribution: foxtrotcharlie as a volunteer commented 27 June 2015 at 09:42

Issue summary:

View changes

File	Size
Screen Shot 2015-06-27 at 11.00.42 AM.png	70.76 KB

Thanks for the feedback. I tested the code as listed above, and when I select the article content type, the workbench_moderation_default_state_article variable is selected by default, with strongarm is installed (see screenshot). When strongarm is not installed, there are no errors when selecting a content type, so perhaps it's not a problem.

I don't really know how to test that it's a 'valid features type'. I've dug through the code, and here are some possibilities: Because it's a variable I could check to see that the variable component is available using features_get_components(). Then calling features_invoke('variable', 'features_export_options') will give a list of available, features exportable variables, which I could check to see if it contains "workbench_moderation_default_state_{$node_type}". Not sure though if that's what you're meaning?

Comment #4

joachim CreditAttribution: joachim commented 27 June 2015 at 12:07

> When strongarm is not installed, there are no errors when selecting a content type, so perhaps it's not a problem.

That sounds like it's ok as it is :)

Comment #5

foxtrotcharlie CreditAttribution: foxtrotcharlie as a volunteer commented 29 June 2015 at 20:07

To create the patch I cloned the 7.x-2.x version of the module which had the state machine dependency (the initial one I was testing on didn't), and now I can't figure out how to set the default workbench moderation state for a content type, and my patch doesn't have any effect. I have enabled the default workflow. Am I missing some configuration setting?

Comment #6

joachim CreditAttribution: joachim commented 2 July 2015 at 13:04

Status:

Active

» Needs review

File	Size
2507527.workbench_moderation.strongarm-features-support.patch	683 bytes

I don't know about the 2.x branch at all.

Here's a patch based on your code that works on 1.x. I simplified it a bit, as there's only one variable so we don't need the foreach loop.

Comment #7

foxtrotcharlie CreditAttribution: foxtrotcharlie as a volunteer commented 6 July 2015 at 19:42

The version on the issue status got me looking at the wrong version ;-) I just tested your patch against the 7.x-1.x-dev version of workbench moderation: I enabled moderation for both the article and page content types, and set a default moderation state for each. I cleared the cache, and then created a new feature, selecting article and page content types. Both workbench_moderation_default_state_artice and workbench_moderation_default_state_page variables appear selected under the strongarm section of the feature components. So looks like it's working.