I have created fields deleted them. Tables for the fields are gone upon deletion, but they are still in field_config and field_config_instance

Is there anyway to clean them?



The entries in field_config and field_config_instance will probably have had a value of 1 in the deleted column.

This means they're marked for deletion, but won't actually be deleted until you run cron (deleted field data is purged in field_cron()).

  • you are the man. I didn't have phpmyadmin installed, so I didn't check other columns for those two tables through ssh connection. thanks Clive – lusketeer Jul 27 '12 at 20:18

using drush:

$ drush eval "field_purge_batch(500)"

you might have to run a few times, or increase the $batch_size then there might still be field_deleted and field_deleted_revision tables, even after running cron


SELECT * FROM `field_config` WHERE `deleted` = 1
SELECT * FROM `field_config_instance` WHERE `deleted` = 1

if you come up empty, you can safely delete those leftover tables

  • This is a great answer, thanks @decibel.places! – joelpittet May 19 '19 at 21:47

As an alternative to running cron to remove deleted data, you can manually run field_purge_batch($batch_size).

To manually run the function you can either:

  • Bootstrap Drupal in a php file
  • Create a menu hook page callback
  • If you have the devel module installed visit /devel/php

The $batch_size to use will vary depending on your server environment and needs. I've used values as low a 5 and as high as 10000.


For those Drupal 8 users,

I experienced this also, dig down the code. I found this all reason why fields not deleted after you did, the following:

  • executing cron gazillion times
  • run drush eval "field_purge_batch(500)" million times

The fields are persist not going away, this due to a piece of logic in here, in field_purge_batch

  // We cannot purge anything if the entity type is unknown (e.g. the
  // providing module was uninstalled).
  // @todo Revisit after https://www.drupal.org/node/2080823.
  if (!isset($info[$entity_type])) {

The modules which is the dependent, is uninstalled. that is the reason why the fields are not removed.

How to solve this? It is recommended approach to reinstall the module first and purge those fields and uninstall back. To find out which module you need to reinstall:

$fields = entity_load_multiple_by_properties('field_config', array(
  'deleted' => TRUE,
  'include_deleted' => TRUE,
dpm($fields); // this is devel module of var_dump

// check the protected member called "dependencies"

In case you dont want to go that approach of reinstall the module, you can also do right away delete, I am not sure what is the behaviour but it should do the job.

Backup first!!!

Yes, dont be lazy, it will save your ass, if something goes wrong.

$fields = entity_load_multiple_by_properties('field_config', array(
  'deleted' => TRUE,
  'include_deleted' => TRUE,

foreach ($fields as $field) {

// Retrieve all deleted field storages. Any that have no fields can be purged.
$deleted_storages = \Drupal::state()->get('field.storage.deleted') ? : array();
foreach ($deleted_storages as $field_storage) {
  $field_storage = new FieldStorageConfig($field_storage);
  $fields = entity_load_multiple_by_properties('field_config', array('field_storage_uuid' => $field_storage->uuid(), 'include_deleted' => TRUE));
  if (empty($fields)) {

Do the cron for the last time. I hope it will fix the issue :)

  • Welcome to Drupal Answers! Please don't copy-paste the same answer for multiple questions. If they are duplicates, flag them as duplicates. – kiamlaluno Dec 16 '16 at 9:19

Can't seem to find any solution. So I ended up deleting them from those two tables manually.

  • This just happened to me too: created fields in production, copied it to the test system. Reverted the fields in production, copied to the test system again. Cron has probably run in the meantime, thus since the test database was not properly dropped/recreated, the two leftover tables for data and revisions kept around... Findings: * always run cron BEFORE taking a backup * when importing to a test database, always drop&create – Beat Christen May 28 '15 at 17:27
  • drupal.org/node/1351506 this is still a known issue. – Kevin Morse Oct 14 '16 at 8:43

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.