How to integrate custom code into a "Features" feature

Question

My specific problem: In a Feature, I have a View. I want to use this View on several different sites. The View has a nid-argument, which validates Node:type == [node_type_1]. When the Feature get's exported, it outputs the filter settings like this:

'node_type_1' => 'node_type_1',
'node_type_2' => 0,
'node_type_3' => 0,

Problems ensue when the feature is used on site number 2, which, with exception of [node_type_1], has an entirely different list of content types. Thus the list becomes

'node_type_1' => 'node_type_1',
'node_type_4' => 0,
'node_type_5' => 0,

And suddently, I have an override, with a diff like:

< 'node_type_2' => 0,
< 'node_type_3' => 0,
> 'node_type_4' => 0,
> 'node_type_5' => 0,

Some background: At some point, I listened to an interview with a Features maintainer, who mentioned something interesting. It is both possible, and supported, to add custom code into features. I hope that can provide me with more dynamic means of handling this particular part of my problem.

My question is deliberately stated such that I hope someone can provide an answer to my specific problem, as well as similar problems, from other modules. I can easily imagine a similar problem showing up in many different situations. However, if it turns out that no-one can solve the problem in a general fashion, yet can solve this specific problem, I will re-phrase the question title to reflect that better.

Answer 1

You have a few options, to create generic Views.

• One way of dealing with this, would be to add code to the views definition. This would work out fine, but the problem is that the code would be removed when you update the feature - not good.
• Another option would be to exclude the view from the feature entirely. This would work out fine, but in case you have other views in your feature you will get into trouble - no good.
• My way of solving this problem: hook_views_default_alter. This is specific to views, but I believe a similar tactic would be needed for other components exported in features. The hook will allow you to alter the default which will make it possible to alter the view definition and make it fit into the current site. This also works great for views defined by other modules that you want to alter by code.

None of these, however, will fix the problem that features will adapt it's feature to the site it belongs to. That is, no matter how you alter the view, Features will still detect that the current definition (the file) if different from what it would look it if it were to be re-exported to code again. There isn't much you can do about this (without changing features), but I believe this is a needed to make features work like it should. What you are able to do, is to negate the changes that could be made, or to simply choose not to alter the file and let your hook_alter handle it instead to keep the code the same.

I can understand that none of these solutions aren't 100% what you are after. But if you want to have a generic view and you don't want to have features telling you that the view is different from what it would have created, the only solution is to not use features.

If this is a problem you should consider if you actually need features (Views can by itself export and revert views. The only thing missing is drush integration.

Answer 2

I think I've been at your spot before with a single D6 codebase running on different sites and using Features for managing exportables such as Views.

In our example we had site sections running off taxonomies and firing off contexts (which got exported via Features). The problem was that although the name of most of our taxonomy terms was the same across sites, their tids changed, and there where exceptions as well, resulting in the problem you expose above.

Our solution was to go directly into the Feature and substitute the hard-coded, instance-specific variables with our own dynamic code. So we had a custom function in a custom module that would determine the contents of a particular variable in the exported feature. Then after exporting the feature initially, we would go into the array that we wanted to modify, and substitute it with a call to our dynamic function. When reverting features on each individual site the dynamic value would take the place of the hard-coded value. The only drawback to this solution is that you need to copy/paste the call to your custom function every time you recreate the feature. But overall the solution was straightforward, easy to implement, and reliable.