21

What is the best way to remove a Drupal 7 field from a content type defined via the GUI? I want to use hook_update_N so the changes can be propagated to multiple servers upon running update.php. However I cannot seem to find a solution. db_drop_table() would make sense to me for custom defined schemas, but not for a content type/field defined through the GUI.

  • you created a custom module to define a content type? – iStryker Jul 8 '11 at 4:22
  • iStryker: created the content type via the admin interface, added some fields, then exported via Feature. But now I want to remove one of those fields programatically. – amateur barista Jul 8 '11 at 4:58
  • Noted that D5 provides a content_field_instance_delete() function, documented here and here, but that function is not available for D7. Also it is curious what field.install in D7 core uses to delete a fields: _update_7000_field_delete_instance() - a custom "internal" function that is not available for others to use. For something so important as fields, it seems to me that there should be a "public" function available somewhere, and that's what I'm searching for. – amateur barista Jul 8 '11 at 5:02
  • Currently my "candidate" public function is field_delete_instance(). – amateur barista Jul 8 '11 at 5:05
18

There are two api functions to delete fields:

If you don't want to reuse the field, it might be a bit cleaner to delete the entire field instead of only delete the instance of it on the content type in question. Only you can be the judge of that.

  • 2
    Worked like a charm. The function does not return any arguments, so when using in combination with a hook_update_N() I would recommend doing a watchdog() to log your update changes. – amateur barista Jul 8 '11 at 19:17
9

Yes, field_delete_instance() is the function to delete field instances.

Note that field_delete_instance() automatically calls field_delete_field() if there are no remaining instances, so field_delete_instance() is most likely all you'll ever need.

_update_7000_field_delete_instance() is designed for core update functions. Example: in update function x_update_7000(), you are using field_delete_instance(). Then in x_update_7001(), you change the {field_config} table in an inconsistent way and field_delete_instance() obviously needs to be changed as well.

But now x_update_7000()'s call to field_delete_instance() would result in an error because the table is still in the old structure. However, the situation for contributed modules is different, since they should always be executed after all core updates and therefore need to work with the most recent core version.

But, this is a pattern that you might want to use for your own API functions which you are using in update functions.

Additionally, these _update functions do not execute hooks because the outcome is not predictable (for example because the module for which the update is run might be disabled).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.