How to integrate custom code into a "Features" feature 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' =&gt; 'node_type_1',
'node_type_2' =&gt; 0,
'node_type_3' =&gt; 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' =&gt; 'node_type_1',
'node_type_4' =&gt; 0,
'node_type_5' =&gt; 0,


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

&lt; 'node_type_2' =&gt; 0,
&lt; 'node_type_3' =&gt; 0,
&gt; 'node_type_4' =&gt; 0,
&gt; 'node_type_5' =&gt; 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.
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.