Skip to main content

Drupal 7 notes - dealing with "ghost fields"

Posted on: Wednesday, 12 January 2011 @ 11:34pm
Blatting about
More specifically

Came across a problem someone else on Drupal dubbed "ghost field" in one of the issue queues.  My issue with ghost fields came about while setting up Profile2 to use in my profile (strangely), but the problem happens in other modules as well.

The problem

  1. create a profile type (or modify the main one)
  2. add a field
  3. delete the field (I don't recall seeing any difference between saving data in the field or not)
  4. try to add a new field with the same name, get an error saying the field name is already in use, but it doesn't appear in the "Add existing field" list

The solution

  1. manually edit the database.  I use phpmyadmin.  Whatever works
  2. find the tables field_config and field_config_instance, browse them and delete all incidences of the "ghost fields"
  3. fields can now be recreated

After deleting the ghost field instances the php fatal error and associated debug messages I'd been having trouble tracking the source of (Entity was getting blamed) disappeared, quite conveniently.

No comments yet

shunting Friday, 29 April 2011 @ 10:39pm [Permalink]

Thanks, that worked for me. Nasty.

bek Saturday, 30 April 2011 @ 8:44am [Permalink]
Valante Friday, 2 September 2011 @ 11:24am [Permalink]
I had a weird variant of this problem, where the field_config and field_config_instance tables were fine (no mention of my ghost fields), but the field tables themselves still existed. In this case, it's apparently important to drop both the field_data_field_NAME table and the field_revision_field_NAME table.
bek Friday, 2 September 2011 @ 4:53pm [Permalink]
Oteno Saturday, 11 February 2012 @ 7:43pm [Permalink]
Thanks, helped to uninstall a module with an "used" field
bek Sunday, 12 February 2012 @ 12:05pm [Permalink]
Sebastian Wednesday, 7 March 2012 @ 3:36am [Permalink]
Thank you!
bek Wednesday, 7 March 2012 @ 10:31am [Permalink]
Jaakko Wednesday, 4 April 2012 @ 6:46pm [Permalink]
Another solution(The Drupal Way?) is to place field_delete_field('fieldname'); into index.php right after bootstrap. According to documentation this will mark the field and its instances and data for deletion.
bek Thursday, 5 April 2012 @ 2:12pm [Permalink]
Jaakko Saturday, 7 April 2012 @ 4:28am [Permalink]
I wouldn't count index.php as core but everyone can have their opinion.And getting your hands dirty while manually deleting data from db seems more hackish to me than using Field API from index.php. In the end, using the API will ensure that everything is done "by the book" and no related or otherwise dependent data is left over. Otherwise there might be more "hacking" to do.However, my solution came up when the site was down(install/uninstall failed) and certain fields seemed to be causing problems. So the solution was one line, one function and no hassle :) But as I said, everyone can do  it their own way.
bek Saturday, 7 April 2012 @ 7:58am [Permalink]
Anonymous Monday, 23 April 2012 @ 12:49pm [Permalink]
ax0rz Tuesday, 24 April 2012 @ 7:48pm [Permalink]
If anyone's wondering how to finally purge the fields marked for deletion -- field_purge_batch()
ax0rz Tuesday, 24 April 2012 @ 7:49pm [Permalink]
Oh, it gets run on cron, so you might just want to do that manually. :) Sorry about the weird formatting in the previous message.
bek Tuesday, 24 April 2012 @ 7:55pm [Permalink]
Jen Lampton Friday, 15 November 2013 @ 5:15am [Permalink]
Running cron once doesn't always do the trick.  If it doesn't work the first time, you may need to run cron 10 or 20 times to get the fields to actually be deleted. Its faster to just manually delete the two tables (field_data and field_revision) as well as the two records from field_instance and field_instance_config. Still not resolved as of the latest version of D7.
Simon Burnett Thursday, 14 February 2013 @ 7:26pm [Permalink]
We just experienced the same thing. Field tables were in the database but the config tables didn't have any entries. Dropped the field_data and field_revision tables for these ghosties and all was fine. Issue was after using Feature to add a content type but not sure if that was the issue or not. Tried the feature again after and it worked.Prefer the sound of the API call in index.php perhaps but comfortable with restoring our DB (plenty of backups!) so was easy for us. thanks all!
Daz Tuesday, 5 March 2013 @ 5:31pm [Permalink]
The best "Drupal" way to do that would be to use drush field-delete {field-machine-name}. @see
Daz Tuesday, 5 March 2013 @ 6:05pm [Permalink]
Well, my mistake, you got to drop table manually
Ashley Tuesday, 16 July 2013 @ 5:19am [Permalink]
I'm having the same problem but even after I delete field_data_field_NAME table and the field_revision_field_NAME tables I still get the "Fields pending deletion" message on my modules page that prevents me from disabling the field collection module. I also get "WD cron: EntityFieldQueryException: Unknown field: field_name  [error]" when I try to drush cron from the command line. Any ideas?
Ashley Tuesday, 16 July 2013 @ 5:55am [Permalink]
I kept reading about this and found the following post: I ran the sql in comment #1, I ran "DELETE FROM `field_config` WHERE `field_config`.`deleted` = 1;" This fixed my problem. Maybe it will help others also.
bek Sunday, 21 July 2013 @ 2:57pm [Permalink]
Adrien Saturday, 11 January 2014 @ 11:07pm [Permalink]
Hi,I also had to run TRUNCATE cache_field because drush cc all still gave me the error. Thanks for the tips. 

Add new comment

The content of this field is kept private and will not be shown publicly.