It's possible this issue belongs with the views module, but I think it's only really relevant in terms of what features expects…so I figured I'd start with an issue here and see what everyone thinks.

I'm guessing this issue affects a variety of component types, but I ran into it first when exporting a view that utilizes an imagecache preset (actually I also ran into it while developing my taxonomy integration patch, so any solution here would help me there too). Imagecache presets are, like all other components in features, exported to an array keyed by machine-readable name rather than by numeric ID. This is definitely a good practice, but unfortunately it makes it impossible for any other components in a given feature to anticipate the numeric ID of any imagecache preset they depend upon.

Views, for instance, uses the numeric preset ID to refer to imagecache presets in exported view fields. If, for example, you export a view that expects your "thumbnail" imagecache preset to have ID 4 but you then enable the feature on a site that already has more than 4 imagecache presets, the resulting view will end up using the wrong preset.

Does anyone have any ideas on how we could resolve this? It would of course be best if views' exported code were adjusted to use the machine-readable preset name …but if that's not a possibility, what then?

Thanks!
Adam

Comments

yhahn’s picture

yhahn commented
Status: Active » Closed (won't fix)

The best way to address these issues are at their source:

1. Adding exportables and switching to machine name string identifiers to modules that need them.
2. Fixing references to serial IDs in modules that don't use the machine name strings.

For example, it is perfectly possible for imagefield (my guess as to what is actually providing the Views handler in question) to refer to imagecache presets by their machine names. It should be fixed there.

As for modules like taxonomy that live in core, unfortunately we're pretty much out of options besides working in the core issue queue. I don't think it makes any sense to start writing a layer of serial => machine / machine => serial switching upon export / cache as it will be specific to each particular module and essentially be a layer of wasted effort that could instead by put into fixing the problems upstream.

jazzslider’s picture

jazzslider commented

I'll be happy to post relevant issues and patches to other projects as necessary. Do you know off-hand if this issue is already on anyone's radar already? I'm definitely motivated to work on it, but I don't want to duplicate effort unnecessarily if I happen to have searched for the wrong thing in various issue queues.

All things considered, though, I'd say this is a pretty important problem to solve (wherever is best), especially if folks want to use multiple features that all provide affected components.

Thanks for getting back to me on this; I'll be looking through other issue queues today, so with any luck this problem should start going away soon :)

Thanks!
Adam

m_z’s picture

m_z commented

@jazzslider:
Do you have some new insights regarding your described problem?

At the moment I modify the files that Features module has been generated and replace the "dangerous" IDs (e.g. imagecache preset IDs) with some constants, that I define in the .module file (or another place). These constants use some "intelligent logic" to find the expected numeric ID. I would be glad, if there is a better solution out there...

jamsilver’s picture

jamsilver commented

The only advice I can really lend is that if you're developing with features on a development machine but need it also to work when it gets pushed to another server, then quite often you need to hand-modify the features export code to safely detect things like taxonomy tids and other things which may not be the same for you as on other machines.

I've just had a look at issue #1317054: Provide support for exporting of altering of components which proposes a slightly cleaner solution for altering feature exports for this sort of thing.