Features Module Support

This would be a great addition! plus one. great work on this mod. Easy and simple to use, without the overhead of DS.

This is already possible.

To capture your custom view modes in your Feature, select the Strongarm component, find the "entity view modes" variable, and check the box to include it in your Feature.

You also must capture the field settings in your content-types (or whatever entity you're using a custom Entity View Mode for) into your Feature, which I'm sure you're doing anyway.

Unfortunately, that means you can only export ALL view modes into one feature.

Correct status.

An export creating the real code like http://mearra.com/blogs/juha-niemi/drupal-7-custom-node-view-modes would be very nice.

All views mode is config in module entity_view_modes we had stored in variables table with key: entity_view_modes

function entity_view_mode_entity_info_alter(&$info) {
  foreach (variable_get('entity_view_modes', array()) as $entity_type => $view_modes) {
    if (isset($info[$entity_type]['view modes'])) {
      $info[$entity_type]['view modes'] += $view_modes;
    }
  }
}

We are using module strongarm for this features. ;)

See comment #3 though.

It would be much better to have one table row per view mode and so export then one by one.

I'm not entirely sure, but is this keeping the huge monster variable this module uses and then extracting/merging back in the bits from it for Features?

> Ctools exportables are built around database tables and their schema info. #8 is suggesting that we add a new table for view modes, and I don't know if that's essential.

It's not essential, but it would be nice, as it would allow for #1702530: Store view modes in an entity_view_mode table (compatible with Display Suite?). And it would make Features support much much simpler!

i think it makes all sense to move the view modes from a variable to a {entity_view_mode} table.

this will allow entity_view_mode to be used by other modules easly, which adds visibility in the community
and also permit individual view mode exportation, which adds flexibility

might add, Entity View Modes makes a perfect companion for Panelizer =)

------------------------
i think we should also push this as much as possible into D8 Core.
we already have Views and Entity Translation UI moving in, so it only makes sense to add this as well

mark as major?

edit:
actually, see this ^_^
#1043198: Convert view modes to ConfigEntity

I've implemented the patch in #12. On a few different test platforms the feature comes in as overridden and these values aren't recognized until I revert the feature. Once that's done everything works great!

On another note, I would also agree that hook_entity_info_alter() seems cleaner.

Isn't there a way to tell features how to output our exportable? If so, can't we tell it to output hook_entity_info_alter() in the way we need?

It would be great if we could use a forward-looking hook for features exports of view modes, so I'm wondering if we should have #1900676: Add specfic hooks for defining entity view modes (backport from D8) land, and then review the following patch.

Thanks, patch with correction.

Re-rolled for 7.x-1.x.

Re-rolled for 7.x-1.x. Fixed that hook_features_revert() should delete the item from the variable rather than re-save it.

Any feedback on #28? I am very tentative to commit it without any kind of testing from someone other than myself so it may have to wait until the next release.

I can confirm that the patch in #28 is working, My set up is perhaps simple: I have three custom view modes which I tested with some image and video file display settings. The view modes exported as a feature module are listed as "In code". This is my first successful attempt at exporting entity view modes, so thank you very much!

Patch #28 seems to work for export but my exported view mode always appears as overridden. Honestly I think this should still be put into the module. The core of the functionality works. You can apply this patch and create a new case for this overridden issue.

To reproduce my issue: Create a coupe custom view modes. Export one of them in a feature. Enable the feature and revert it. The feature always appears as overridden and the diff displays the previous value was false while the current value is the exported view mode.

Hmm, I don't think the workflow in this patch is quite right. Basically it looks in the 'entity_view_modes' variable to see which view modes are available for export:

+++ b/entity_view_mode.features.incundefined
@@ -0,0 +1,121 @@
+
+  $view_modes = variable_get('entity_view_modes', array());

But, when I enable the feature on a fresh website, the view modes it defines are declared in a default hook, are listed as "In code" in the entity view modes UI, cannot be edited in the UI and never make it into the 'entity_view_modes' variable. As such once an entity view mode is exported into a feature and 'properly reverted' (i.e. removed from the DB), it cannot be chosen again in the Features UI.

With every other features exportable config in Drupal the following workflow is possible:

1. Export a piece of config into a feature
2. Copy the feature to a fresh site, enable it - creates the piece of config
3. (Still on the fresh site) Make a further modification to the piece of config, Recreate the feature to 'update' the export code.

Indeed many people use that workflow generally while site building to keep config in code, for moving around between staging/live sites or passing to different developers in the same team.

