New Field Bases and Instances in Features April 18, 2013 in Development, Drupal 7 Comments on this post. DamienMcKenna It’s worth noting that there are problems upgrading an existing feature to 2.0-beta2, including the old file not being removed and the new structures not always being added though the old ones are removed; see the issue queue for further details. Mike Potter Yes, I mention the old file that needs to be removed in the blog post above. Definitely will be taking care of the issues on this before the next release. Juan Pablo Novillo Thanks. This post helped me figure out why feature modules were overridden and un-revertable. Would it make sense to add a warning at admin/structure/features that shows that *.features.field.inc files need to be manually removed? davereid So in this new system, should field bases be exported as one big feature independent of content type features? It’s unclear from this post what the default exports should look like. Mike Potter No, this doesn’t really change how you design your features. You should never have any “big features” for all of a specific component. Always group your components by functionality. So put your bases along with your content type. The only time the difference between Base and Instance will really affect you is if you are building upon a distribution where the distribution exports the Base and your export additional instances in your own site features. davereid I’m still running into major problems with sharing field bases across several different content types in individual features. Re-exporting those features is now removing the base fields from some features, and now declaring dependencies on random other features just for the field bases. Basically whichever module gets to ‘claim’ the field base first wins, regardless of who best should have the field base. I’m worried it’s going to start running into circular dependencies quickly. :/ Mike Potter If you have multiple content types in multiple features sharing the same field, Features has no way to guess which feature should own the base. So export the base where you want it first, *then* export the features that share it and depend upon it.