Secondary menu

Playing with features, once they're created

japerry's picture

Playing with features, once they're created

Written by Jakob Perry on

Features is a wonderful module, it allows you to put in code, pieces of functionality that is otherwise created in the UI. (For more information, look at these slides on features

But while features are great to start out with, they can be a pain to edit after they're first created. Here are some woes people first face when dealing with features

  • Content fields cannot be easily deleted

  • Content fields cannot be changed

  • Exporting updates can be difficult

  • Adding to existing features are also difficult.

Why can't I alter my existing content fields?

You don't want editorial content to be deleted with a feature revert accidentally. The module sides on safety, even if it sacrifices convenience. Unfortunately, this means going in after the fact and deleting the field from the CT manually from any site you're working on.

For example: You have localhost and mywidgets.com -- if you delete the field from localhost, and export the feature, you're all good locally. However, if you then pull in the feature to production and then revert it, the field will not go away. Worse, if you make changes on production and export these changes to a feature (don't do this!), you'll end up with that deleted field back in your code. Make sure to manually go into production and delete the field once you revert the feature.

Should I combine my views and CTs together or have them be dependencies?

In general, its probably best to keep them separate. Having combined features can cause issues if you need to revert a certain part of the feature, but don't want to revert the other part. For example: if you have an 'events' feature, that combines an event content type and an event listing view. If an editor made a change to the event listing title, this would be lost if you revert the feature when making a change to the content type.

If my features are always in the default mode, is it ok to group them together??

While I think its a good goal to achieve, it can be very difficult to maintain, especially if you are running a feature in a multi-site setup. Many times you'll see features used as the 'bootstrap' to get the structure 80% of the way, and then special customization afterwards to titles, certain fields, etc. If this scenario affects you, its especially important to separate your features into a 1-to-1 grouping of components to modules.

On the other-hand, if your don't have any use-cases where the feature could be customized (if multi-site), or you're running one site where you can export the changes, then its more acceptable to group common components together.

I made a node_reference field, and now it needs to be a node entity reference field, but I get an error -- what do I do?

WD php: FieldException: Cannot change an existing field's type. in field_update_field() (line 234 of /modules/field/field.crud.inc) [error]

In general, you shouldn't be changing fields after the fact. And if you have data in these fields, you really shouldn't be changing them. Its recommended you name the new field something different, and then do a content migrate. However, if you're still in the building phase, and have no content for the content type, there is away around this.

First, make a new field in your content type, and build it like you would any other field.

Second, export your feature, the quick way is to use 'drush fu (feature_name)'

Third, goto your database, field_config table, and change the type and module for the field you really want to change, to the same values in the fields of the new 'temporary' field you just created. (by using the same name and placing a _2 after, etc it'll show up right below in the table layout. Delete the temporary field you created. Forth, edit your feature directly. Delete the code that represents the old field, and then find the new field you just made and rename it to be the old field.

Fifth, use 'drush fr --force (feature_name)' to refresh the feature/content type. You shouldn't get the error above anymore!

Sixth, check your feature. If it shows overridden, but the field otherwise is appearing properly, re-export the now migrated field.

How do I easily update my feature? The best way to do this is with drush. Its fairly annoying to have to re-download and unzip a feature every time you want to make a change! drush fu (feature_name) drush fr (feature_name) Despite the vulgarities, drush fu is 'feature update' -- or as my co-workers like to say 'FU module, we're replacing you!'

A note about drush fr and fra (feature revert and feature revert all). Be very careful when using drush fra. If your site is not all in default, there is a good chance an editor will get very mad at you!

Features, while they have drawbacks, are a great way to codify your sites components. It has work left, but I haven't seen anything else that can be as reliable to use when migrating new components into large enterprise websites