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?


6 Answers 6


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, 2012 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, 2019 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.
    – apaderno
    Dec 16, 2016 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 May 28, 2015 at 17:27
  • drupal.org/node/1351506 this is still a known issue. Oct 14, 2016 at 8:43

If you run several times the drupal cron, drupal will delete the field tables and its content. You can follow the next steps for run several times the cron easily, but this steps can block your system, web or hosting, but you can do if you control your system.

  1. Go to Drupal status page (admin/reports/status).
  2. Down in the page, you can see something like "run cron manually" and a link like "run cron from outside" and a link with a cron_key parameter. Copy this link.
  3. Go to a terminal (linux or mac terminal).
  4. Write the next bash command:

    while true; do curl [put here the copied link, deleting the brackets]; done;

  5. Press enter. The command will be executed unlimited times.

  6. You can go your database, like phpmyadmin, and look for "delete" named tables. You can see how the rows are being deleting and go down. When all tables with "delete" in the name are empties, it will be dropped. When you can't see any deleted tables in the database you can go to the final 7 step.
  7. Stopped the bash command in the terminal. You can press ctrl + c keys. If you can't, close the terminal.

As I commented before, not is the best solution, but is simple, it work, you will not do anything wrong, because you are only running the drupal cron, so, you can break anything with some wrong php code. Otherwise, you can saturate the server, system, hosting or anything else in your web, because this steps run a lot of times the cron and this make web resources consumption, but if you have the control of the resources, there are no to much tables or rows to clean or you know is safe to do it for you system, you can do it.

And I know, it is not the best solution. But it work. Maybe it is the easy and best solution for your situation.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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