At the moment, when I create a feature the first time & move it to a fresh install and recreate the feature again, Features loses all track of it actually being in the feature - i.e. the features[entity_view_mode] entry is removed from the .info file. In fact, at the moment I think the only reason that my feature still contains the hook_entity_view_mode_info() implementation after being Recreated is 'by accident'; if I had some other piece of config in my feature which also exported to the 'FEATURENAME.entity.inc' file, then Features would explicitly overwrite that file when recreating the module and the hook_entity_view_mode_info() implementation would disappear.

Perhaps the answer is to put a special flag 'features_export' => TRUE inside each features export? Then when listing components for features, list everything from the entity_view_modes variable and all default entity_view_modes which have that flag on it?

@jamsilver: The current stable version of Strongarm stores the data in the variables table rather than loading it via hooks, are you sure you're using Strongarm v2?

@DamienMcKenna: Since I'm testing the patch in #28 I'm not exporting the entity view modes with Strongarm at all, but rather with the functionality that the patch adds :-).

I'm sorry to say this when a lot of work has been done on this patch, but I really don't think it's useful without #1702530: Store view modes in an entity_view_mode table (compatible with Display Suite?).

My reasoning is this: best practice with Features tends to be grouping parts of site functionality into different features. So suppose you have a site with a news page and an events calendar. You would probably want one feature for each of those, providing the node type, the fields, the views, and so on.

But when you have, say a 'front page news scroll' view mode for your news nodes, and a 'calendar pop-up' view mode for your event nodes, and you want to export them, you run into trouble: having a single variable for all the view modes means you can't split them up over several features.

Joachim,

I both agree and disagree with you here. Features would be much more useful to entity_view_modes if they were able to be exported separately. However I believe this patch is a step in the right direction. And until the case you mentioned is added this patch should still be good to apply. It wil force future patches to support features including when entity_view_modes are moved into tables. I think both patches need to continue to progress and whichever goes in first the other patch can adjust to meet it.

I have a problem, If a view mode is in a feature but not in a DB, the diff module shows that your feature is overridden. The difference in a view mode.

Here is what it shows:

I tried to revert it via Drush and from interface, nothing helped.

Agree with #35, lets get #1702530. In, while this feature is important. Schema will completely change what is exported within a feature (likely allowing more granularity). Besides #1702530 looks pretty straight forward and should be close to getting it passing automated tests.

If that is the case then lets postpone this and work on #1702530: Store view modes in an entity_view_mode table (compatible with Display Suite?)

#1702530 was updated and is now passing testing. Please test!

Hi, sorry but I have been looking at #1702530 and the new structure is almost ready. Did somebody already had a look at the possible changes?

Patch from #28 work for me; many thanks!

#1702530: Store view modes in an entity_view_mode table (compatible with Display Suite?) is RTBC, let's mark this as active again.

to be able to cleanly apply the patch from #1702530 and still use the patch #28 above, simply do this:
git clone entity_view_mode
then : apply this patch from #28
then apply this interdiff
then apply patch 54 from #1702530

I am not sure if this works yet or not, haven't yet tested.

see next comment instead

new interdiff.
to be able to cleanly apply the patch from #1702530: Store view modes in an entity_view_mode table (compatible with Display Suite?)
AND still use the patch #28 above, follow these steps:
Step 1) git clone entity_view_mode OR cd sites/all/modules/entity_view_mode
Step 2) apply this patch from #28 (EXAMPLE: patch -p1 < example.patch)
Step 3) apply this interdiff (patch)
Step 4) apply patch 54 from #1702530

I've tested this, while it allows capturing of very basic things, the features_revert is actually doing a delete instead of a rebuild. So you can capture something (limited so far) but you cannot revert it.

needs work

prior to either of these patches, features using strongarm can capture the File_entity display settings.
if we apply #1702530 then strongarm won't work anymore however that is what this issue is about, making a features export. the patches listed in #45 are a start but is a work in progress.

This needs an issue summary update.

If I remember correctly the goal is to allow users to add view modes from this module to features and not have to rely on strong arm. Currently #1702530: Store view modes in an entity_view_mode table (compatible with Display Suite?) is a dependency of this as it changes the way the view modes are stored. So this issue should tackle adding featurability back to this module.

now that #1702530: Store view modes in an entity_view_mode table (compatible with Display Suite?) is reviewed and tested, can we hope to see a rc2 with these two developments?