fields and data are deleted when a content-type module is disabled
joachim - August 8, 2008 - 14:36
| Project: | Content Construction Kit (CCK) |
| Version: | 5.x-1.7 |
| Component: | content.module |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Description
It should be safe to disable modules. Our documentation says that this is the correct procedure prior to module upgrades, etc.
But disabling a module that provides a content type - eg blog - deletes all its associated CCK tables, ie fields and their content get zapped.
This is a problem, as people following the documentation to perform an upgrade will lose data.
#1
Subscribe (<- lame)
#2
Subscribing.
#3
Blog module doesnt provide any content type - I assume you mean book ?
I need to check this on a D5 install.
#4
Blog module doesnt provide any content type
doh - of course it does... nevermind
#5
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...
#6
Folks who are interested in this should help with the patch at #253569: DX: Add hook_modules to act on other module status changes
#7
Committed that fix to both D5 and D6 branches.
#8
Um, does that fix this?
We do need to delete these content types & the CCK tables when a module is uninstalled.
#9
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.
#10
So we should leave this issue open and have it depend on an issue filed on core?
#11
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).
#12
So we should refile on D7? Or is CCK radically different there?
#13
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.
#14
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
#15
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.
#16
Automatically closed -- issue fixed for two weeks with no activity.