Implement node type -> strongarm pipe for Features

I'm having this problem too. Any updates on this one? I'm using the beta10

Comment settings are stored in the variable table. Try Strongarm.

Hmm, but isn't this rather complicated? Using Strongarm, I have to search for the fields/settings of a content type I want to "versionize" ... I just want "Features" to work as the "export" functionality. I select "a" content type, and Features takes care of all settings ... even the settings that are added using contrib modules

I think this should play into the patch I just provided (#870040: Provide hook to allow modules to define what variables they own) to add & build upon a new hook_default_variables() that would let modules define the variables they provided.

FYI some of this also goes back to the discussion on another ticket: #401948: Node settings change not triggering "overridden" flag

From the POV of getting Features to work with this, the node_features_export() function in features.node.inc would have to be expanded to call a Strongarm function to obtain a list of suitable variables for the given content type, rather than just using one from CCK (content_extra_weights_{$type}).

Adds node pipe for core variables. As described by @gordon here (http://drupal.org/node/728004#comment-2858488), contrib node type variables should be implemented in pipe alters their respective modules.

Whoops, actually attaching patch.

http://drupal.org/cvs?commit=402796

I repeat one of my previous replies:

<<
Hmm, but isn't this rather complicated? Using Strongarm, I have to search for the fields/settings of a content type I want to "versionize" ... I just want "Features" to work as the "export" functionality. I select "a" content type, and Features takes care of all settings ... even the settings that are added using contrib modules
>>

So, if I want to export the "Workflow settings", I have to install Strongarm and Ctools. So, to control my "Content Type", I have to use 3 contrib modules: Features, Strongarm AND CTools.
The "export" functionality does exactly what I want, but it's not easy to control it. I was hoping Features would solve this problem ...

from IRC :)

After drush fu MYFEATURE

WD php: Missing argument 4 for strongarm_features_pipe_node_alter() in                                                                               [error]
/MYPATH/sites/all/modules/contrib/strongarm/strongarm.module on line 194.
Created module: MYFEATURE in sites/all/modules/features/MYFEATURE                                                                          [ok]
Missing argument 4 for strongarm_features_pipe_node_alter() in                                                                                       [warning]
/MYPATH/sites/all/modules/contrib/strongarm/strongarm.module on line 194.

Same error for me - patch in #15 seems to resolve it.

Also confirming patch at #15 removes this error.

Also confirming the #15 patch is working.

Yep. Came here to file this patch, good to see scottrigby beat me to it.

#1221038: Extra argument in strongarm_features_pipe_ds_alter() contains the same patch, so I've updated the status and cross-post here so the eventual committer can kill two issues with one commit ;-)

This is a no-brainer. I'm happy to see it is properly closed. And I'm sad it is still present in version 2.0. Let's commit it.

Heh.

Nobody want to commit #15?

The implementation of the hook matches a previous version of the hook, one I'm trying to get back because removing the module name prevented me from doing some fun stuff. If instead of fixing it in strongarm, we restored to the hook to what it used to be, that would fix this error also. See my issue #939254: Return the $module_name to hook_features_pipe_component_alter() to restore the hook to what it used to be.

The reason it was changed is that d7 drupal_alter doesn't allow same more than a certain amount of arguments, so instead of changing the signature to how d7 alters can add more data, the information (module name) was removed from the hook and is now implausible to access in an implementation of the hook :(

Going to mark this needs work in hopes #939254 gets addressed and this isn't needed. This should have likely been it's own bug report instead of opening an old issue as now the trying to find the issue is really confusing :O!

If this issue runs against 6.x and issue #939254 against 7.x how is work on #939254 going to solve this problem exactly?

Once something is committed to one branch, it can be ported to another. Patches like that likely outta go in 7 first.

bookmarking this

The same bug.

Missing argument 4 for strongarm_features_pipe_node_alter() strongarm.module:194 [warning]

Any progress on that?

According to the 6.x-2.1 release notes, a fix for "missing argument 4" made it into 6.x-2.1.