Message "Required by Drupal (Fields Pending Deletion)" baffles users

Thanks for reporting this!

Moving to 8.x (we fix bugs there and then backport if possible/necessary), and base system (this is in-code text).

Ditto for me. I have several modules I would like to disable, (Organic Groups and Reply), and after doing everything I can to delete the fields, I am confronted with this "Fields pending deletion" message, which prevents me from disabling the modules. Everywhere else I have read has recommended running cron, (sometimes multiple times), which will finally delete the fields and allow me to disable the module. I have run cron probably 50 times, and am still getting this message. Eventually I had to go in and delete all references to the fields through the database, taking my site down for several hours in the process because the references were located in so many different tables. This is extremely frustrating.

Cross-linking #943772: field_delete_field() and others fail for inactive fields where this was done.

+1 on having an extensive help text linked with this message.

What @NathanM describes in #2 does sound more like there is problem with the purging of field data which is independent from how this message should be phrased/explained in help texts.

I found this message very helpful, but it should really mention cron.

There should be a 'delete offending fields now' button, in addition to an 'run cron to delete them, if you want' button.

Also: #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed

improve issue summary

better Issue summary

Altered summary to add reference to code.

Crosslinking to #1264728: Refresh field 'active' state in module_enable() / _disable() which would mitigate that in "good" cases (fields with few values, e.g just evaluating a field type module and removing it)

The real fix would be a "purge everything now through batch API" button somewhere in the UI - probably on admin/reports/fields.
Not possible for me to work on this right now, but any takers welcome.

My problem is that it doesn't even tell you which fields to delete. I've removed the only instance of the field I remember creating. I ran cron a bunch. I guess I'll go dig into the field system to get a list of the fields and see what entity has another field of this type.

@drewish : the admin/reports/fields screen displays the module name in the "Field Type" column. You need to delete all the fields where the module is the one you want to disable.

This patch changes "Fields pending deletion" to "Fields pending deletion - run cron to delete the fields", with a link to the run cron page.

This doesn't work, however, when cron runs are not enough.
like in the media module, I had created one single field to try this module didn't work, now it is not possible to cleanly uninstall the module.
I have run cron 10 times now

The way should be to display the fields that are pending deletion and offer a way to erase them from the database without cron, but with a specific link. The first link to delete the fields was not very helpful it lets you guess which of the fields you need to delete... There should be the hook for the final deletion of those fields.

@triple5 there is a discussion going on at #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed that is related to this issue.

It's doubly frustrating that even once you do figure out that you can't disable/uninstall a module because you need to run cron to clean up your data, that even after you run cron, you still can't disable/uninstall the module. It *appears* as though running cron changed nothing, so makes you think that's not the solution, even when it is. You just need to do it N more times.

Hold on, can't cron batch? Why is it even necessary to run cron more than once? Can we fix that too?

Agreed - this message also leads to unfixable bug reports on various modules that make use of the Field API. Simply Google the message text to see some examples.

@jenlampton
In some situations there may be quite a bit of data to purge, so having it all purged in a single cron run might not be scalable (cron could sit there running for a long, long time).

I'm going to take a stab at something along the lines of #8, where we let deleted Field API data purge by way of small batches at cron run, but also offer a "Purge all deleted Field API data" option to those who want it gone now (utilizing the batch api).

If all goes well I'll follow up with a patch soon.

Here is a workaround:
https://drupal.org/node/1530812#comment-5865292

improve issue summary

rerolled.
should we also be adding the solution as described in #16 as well ?

Rerolled the patch in #17.

I leave the issue at needs work, because the tests needs to be fixed. At least FieldUninstallValidatorTest.php fails due to the use of Drupal::url.

This issue can be replicated on Drupal 8.2.4 with the following steps:

1. Install Drupal using the minimal profile.
2. Uninstall the node module.

As a result, the Text module can't be uninstalled because the body field from node is still pending deletion after the node module has been uninstalled.

There is no content on sites that were just created with the minimal profile.

Just a notice here although it may not be so relevant.

For 8.2.x I got a similar message (Required by ... (Fields Pending Deletion)) while trying to uninstall a module because there were Path aliases on the database. After deleting the path aliases I could uninstall the module.

Let's forget about messages telling the user to run cron, when that may not even work. The uninstall action should actually purge the fields as part of its run. By explicitly uninstalling a module, the user is saying, "I don't want anything to do with this module anymore." So it makes no sense to wait for cron. Do it now.

I just ran into this as well testing a module. Something needs to be done. The message

Fields pending deletion

although true, does not provide any helpful information to the user on how to solve the issue and actually complete the tasks at hand, uninstalling a module.

A message to run cron is not enough. It seems that I am finding information that the cron run only deletes 10 rows of data at a time. Because of this it may be necessary to run cron multiple times before all the fields pending deletion have been deleted. How many times the user does not know.

The fact that cron on sites is run at different time intervals and the number of fields pending deletion, have led to lots of posts of frustration that the system waits arbitrary amounts of time before deleting the fields and that running cron even multiple times does not delete them.

We need clarity in the error message that includes how to resolve the issue and a way that people can check if fields are queue for a pending deletion.

I might also add that it also baffles the users as to why the 'field_deleted_data_' tables are so long in the database after deleting fields. A better error message could help clear up that confusion too.

See: Fields 'field_deleted_data_' Tables appear in Database after Field Deletions

Added an explanation for why this 'error' is presented. It's not really an error.

Also added some more behavior to the solution: We should report what's up, with an accounting of how many records might be effected by deletion, and arbitrarily decide whether or not the user can go ahead and click a 'delete them now' link.

I must have run cron 50 times and still I'm stuck with Field Token Value. I think it's causing problems in Views and I really need to remove it. Any additional information would be most helpful.

I must have run cron 50 times and still I'm stuck with Field Token Value. I think it's causing problems in Views and I really need to remove it. Any additional information would be most helpful.

Is this fixed by #2884202: Non-persistent fields become unpurgeable zombies without their target entity type?

#2762381: Config entities removed in wrong order causes PDOException is also related.

Any reason why modules could not run batches during hook_uninstall() ? Sure, it doesn't include a "sandbox" batch tracker like hook_update_N() (wouldn't it be a good idea to add one ?), but does that preclude actually running a batch ?

to solve this issue tray to delete module folder manually after delete run crone many times it should solve.

Update for 8.6, should work on 8.7 (patch is same except index hashes)

How to force Drupal to clear out fields pending deletion:

drush php:eval 'field_purge_batch(50000);' 

You may need to provide an even bigger value. When this command returns quickly, uninstall will work.

This is still valid, the proposed patch seems OK except I'm not sure what hasContainer() is doing there, should it be checking permissions to run cron instead? Or that we're not in a CLI request?

I just ran into this, where I had to run Cron, in order to uninstall a module. I got this odd error message, even though the field was already deleted:

$ drush un field_token_value
In PmCommands.php line 203:
  field_token_value: Fields pending deletion

The updated message in the patch is a big improvement, immediately showing an actionable solution:

Field pending deletion: field_token_value. Running cron may delete the field.

The last patch or MR doesn't apply to the target branch, please reroll the code so that it can be reviewed by the automated testbot.

Not sure what additional changes are needed for 10.1