Hey guys,

Does anybody know how can I erase fields that are not in use?

I have already erased the content types where they were, but they still show when I try to create one with the same name.

Thanks.

Comments

ttjordan81’s picture

Does the fields exists in another Content Type? If so, then you will need to remove those fields from that content type. Fields that exists in other Content Types could you use again..so check if its being used somewhere else.... Some fields are Drupal default fields and should be left alone.

jfha73’s picture

They are not in any other Content type, they don't show in the database, but when I go to Migrate fields, there they are.

itarato’s picture

I have the same problem.

emarchak’s picture

In drupal 7, you can go to the field list page in reports (admin/reports/fields) to see where they are being stored.

andrea.brogi’s picture

I have some field that don't have any content connected.

Ark Andrea Brogi
----------------------
http://www.andreabrogi.it

MrPhilbert’s picture

Some people are real good at stating the obvious. The question was how to delete them. Not how to view them.
Any answers?

geerlingguy’s picture

Every now and then, I notice a rogue field that shows up in the field list, or still has database tables like "field_data_[field_name]" and a record in {field_config}, but don't have any instances, and aren't able to be deleted in the interface.

In these circumstances, you can safely delete the rows for the table manually in {field_config} and the two database tables for the field:

  • You know the field isn't being used in any Views or Content Types
  • There's a record in {field_config} and two tables for the field in the database (a 'data' field and a 'revisions' table).
  • There's NOT a record in {field_config_instance} for the field.

__________________
Personal site: www.jeffgeerling.com

drusims’s picture

Thank you for the accurate description of the verification process.

Is there by any chance a module who does that ? I mean this kind of stuff could be included in Devel or some other development module... If anyone has info about it, this post would be a great place to speak as this page appears a lot in Google search resultss

nachenko’s picture

Something similar happened here, only the field did not appear in field list report '/admin/reports/fields'. Someone had been messing with Features a bit too much, so we had a few orphan tables. {field_data_FIELD_NAME} and {field_revision_{FIELD_NAME}

In such cases, if the field does not appear in that report page, it means Drupal knows nothing about such field, and you can safely drop those orphan tables. You can do it using a db admin client, or you can do it using code, which is what we did: db_drop_table($table).

lukasss’s picture

subscribe

For world peace!

Bruno Vincent’s picture

How do I do that:

In these circumstances, you can safely delete the rows for the table manually in {field_config} and the two database tables for the field:

Is that PHPmy admin? Drush? Find and replace?

Can someone elaborate on how to do this?

vm’s picture

any work performed on the database can be accomplished in phpmyadmin

chowdah’s picture

When I deleted an old content type I node longer used, a single node of that content type remained in the db, so every time it was accessed, there was a field called 'field_data_field_activate_disclaimer' that would throw a table not found SQL error. Bots were constantly hitting the node - maybe on revisits to find out if the error was resolved, but the error was ever present in my drush watchdog logs and I could see things slow down to a crawl on the server when the node was accessed. Due to this, I did not want to just delete the field, because the errors were a sign of a larger issue with the DB.

The problem was the error would not allow me to delete, edit or otherwise manipulate the node. The error was telling me the node number, so I created a view that had fields for 'node title' and a 'bulk operations' field that would allow me to delete the node. I then filtered the view by node id and exposed the form to allow me to input the id of the node I wanted to delete.

Using the bulk operations page generated by the view, I tried to delete the node, but it threw the same error saying it couldn't find a table for the missing field in the DB. I used phpMyAdmin to add the table to the db with a 'dummy' column to hold data. I went back to delete the node, resulting in another sql because it found the table, but not the column. I had to repeat these steps until I rebuilt the table with all the correct columns.

I then discovered other missing tables through this process, and had to rebuild them the same way - through trial and error. The end result was that I was finally able to delete the node and ended up with a list of possible rogue fields that still were referenced in the DB based on the names of the missing tables. With due diligence i was able to 'clean' the DB of these references.

Anonymous’s picture

In response to the question as initially specifically stated, isn't the answer simply to manually run Cron?
I've just tested this.
I've created a field type for a node and saved it. The field exists.
After creating some content using that node type, I then went back to the configuration for that note type and deleted my just made field.
Immediately afterward, I went to the field list. It showed my deleted field as still existing.
I then went to the Configuration page and manually ran Cron.
I then went back to the fields list and saw that my deleted field was no longer listed there.
I then went back to the node and recreated the same field using the exact same name. No problems.

The same process (running Cron to fully delete a field) also works for when you have deleted a field and then want to uninstall a module that was associated with the field (but Drupal won't let you uncheck the module's box because it says data exists in that field).