[UX] Solve the "Fields pending deletion" problem

[jenlampton]

In Drupal 7, after you delete a field from a content type, you are prevented from uninstalling the module that provided that field for some arbitrary period of time.

When you return to the modules page, that module is disabled, and stays that it's "required by Drupal" and the reason is "Fields pending deletion".

As it turns out, you can cause the fields to be deleted by running cron... an arbitrary number of times - even if there are no values in the field (it never works the first time, don't ask me why).

It would be nice if we could find a way to delete the fields when the user hits the "confirm" button on the confirm form after deleting the field. Or, if we do need a batch process to run, run it the first time cron is initiated after the field has been deleted.

This is a painful end-user WTF, and we should find a better solution to the field deletion problem.

[bojanz]

This hack was introduced to work around one of the many issues of disabled modules.
You need to remove the concept of disabled modules first, before doing this change.
Otherwise you mustn't allow the module to be disabled until the purge happens, and if you purged the data, you've basically uninstalled the module anyway.
Perhaps you can do it halfway and just have some modules go straight to uninstall, but that's an even worse UX inconsistency (plus, you'd need to insure that uninstall works on active modules, which would be tricky)

Also note that this behavior doesn't happen for modules that provide fields, but for modules that provide field types that have fields of those types created.

[SoLoGHoST]

This does not work for me. I have installed the Field Formatter Module, used it once, I think in a Field Collection. Deleted the Field Collection and now I can NOT Remove this damn module. I ran Cron a million times. Even tried removing the directory field_formatter_settings and ran Cron again, a thousand times, put the folder back and it still does not work.

[quicksketch]

Hi @SoLoGHoST, I think if you're having this problem on an existing site, the best place to get help would be from the module's issue queue: https://drupal.org/project/issues/field_formatter_settings. This project (Backdrop) is for a new fork of Drupal that hasn't yet been released. Though you're reaffirming exactly what @jenlampton has pointed out: this is a really annoying problem for end-users.

[ghost]

This blog article may be helpful: http://www.bluespark.com/blog/uninstalling-and-purging-field-modules-all-once
The code it suggests seems to do everything needed at once (rather than waiting an arbitrary period of time).

[quicksketch]

Yeah, I'd love to see a Batch API process for both module uninstall and field deletion. This would probably mean converting hook_uninstall() from just a dumb hook to being one that had a $sandbox parameter, just like a hook_update(). Likewise, field deletion should become a batch operation instead of a simple form submit.

[jenlampton]

please please please I would love love love it if someone were to work on this! I hate this about D7 and want people not to have to suffer in this way in backdrop-land :) major kudos to anyone who works on it!

[quicksketch]

We fixed some issues with field deletion in the conversion to CMI:

• If a field is empty of data, it actually gets deleted immediately now.
• Cron jobs now delete 200 (instead of 10) rows of data at a time.
• After data is empty in a cron job, the field is deleted immediately instead of needing another cron job to delete the field.

This should mitigate the not-deleted-field problem significantly, but we still have work to do here to truly always delete the field immediately via a batch operation.

[jenlampton]

The remaining work to be done is to batch the operation so that it all gets done in the first pass.