I noticed that when enabling a feature on a site that includes a content type the ordering for non-fields in the cck type is ignored. By non-field types i mean things like taxonomy, menu settings, revision information, path settings, comment settings, etc. Anything you can re-arrange on the manage fields page of the content type.
Before I started using features for this I was just exporting the content type and importing it on site creation. The exported content type includes this (for example):
$content['extra'] = array (
'title' => '-2',
'revision_information' => '2',
'comment_settings' => '4',
'menu' => '1',
'taxonomy' => '-3',
'path' => '3',
);
Which I believe sets the weights for each of the extra fields. Am I just missing something in the feature or is this a bug? Also, I'm not sure if it's relevant, but I'm installing this feature through an install profile. Not adding it to an existing site.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | features_693944.patch | 2.5 KB | hadsie |
Comments
Comment #1
hadsie commentedIt turns out it also doesn't seem to respect the weight on the regular fields either. Looking into it a bit further it seems that the weight needs to be set at the top level of the object in order for content_field_instance_create to set it appropriately, currently it's just in the display_settings and widget attributes of the field (exported in myfeature.defaults.inc).
I've attached a patch that allows for the weight to be set properly for both regular fields and non-cck fields. I'll do more testing on it today and update the ticket if I find any issues with it.
Comment #2
hadsie commentedComment #3
john.karahalis commentedWe noticed this issue also. Is there any way we can get the Feature devels involved in this conversation?
Comment #4
hadsie commentedI'm pretty sure that the devs /are/ working on this problem, but in a more generic sense. The problem is that these settings are stored in variables which aren't currently handled by features. This is describe in this issue: #401948: Node settings change not triggering "overridden" flag
For now though this patch seems to do the trick for me.
Comment #5
yhahn commentedI've committed strongarm integration to address this here:
http://drupal.org/cvs?commit=325346
Diff here:
http://drupalcode.org/viewvc/drupal/contributions/modules/features/inclu...
(You can see that having a working variable export system makes these sorts of fixes stupid easy : )
Note, you'll need the latest Strongarm release (2.0-rc1) and need to be using the latest checkout of Features DRUPAL-6--1 for this to work.
Comment #6
hadsie commentedAwesome! Thanks yhahn!