Hi:
I'm trying yo make a feature which include a blog content type and some custom display modes. I'm able to export all components but which views modes are active for a content type... If I enable a views mode to have custom display settings I can see all DS settings imported via the feature. But I have to enable this view mode manually.
I've managed to found that this information is stored in field_bundle_settings system variable but I don't want to export this variable with strongarm since it contains information about all entities (not anly the blog one).
This are the lines related to DS in my features info file:
features[ds_field_settings][] = "node|blog|default"
features[ds_layout_settings][] = "node|blog|blog_list_landing"
features[ds_layout_settings][] = "node|blog|default"
features[ds_view_modes][] = "blog_list_landing"
And this is where the custom views modes are stored:
field_bundle_settings: Array
(
...
[node] => Array
(
[blog] => Array
(
[view_modes] => Array
(
[teaser] => Array
(
[custom_settings] => 1
)
[full] => Array
(
[custom_settings] =>
)
[rss] => Array
(
[custom_settings] =>
)
[media_gallery_block] => Array
(
[custom_settings] =>
)
[test_view_mode] => Array
(
[custom_settings] => 1
)
[blog_list_landing] => Array
(
[custom_settings] => 1
)
)
...
Perhaps this support request is best suited at the features modul, but I want to know if someone has the same issue.
Many thanks.-
Comments
Comment #1
johnste commentedI'm having the same issue, however I'm not using Display Suite.
I'm using i18n and have hidden the language field which I want to export. This is also saved in field_bundle_settings. If I export it to a feature using strongarm the site breaks when I restore the feature. I think this is a Strongarm issue.
Comment #2
swentel commentedI think hook_entity_info_alter() should be called for those settings too. I'm currently marking this won't fix since this is really a core setting or something that should be fixed either in features/exportables or strongarm.
Comment #3
neurojavi commentedReopening, changing title and moving to features module...
Comment #4
ademarco commented+1
Comment #5
mlncn commentedI believe i'm running into the same issue. I removed the Teaser build mode on a Features-controlled content type and now the Feature immediately declares itself overridden, and adds the Teaser build mode back for each field.
Are there / could there be options when declaring a content type in a features .info module for what custom build modes it should include? It seems to be creating the default (Default and Teaser) automatically.
Comment #6
simon georges commentedSubscribe.
Comment #7
damienmckennaThe field_bundle_settings variable is one of the worst things ever in D7, and I personally think it's a core flaw. This variable should NOT be a single value for ALL content types, it should be PER content type.
Comment #8
simon georges commentedAgreed !
Comment #9
damienmckennaOh, wait: #1211008: Split field_bundle_settings out per bundle
Comment #10
yched commentedMy very own bad, and I only realized this a couple weeks ago.
Core patch posted in #1211008: Split field_bundle_settings out per bundle
Comment #11
pfrenssen#1211008: Split field_bundle_settings out per bundle has gone RTBC! :)
Comment #12
pfrenssenIt is not obvious to me how this can be implemented in Features. These settings are per bundle, but are stored in the variables table, not with the entities themselves. This rules out implementing this separately per entity (eg in features.node.inc). This is like the other entity settings which are stored in the variables table (such as node revisions, default node publication status etc) - these are also not supported directly by Features but need to be exported with Strongarm.
Indeed with the patch in #1211008: Split field_bundle_settings out per bundle it has become very convenient to save these settings using Strongarm so it might not be necessary to provide this in Features.
Comment #13
simon georges commentedFYI, the patch for strongarm is ready (and has been for a month) : #1306924: Export additionnal settings, just waiting for the core commit ;-)
Comment #14
tim.plunkett#1306924: Export additionnal settings is a better place for this.
Comment #15
a.milkovskysubscribe