I am trying to install a feature on an existing site with that already has some of the same field names (field_image for example), and I get the following error:
FieldException: Cannot change an existing field's type. in field_update_field() (line 230 of /var/aegir/platforms/dcpl-drupal7/modules/field/field.crud.inc).

This is related to #1058902: Error when enabling Debut Article, where they recommended:

This bug can be fixed following an approach used in media_gallery.install, which detects existing fields and throws a hook_requirements() error if there's an existing field with the same name but a different type. Arguably this should go in features, but a workaround in debut_article and other debut features meanwhile is important.

Comments

rp7’s picture

subscribe

wmostrey’s picture

I'm experiencing the same issue, and I wonder why this shouldn't be allowed. I'm trying to update a file field to an image field using Features. The change really is minimal, but as the comment in field.crud.inc says around line 230: "// Some updates are always disallowed." Why exactly is Drupal core specifically disallowing us from doing this?

Should we move this issue to Drupal core?

yched’s picture

Core disables changing an existing field's type because changing the field type possibly means changing the data schema ('columns'). Changing field type is considered a data migration topic, and left for contrib to handle - it was out of scope of the Field API D7, as it was out of scope of CCK D6.

In terms of Features, though, I guess Features could handle deletion / recreation of a new field with the same name - that means the loss of field values, though.

wmostrey’s picture

I don't think deletion/recreation is the way to go (and I don't think loss of field values is acceptable). My use-case was a move from filefield to imagefield which isn't so drastic.

Given this information, I'm inclined to mark this as "Won't fix".

rj’s picture

We ran into this problem when changing a field type from text to text_long, which took down our QA server until I figured out what happened. Would be nice if features gave a warning about this before drush fu is run (ie. danger will robinson, you have changed a field type, are you sure you want to proceed?).

hefox’s picture

Hm, my guess is ideal here would be for features to prevent enabling of the module, and for another contrib module to handle converting the fields (so then the feature could be enabled). Or tell user that that field needs to be deleted.

btully’s picture

Same problem here. Is the only option to completely wipe the database and reinstall from scratch? Or are there some shortcuts such as deleting certain tables/rows from the database that would provide a temporary workaround?

zhangtaihao’s picture

There's possibly a related topic in #1664160: Catch field exception when rebuilding (esp. in regards to DB column change). The stopgap was for Features to catch the FieldUpdateException and log the error. Of course, the problem is magnified in Drush.

giorgio79’s picture

Kristen Pol’s picture

I got this error and I went through and deleted all the content types (via the Drupal UI) and then the error went away (all content types were in a Feature so I didn't lose anything).

thirdender’s picture

Patch #2 is definitely at least helpful in finding the problem. Before I applied the patch to my installation I didn't even know which field was causing the issue. I previously fixed the problem by deleting the content types and letting Features recreate them (like #10 did), but that didn't seem like a good option long term. Fast forward a few weeks when people are starting to use the system. The problem reared it's head again after a botched update, and it feels like even less of an option now :-p Patch #2 at least got the site running past the error so I could see what Features is doing and know which field is having issues. However, the message is only logged to the watchdog, and no error is displayed. Not sure how I feel about that.

I don't think the field in question actually changed types either (I haven't modified this field for a few weeks), so I think there's something else at play. This is my first time using Features, so I'm not sure how well I'll be able to pinpoint the issue. Harumph, just reverted the components of the Feature and everything is working fine now…

fejn’s picture

Issue summary: View changes

@thirdender: Thanks for mentioning that Patch #2 helped you figure out what field was causing the problem; Could you make that a link: I don't know what Patch #2 is, & haven't stumbled across it reading other stuff (yet).
Thanks, Jeff

kappaluppa’s picture

I'm looking for "patch #2" as well... where can I find it?

thirdender’s picture

Sorry guys, I just read and re-read this thread and I have no idea what I was talking about :-p What issues are you experiencing now? Is it the same error as the OP?

If you're not experiencing a White Screen Of Death, try checking your watchdog logs (admin/reports/dblog). See if there is an exception logged there with additional information about the offending field.

Virang’s picture

Same problem is here guys, i want to change existing field type form user registration page. is there any idea then please help me.

sammarks15’s picture

Adding a relation to #1664160: Catch field exception when rebuilding, which fixes this issue by providing error messages in watchdog instead of throwing a fatal error.

AaronBauman’s picture

#1664160 is closed, but this issue persists.
The user needs better feedback in order to know what action to take.

Don't delete the field - fine - but a hard fail with no explanation is not OK.

dwork’s picture

In my case (my own feature), I had actually redefined an existing field, so the correct fix was to rename the field in the feature. Sorry, I don't know how to patch, but I added some code to modules/field/field.crud.inc about line 233 (Drupal core 7.43) to help debugging.

// Some updates are always disallowed.
if ($field['type'] != $prior_field['type']) {
$f = $field['field_name'];
$ft = $field['type'];
$pt = $prior_field['type'];
throw new FieldException("Cannot change an existing field's type: $f .. $ft -> $pt");
}

Just an aside, but most Drupal module errors are incomplete and fail to give enough info for easy debugging.

mpotter’s picture

Category: Bug report » Support request
Status: Active » Postponed (maintainer needs more info)

Unless you are really talking about legacy support you should probably update this to reference 7.x-2.x branch, and a patch would still be needed (have no idea what all the references to Patch #2 is)