Is there any mechanism whereby the order in which components are imported can be specified? This specifically concerns the dependency of some components on others, for example a field depending on the machine name of a taxonomy (in the case of content_taxonomy).

One of the existing hooks must allow me to do something like this.

CommentFileSizeAuthor
#3 content_taxonomy_fun.txt3.93 KBhefox

Comments

darrenmothersele’s picture

darrenmothersele commented

I have a feature that exports a vocabulary and a content type with a content_taxonomy field. When the feature is enabled on a new site, the vocab and content type are created correctly, but the content_taxonomy field references the wrong taxonomy. The vid is hard coded in the export for the content_taxonomy field.

Would this (ordering of components) fix this?

zhangtaihao’s picture

zhangtaihao commented

No, unfortunately. Your issue has entirely to do with transforming local objects to/from feature-level components--in other words, moving from local vid's to machine names, UUID's, etc. Some of this is being addressed in #838612: Remove Alterifications from export, but seems to have received no further response since my posts.

On the other hand, I've sort of worked around this problem temporarily. My scenario was a UUID-distributed vocabulary on each end. I implemented hook_content_default_fields_alter in the feature .module file to detect content_taxonomy fields and map each original vid to the target one accordingly. The idea is to maintain a map of vid's to machine names or UUID's from the dev site within the module. This map would allow you to detect the actual vocabularies from the vid's hardcoded into the exported feature on import, so that you can set the vid to the vocabulary as generated on the new site.

hefox’s picture

hefox commented
StatusFileSize
new content_taxonomy_fun.txt3.93 KB

Do a features revert in hook enable/hook update N, listing features in order of wanted revert?

This would be useful; I am doing the same (mapping field to vocabulary).

However, what could be done is in hook_content_default_fields_alter, trigger the rebuild of taxonomy; might cause some double reverts but that seems reasonable.

(Txt file attached is a test to see if a random idea got while typing this works. Making the content taxonomy => vocabulary name exported automatically with the export of the field. From brief testing appears to work. )

zhangtaihao’s picture

zhangtaihao commented

Looking good. I haven't tested this yet either, but the logic is sound. Assuming the export hook works without export options, this is exactly what I was looking for in terms of feature component dependency. Thanks!

Somebody needs to document in the API how pipe alters can be used to do exactly this. Feel like giving it a shot, @hefox?

efesler’s picture

efesler commented

@hefox, the piece of code seems to work properly providing the following change:

at line 109:

$field[$key]['vid'] = $mapping[$field['field_name']];

should be:

$fields[$key]['vid'] = $mapping[$field['field_name']];

thks

mpotter’s picture

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

Closing this for lack of activity. Please re-open this issue if you can reproduce it in the latest version.