On enabling or disabling modules, CCK appears to run some kind of clean-up process. This process decides that several of my content types and related tables are crud, and deletes them without confirmation or warning. This has now happened several times, and with different content types - the first time my site had no content and I recreated the types; this time the only clean solution was to delete and restore the entire database from an older backup.
The content types that are deleted are previously completely functional.
I'm still trying to find out what it is in the state of my database that triggers this destructive action during clean-up, and how to get it out of this state, but I would very much appreciate it if there was some confirmation check in the module before it drops whole tables or deletes my data... :/
Comments
Comment #1
karens commentedNeither the content module nor any of the core CCK field modules do anything when you disable them. This behavior must be coming from a contrib module. What module are you disabling when all this happens? That's the source of your trouble and you need to report an issue on that module's issue queue.
Comment #2
yched commentedEr. You say this happens after submitting the admin/build/modules page ?
(Side note : You probably mean 'cruft' instead of 'crud', right ?)
Comment #3
yched commentedCross-posted :-)
Comment #4
cburschkaApologies, I posted this while I was really confused and frustrated about what was going on. Some delving into the database and core node.module code revealed that
1. node.module rebuilds the content types when modules are disabled or enabled, in order to get rid of types that are no longer supported.
2. content types get deleted if their module is disabled.
3. If CCK was used to add any fields to a content type provided by another module, these fields will get deleted when the module is disabled.
The concrete problem in my case was a dependency issue that caused my custom module to get unexpectedly disabled, and its content types deleted.
However, I can see a pretty big problem here: Disabling (not uninstalling) a module will, more or less silently, delete a lot of data if CCK added custom fields to the content type of the other module. I may have misinterpreted the philosophy behind the module system, but I believed that disabling and re-enabling a module would not cause permanent deletion on that scale.
Perhaps content type customizations can remain in some kind of limbo or trashbin that lasts until the module is uninstalled or the content type is deleted manually? Perhaps this should be handled by the core node module instead of CCK, as it affects other customizations (like relabeling of content types, title and body fields) as well.
Comment #5
cburschkaPlease don't let this drop off the radar.
There's a reason disabling a module is different from uninstalling it. The former is not supposed to destroy your data.
If you disable a module that provides a content type, and you had used CCK to add additional fields to it, these fields and all content submitted in them are immediately and irreversibly destroyed. CCK is destroying user data without confirmation when modules are disabled. This is as if disabling a filter module would delete all text that was assigned this input format.
Keep in mind that even node.module itself isn't this destructive when deleting content types:
Nowhere does it say that any of the content will be deleted! Yet CCK will immediately drop all tables and data associated with the content type the moment it is deleted.
I'll move this to CCK, as it seems that it would be easier to fix there.
Comment #6
karens commentedThis is really the same issue as http://drupal.org/node/198508 -- how to handle inactive fields. It's a huge problem because without being able to access anything from the field module that created it, we're running blind and could easily do serious damage to the database.
The current solution is to mark those fields inactive and ignore them, but the problem is that CCK moves data from one table to another using whatever information it has about field structure and if some of that info is missing, it's quite hard to do the right thing.