In case a module saves some additional data to an entity (e.g. some statistics) it needs to clean it up once those entities are deleted. Thus, when the entity-type providing module is uninstalled, it needs to remove all data related to those entities.

That would work if the module could rely upon being enabled, but it might be disabled when the module is uninstalled and so miss the hook invocation. That way, the user would end up with left-over data in the module's data tables.

For cleaning up field-data I think we could go with that approach, as we could require field API to be enabled if entities are. Thus, field API could delete all fields, instances and associated data of all fields that are associated with an entity-type or bundle of an uninstalled module.

For that to generally work though, we'd have to require that there are *no* disabled modules except the one uninstalled.

@fieldAPI:
Currently, field API requires one to call field_attach_delete_bundle() for each deleted bundle object, what doesn't play well with the overall used approach: We are not invoking deletion hooks for entities in case the providing module is uninstalled - that won't work as for loading an entity we need the module to be active.

Comments

Status:Active» Closed (duplicate)

I'm going to mark this as a duplicate of #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed, just seems like exactly the same issue trying to be solved.