Core uninstalls shall clean up node and node_type table and recalculate node_comment_statistics

Moved to project queue

This appears to be a valid bug, the entries for node types are not being removed from the node_type table after disabling and uninstalling any of blog.module, book.module, forum.module, and poll.module.

Duplicate of: http://drupal.org/node/93400

First, untested attempt.

About the mysql requirement -- we thought we will rise the requirement to 4.0 already, just we have not found any use for it. Now we do. Given the recent agreement using 4.1 in Drupal 6 and the surrounding posts, I can't remember anyone posting 'but hey we are at 3.x still'.

It's a patch. Frightening it might be, but still: a patch.

i think this code is too infrequently run to merit raising the mysql version requirement.

One could rearrange the code so that mysql 4.1+ and pgsql runs subqueries , mysql 4.0 runs the multitable delete and I leave mysql 3.x for the next patcher.

I'm guessing ac was using mysql 3.

A loop would be more code, but work all the time and consistently across database versions. Maybe it would take too long to execute if there are too many nodes.

This code is just too rough to commit. Either it should work on the versions of MySQL we support, or handle not working on MySQL 3 with a better error. I didn't notice a clear indication that it was okay to drop MySQL 3 support for Drupal 5.

Either clean it up or postpone for 6.

Cleaned up and synced with HEAD. The initial patch had forum.module incorrectly remove the poll type. This version also adds blog_uninstall() and fixes the sql error, which was because the table name is node_revisions, not node_revision.

This shouldn't change Drupal's required MySQL version.

I'm still concerned by the idea of deleting nodes when a module is uninstalled. I just went through the following process on a client's site:

1. Set up forums
2. Get new requirements from client, realize forum.module won't cut it
3. Disable forum.module, create new 'forum' content type and use views/etc to add custom behaviors
4. Be happy

If uninstalling the module deletes all nodes of that type, then there is a ticking time bomb waiting on the 'uninstall' screen: if the client ever decides to click that button, since forum.module isn't being used, it will immediately delete all of their site's forum posts.

@eaton - thats just a bug. forum uninstall should assure that it owns the node type = 'forum' before deleting such nodes. just a simple if() will do.

Subscribing.

It should not only check if it owns the nodes / content in question, but there should be a prompt to ask the user if he wants to delete the content. What if I want to disable forum.module for a week?

@fireangel - uninstall is different from diable. what you describe is disable. uninstall specifically is there so that modules can do this sort if cleanup. uninstall is destructive by design. there are lots of warnings during the process.

Thanks for the clarification moshe. I think Eaton's comment misled me into thinking that it would also delete the associated content ;)

Whatever happened to this? I'm developing a module that depends on correct info in the node_type table and I'm finding it isn't. Is there a patch for Drupal 5.1 available? Also, if I can add my two cents worth... it seems to me that Drupal core should be handling the deletion of content type info (at least from 'node_type' and possibly also 'content_type_XXX') when a module is uninstalled since modules don't seem to interject themselves there in the first place. Can anyone tell me what's going on?

Thanks.

This should probably be fixed is system module- but I posted a patch here that's a minimal fix: http://drupal.org/node/147061

Why is the MySQL min version changed?

We should also tell the user WITH A BIG ANGRY MESSAGE that he is deleting all nodes of this type.

Reroll and I'll review :)

is this issue in current 6.x? Is any one interested in pursuing it any more?

@dpearceMN, #29:

Yes, it is still. Just uninstalled forum.module in 6.22. It left alle forum nodes and their comments untouched, but also removed the node_type info. So the abandoned nodes are now of the type "" in the frontend and "forum" in the database. Even worse, when trying to edit such an abandoned node, you will receive:

warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'forum_node_form' was given in X:\Internet\Server\test\drupal-6.22\includes\form.inc on line 377.

This is really bad behavior IMO. At a glance, I can see several solution options for that:

1. Delete the node types on uninstall. (Rough!)
2. Delete the node types on uninstall and clearly warn. (Also rough but "ayor" then)
3. Delete the node types on uninstall but create an export function for later reuse (->import function) AND prompt to consider this export . (More convenient, more coding, user friendly, consistent.)
4. Offer a choice on uninstall whether to
   • delete all module related nodes
   • or offer the option to turn them into an existing node type (although this can be done with some contrib module I do not remember atm, this would refer to solution 2 then)
5. generally reconsider having an undeletable generic node type that catches all abandoned module nodes as long as no module takes care of them again (IMO the best, as well as the most code expensive option. It would mean doing basic changes to branches that already have successors, on the other hand, at least as for D6, just remember how many people still stick to Windows XP for good reasons ;))

Maybe we can have some opinions on this. At least for D6, I would even contribute myself, but I have to admit that I am not even having full project access as by now (pending). Which, of course, wouldn't keep me from proposing some patches in case there is a demand.

Perhaps I am thinking wrong here and all that may be solved with a contrib module. I would be interested in further opinions.

(Unfollowing)