fields and data are deleted when a content-type module is disabled

Subscribe (<- lame)

Subscribing.

Blog module doesnt provide any content type - I assume you mean book ?
I need to check this on a D5 install.

Blog module doesnt provide any content type
doh - of course it does... nevermind

Right, this is no good.

When disabling modules, core does a node_types_rebuild(), which calls hook_node_type('delete') on node types that get disabled.
We can prevent that by adding :

  if (!empty($info->disabled)) {
    return;
  }

at the beginning of content_type_delete().

Problem is that this is the only chance we get to remove the data when a module is *uninstalled*. We only get notified of 'disable', not of 'uninstall'.

Well, I don't see any other fix for now, and stale tables is always best than destroyed data...

Folks who are interested in this should help with the patch at #253569: DX: Add hook_modules to act on other module status changes

Committed that fix to both D5 and D6 branches.

See #5, core doesn't provide any information about when a module is uninstalled, so there is no way to react to that. Because we don't want to delete data on disable-only, we are left with no alternative but to leave the data there. You'll have to delete it manually if you want it permanently removed.

I don't know of any way around this.

I seriously doubt core is going to do anything about this in D5 when the same behavior still exists in D7, so I see no point in leaving this as an open issue.

It would be a great core issue to file to get a fix into D7, but I think CCK has done as much as it can with this for D5 or D6, unless a core fix for D7 is committed and backported (which seems unlikely).

You need to file a core issue before anything else can happen. And yes, CCK will be radically different in D7 -- there will be fields in core by then, at least the beginnings of it.

About the issue with stale data that we cannot actually delete when a module is uninstalled :
Maybe we could form_alter our own submit handler into core's uninstall form - we still wouldn't catch modules uninstalled through drush or equivalent, though.

As moshe pointed, the real fix probably lies in #253569: DX: Add hook_modules to act on other module status changes

The other thing to do would be to provide a cleanup function with a button somewhere in the admin area that could be clicked to manually remove all traces of a module. That would provide a method without any automation, but that might be enough.