Add documentation about exporting content types + using strongarm

I'm seeing the same issue.

Looks like it behaves the same way in D6.

Subscribing

It looks like these settings are stored in variables in the "variable" table. So you can export them with Strongarm. I believe exporting these variables would do it:

• node_preview_[content type name] -- preview setting
• node_options_[content type name] -- I think this controls the promoted/published default statuses and whether or not to display author information
• comment_[content type name] -- whether or not comments are enabled
• comment_preview_[content type name] -- comment preview setting

If someone else can confirm, then we can probably close this issue.

Correction: I believe node_submitted_[content type name] controls whether or not author information is displayed.

Features should automatically include these variables if Strongarm is enabled when exporting a content type, or at least this is how it works in D6 Features.

Features should automatically include these settings independently of Strongarm. If it uses Strongarm, it should have Strongarm as a dependency so I am forced to install it. Otherwise I find out the hard way that my settings were not saved. It's not the best experience to have new nodes show up automatically on the front page of a production site, when the original content-type says not to promote them to the front page. (features-6.x-1.0).

Subscribing

is fixed by strongarm in the meantime ( current versrion ), it is using a pipe to auto-include those settings for an content-type.

Beside that, it would be rather easy to add this here, but i cant see any sense in providing patches in this queue, as it seems rather stuck

Features is a magical system for generating a Drupal module that a developer could also produce by sitting down and typing out a mind-numbing load of code.

Whenever creating a new feature, or updating an existing one, at least take a look in the .info file to make sure every element you expect to be there actual shows up. Features is not infallible, and it's always good to know what code you are tossing around.

If you create a Feature without the correct (stable, 2.0) version of Strongarm, you will lose key settings. Of course, the definition of key settings can vary based on what modules you use--developers of features for Open Atrium face not having their OG settings exported, which is a continuous pain the behind.

Assuming the original flaws crept in because of a bad/missing Strongarm, I am marking this as Works as Designed. If this functionality is actually not working, it is either a bug with Strongarm or hook_features_pipe_COMPONENT_alter().

I encountered this today, using strongarm 7.x-2.0-beta2 and features 7.x-1.0-beta2 enabled, and expected features to auto-magically include the settings of my content type into my feature. It did not, even when I re-created my feature, and clicked the contenttypes again.

node_options_* is exported, but node_preview_* and node_submitted_* are not. (not using the comments module here.)

Hi, why isn't strongarm a dependency of this module?

When I export a content type, I expected these settings to be exported too. I'd guess that's a pretty common expectation. If not a module dependency, it's for sure worth a mention on the project page.

ATM, with D7 dev of strongarm and features, the "Whether or not Preview is allowed / available before saving the node" setting is not being saved.

The other 3 settings appear to be saved.

Workaround:
1) Install Features, Content Access, and Strongarm
2) Set the permissions on the people->permissions tab. (content type->access control tab may work too, didn't test)
3) Use features->permissions->all content type permissions you want to save
4) Use features->strongarm->"content_access_settings". Other stuff should be automagically included.

I didn't find a way to backup the preview settings.

If you not export the permission the administrator can not create the content type, content access is not required, go to permission ad activate it

Features is doing its job, you need Strongarm as well if you want the variables.
Regarding the missing variables, it has been partially fixed in Strongarm dev version (see #1117882: Update hook_features_pipe_alter() with D7 variables), #1233642: Follow-up of #1117882: Update hook_features_pipe_alter() with D7 variables is waiting for a commit.

I suggest to change the issue to Documentation feature request so somebody mentions Strongarm for variables export on the project page.

This is not a feature request; it is proper documentation. As "Content types" are listed as supported components on the project page, further information needs to be added saying that their settings are not unless Strongarm is also installed. This could simply be a sentence in parentheses appended after "Content types" in the list.

EDIT: With the latest dev versions of Features and Strongarm, everything came through except for the menu settings in one specific content type. It was only one; the others were flawless.

There will always be issues like this. You should never use Features "blindly". For example, if you enable additional Display Modes (such as RSS) you will discover that the enabled flag is also not exported via the Content type. Once again, it's because it's stored in a variable. If Drupal kept everything nice and organized into a single data structure then this wouldn't be a problem. But Drupal often uses variables to store all sorts of different settings. I never install Features without also Strongarm.

I agree that it could be better documented though.

Also, other contrib modules might add settings to the content type page, which features/strongarm can't know about, or somewhere else. It's a loosing battle.

I do however agree that it should be documented. I was in the other camp and was surprised to see that exporting a content type would also strongarm a slew of variables.

Xen: #1400298: Removing auto-detected components from a feature (UI update, removing Ajax) for discussion (that I'm trying to start) on how to make the process of additional components added less forceful.

(Fairly certain adding further documentation is a feature request, but whatever. I generally only use task when making something for myself to do, as otherwise it feels presumptuous).

then ..is it not there the possibility to export menu settings for nodes?
pleasee help me!!
thanks
A

For #21, squinternata:

You'll need to export menu_options_CONTENTTYPE with strongarm

A quick note here: exporting with strongarm is done automatically but does not always work: it seems that the variable is imported, but reverted to its default value (array(status)) when the actual node is imported. Here is how to reproduce this:

- enable strongarm + features on a brand new drupal 7 site
- set your page publishing options to "not published, with new revision"
- create a new feature with the page content type (the variable node_options_page should be array(revision)).
- create another brand new drupal installation (by hand or using simpletest)
- import your feature
- note that if you check node_options_page it is now array(status) -- the variable has not been properly imported, or rather, it _has_, but has been reverted.

I'm saying it has been reverted because if you do add an update hook to your module's install file and try to install it on yet another brand new drupal installation, it still does not work.

function mymodule_update_7001() {
  // running into http://drupal.org/node/1105670 -- but even
  // with strongarm, having a hard time making default revisions
  // and published by default work.
  
  // dang, even this does not work, seems that node_options_page
  // reverts back to array('status') when a node type is imported
  // ... see mymodule_requirements() in the .module file:
  // visiting the admin/status/report page should solve this.
  variable_set('node_options_page', array('revision'));
}

The above code does get called, but the variable seems to be _reverted_ when the node type is imported. My solution is to have this code in my hook_requirements() :

function mymodule_requirements($phase) {
  $requirements = array();

  if ($phase == 'runtime') {
    $node_options = variable_get('node_options_page', array('status'));
    if ($node_options != array('revision')) {
      variable_set('node_options_page', array('revision'));
      drupal_set_message(t('The page node (default published, revision, etc.) options were not imported as expected. An attempt was made to correct the situation.'));
    }
    $requirements['node_unpublished_page'] = array(
      'title' => t('All pages should be unpublished by default'), 
      'value' => serialize($node_options), 
      'severity' => $node_options==array('revision')?REQUIREMENT_OK:REQUIREMENT_ERROR,
    );
  }
  return $requirements;
}

Hmm, tried it with content types other than the built-in page, and everything works as expected. It seems to be impossible, afaikt, to create a feature which defines the page as being not published, not promoted and with a revision.

Found this issue while searching to understand why Features was not preserving content type settings.

I'm of the view that Features should include strongarm as a dependency and just not quite sure how to respond to comment #19.

Documentation including the brief mention on the features project page under related modules is not sufficient to understand the dependency unless you've already encountered it.