Features re-creates my deleted cck-fields

Yeah, I can confirm this.

It happens because function content_features_rebuild() creates field instances if they are missing...

I'm wondering why this isn't constricted to content_features_revert(), since content_features_revert seems to have the same code in it, just limited to updating an instance, not creating it if its not there.

Other features includes don't use hook_features_rebuild, so I'm going to try and patch content_features_revert to do what content_features_rebuild is doing.

Just FYI, this is on our radar and is a result of CCK being a non-exportable object type. The current solution we've been tossing around is to have Features prompt you on admin/build/features with a form to create new CCK fields that are defined in code for a feature you already have turned on -- this will let site builders opt out of re-creating CCK fields that they just deleted so they can update their feature codebase.

It's true that we could only do this on revert but will be pretty surprising for users who find that they must "revert" a feature to get the new CCK fields that are defined in a new version.

The real answer to all of this of course is to get exportables into CCK : )

We are using Features for development on a large complex site, and in my testing I noticed that "Revert" is exactly the way to load up an updated feature that includes CCK fields.

Since CCK is in the DB, when you "svn update" an get a new version of a feature module, it triggers the "overridden" flag.

Then, you "Revert" back to code status... While I agree that the naming conventions are a little confusing, I think this makes sense.

If you make changes to CCK fields, the code, as it sits now silently "reverts" your CCK types back to default when you visit the features page, making changing CCK fields impossible unless you "drush features update" before you visit the features page.

Here's the patch I made that puts the field updating and creating into the Revert hook, and removes it from Rebuild.

Seems to work great so far.

ALSO: This patch adds detection of Newly Added fields, which it ignored previously.

Am I right, that at this point the flow to be able to delete CCK fields managed by a feature is: delete the field definitions from file (*.defaults.inc), delete the fields from the database ?

subscribing

subscribing

Hi,

when applying the patch on beta-3, I get errors...

Hunk #1 succeeded at 31 (offset 2 lines).
Hunk #2 succeeded at 86 (offset 2 lines).
Hunk #3 succeeded at 149 (offset 2 lines).
Hunk #4 FAILED at 169.
Hunk #5 FAILED at 212.

What is the status of this patch with regards to beta-3? Is it already incorporated?
@careernerd: could you revise & re-send the patch so it would work on beta3? Or has so much changed since alpha 3 that the patch & CCK mods have a problem?

http://drupal.org/cvs?commit=270108

As of this commit, CCK and all features_rebuild() implementers get a big improvement up in terms of change management workflow. Your deleted CCK fields should no longer get automatically resurrected. I would love some additional testing before closing this issue.

Is the issue #480978: Fieldgroup support taken into consideration? I tried to apply patch in that issue, but one hunk out of four failed.

Closing, addressed now by http://drupal.org/cvs?commit=290546.

Handling fieldgroups properly is a different issue, please follow here http://drupal.org/node/480978