Clarification

I'm no Features expert, but my colleagues have been trying it and found that it didn't play well with our workflow. We have a lot of large live sites that's continually updated, and if I recall correctly, some of the issues were with upgrading smoothly. I seem to remember that it was incapable of updating existing fields, but that can't be right.

One of the advantages of field_gatekeeper is its low tech approach. It only updates fields when told to, so one can place the update in the proper place in a migration process. Another is simplicity, together with Drush EM, changing field settings is just making the change in a dev environment, running a drush command to update the export, check the change into version control and roll the change out to the live servers and trigger the upgrade (through update.php or manually).

I'll see if I can find someone that knows why we abandoned Features.

It's possible you last played with Features before it had graceful support for the same CCK field attached to different content types coming from different features. Or a host of other things. Features is a rapidly developing module.

It sounds to me as though this module provides greater control over when updates happen, and where, but I'm still very hazy on what it provides that a more recent (Beta 6+) version of Features provides.

This sounds like it might be a good solution for very large numbers of CCK fields, but I've not gone beyond dozens of fields myself.

> but I'm still very hazy on what it provides that a more recent (Beta 6+) version of Features provides

More finegrained control? I haven't done it myself, but I see no reason why a module couldn't create a new field in an update hook, migrate some data from an existing field and then update the original field afterwards. But I assume you'd be able to do something like it with Features by using a release as a stepping stone..

That's the idea. It's a mental switch from maintaining the site to maintaining the pieces.

But thank you for the clarification. It's good to know about this module.

> That's the idea. It's a mental switch from maintaining the site to maintaining the pieces.

Hadn't thought of that, but yeah, comes from the history. It was born at a company that makes a lot of very custom made sites, with tight (sometimes too tight) coupling between features.