If you delete a field with field_delete_field you did create in your hook_install (like the node_example said http://api.drupal.org/api/drupal/developer--examples--node_example--node...) with a field defined in your own module. The tables of the field are not deleted because, in field_delete_field, field_info_field($field_name) returns NULL. In fact, in _field_info_collate_fields deleted fields (deleted on hook_disable), are not selected.
Here is a patch that corrects that behavior and permit having a module defining fields and using those fields.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 902794-field-deletion.patch | 4.03 KB | superbaloo |
| #11 | 902794-field-deletion.patch | 1.12 KB | superbaloo |
| #10 | 902794-field-deletion.patch | 1.15 KB | superbaloo |
| #8 | 902794-field-deletion.patch | 1.15 KB | superbaloo |
| #6 | 902794-field-deletion.patch | 798 bytes | superbaloo |
Comments
Comment #1
superbaloo commentedMay this patch will apply more smoothly
Comment #2
superbaloo commentedComment #3
superbaloo commentedComment #4
superbaloo commentedCode cleanup thanks to chx
Comment #5
superbaloo commentedAnother code cleanup thanks to chx
Comment #6
superbaloo commentedAnother code cleanup
Comment #8
superbaloo commentedForgot one variable usage :(
Comment #9
superbaloo commentedComment #10
superbaloo commentedpatch format corrected
Comment #11
superbaloo commentedUnix EOL
Comment #12
superbaloo commentedHere we go with tests and comments
Comment #14
chx commentedInline comments use // not /* even if multiline
The test, if you want to use the module page, needs a new module alas that hook_system_info_alter() the field_test module so that hidden becomes FALSE and so it becomes visible on the modules page and enable this little module with setUp. Alternatively you can call module_enable and module_disable directly and use the brand new ( four days )
$this->resetAllmethod after to reset everything.Comment #15
yched commentedI don't understand what this is about.
Can you provide a clear and (if possible) simple list of steps to reproduce the bug ?
Comment #16
superbaloo commented@chx: okay thank you for the tips
@yched:
If a module creates fields in its hook_install defined by itself, the fields would be created correctly.
If you disable it, fields becomes both inactive (because the field_module_disabled unset flag active) and when the cache is being rebuild (triggered at the end of field_modules_disabled) the fields are flagged as "deleted". So if in your module hook_uninstall you try to delete the fields you'd created in your hook_install, in field_delete_field when it looks for the field with field_info_field it gets NULL and fields never gets deleted. This way (if you use sql_storage) the table never gets deleted nor renamed and the records in field_config are not deleted. Then try to re-install the module, the fields gets recreated, the table is still here, you gets an sql error because of the not deleted table and the field will not be available at all.
If you want to check it by your-self, in the patch @#12 i did modify field_test module to trigger the bug.
Comment #17
Tor Arne Thune commentedClosing this as a duplicate of #943772: field_delete_field() and others fail for inactive fields, as the other issue has more recent activity and solutions.