New Field Bases and Instances in Features April 18, 2013 in Development, Drupal 16 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? Richard Schulte This warning is displayed when you run a ‘drush features-update’, actually 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. http://marzeelabs.org/ Peter Vanhee I agree with davereid that we risk running into circular dependencies very quickly. An example is the body field that is shared by most content types. With the new features module, if you have multiple features using the body field, only one of these features will get to claim the body base field (the first one you export). This poses a big problem on features re-usability in other sites (which is still the designed use-case of feature even if features has grown into a deployment model): you can’t simply take out a feature and use it on another site, without also taking out the feature that provided the base field, since that feature has now a dependency on the feature providing the base field.. Mike Potter There were some patches made in the recent RC4 release to improve the handling of field bases and instances that should take care of the problems davereid was having. It still has a problem of the “first export wins” so just be careful to put the base field into the correct export (or export it first). Splitting fields into bases and instances doesn’t actually make dependencies any worse. You still need to think about your modules and their dependencies the same as before. It’s just that now you have a bit more flexibility in handling fields (and with this flexibility requires a bit more thought). Rob Wohleb One problem I’m seeing is the features-update-all command. If a developer accidentally runs that, it will likely wipe out any carefully crafted setup that they have done to put field bases in a master feature. The developer should be using something like git so loss of feature config in code should be minimal, but it’s still a PITA. Even if they make sure that all of the features have the master feature as a dependency, it doesn’t update the master first. This seems like a flaw in the ordering logic, but maybe not. Any ideas? Paul Mackay Mike, are you suggesting that if building a set of Features, or a new distro, that your recommended approach would be to have a “core” Feature that contains shared field bases, and then other Features using those shared fields would depend on it? It would be great if the Features docs could be updated with this info and recommended ways of structuring fields, etc. Mike Potter Maybe, but not necessarily. It really depends upon the project. Recommending ways of structuring fields and features exports is like asking for recommendations on how to structure your web site or your software project. Every project is going to have different specific needs. For a distro, I would *not* put all of your base fields into a single Feature. You still want to group exports by functionality. For example, in Open Atrium 2, we have an oa_core that contains the base field for Section references. But it wouldn’t be appropriate to put base fields for Discussions or Events into oa_core since that would break the modularity of plugins. The base fields for those plugins go into their specific plugin modules, just like they did before base and instance were split. Paul Mackay Thanks for replying The approach I’m thinking is to put some common fields that will be used across many of the other content types in a Core module, and then keep fields in features that (as you say) are specific to those features. http://www.tsvenson.com/ Thomas Svenson Late to the party here and have found this thread most enlightening. I’m working on a new site and will use Features for it and it will also contain many shared fields and many content types. Currently I am leaning against having one or several features containing just the shared base fields. My reasoning for this is that it will make it easier to organize and manage as I won’t have to think twice about where to put them. I also believe it will be easier to manage dependencies when adding or changing site features. As well as make collaboration easier as and when more people join. Would be great to get your experienced feedback on this think Mike. http://twitter.com/emjayess emjayess This still trips me out. Mainly due to the unavoidable arbitrary and arcane resulting dependencies; but also of course the confusion for whom drupal feature dev is a new thing. In my pipe dream, content types packaged into features simply (sic) check for the presence or absence of the base field configuration each requires, and either takes action (if base config = absent) or smiles and moves along (if base config = present)… which would have happy side effects of our features remaining atomic and retaining true portability, and “just work” without being so darn meticulous. Also, perusing around the web (and destinations like Drupal’s stackexchange) reveals that in practice, people are indeed going with (and advising) dedicated features to house field_bases… so it seems like the fallout of this in practice is drifting from what I gathered to be the intended theory of organizing fields in features.