Node types aren't going away when module disabled

Yes, I see this too.

checking the DB: {node_type} still contains type blog after the module is disabled
however, node_type.module == 'blog', so it seems like it shouldn't go in the menu at least, based on the code in node_menu()

node_menu() checks:

function_exists($type->module .'_form')

and this is the *same* check used by function node_overview_types(). In this latter case, blog doesn't show up after being disabled.

at least with my patched menu system, the menu entry goes away when I do another menu_rebuild(). This suggests something problematic about when the menu_rebuild is happening. ALos, seems like 'blog' should be deleted form the table?

http://api.drupal.org/api/HEAD/function/_node_types_build

should probably delete form the table disabled node types?

Related: http://drupal.org/node/92329

Yes, that looks related. A big part of the problem is that node module isn't tracking which actual module is declaring a node type. It just has the (badly mis-named) 'module' field which should really be called 'base' or 'prefix' or something else.

As far as the menu part, the fundamental problem still seems to be that node_get_types returns 'blog' in the list and the function blog_form() still exists in memory. Since the 'base' could just as well be zzz_ as blog_, there is no way to fix this in the menu system.

Another part of the problem- hook_disable() is only called for the specific module being disabled. I guess a #submit function could be added to the module form??? That's a little ugly however....

The easiest way to fix this (though not the best) - implement hook_disable for each node-type module.

Attached patch for blog

patch for forum and poll (note I don't know how to get all 3 in one patch since blog.install doesn't exist)

Peter - see http://drupal.org/patch/create under "Adding/Deleting files".

Thanks!

Anyone? Either we need a simple fix like this (manually remove), or someone needs to take on a more thoroough re-write before the code freeze.

What about this : in node_types_rebuild(), check the modules do exist and remove the record in {node_type} is not.

Attached patch does that

let me start again : in node_types_rebuild(), check the modules do exist and remove the record in {node_type} *if* not.

can't work - the 'module' field is badly mis-named (should be named 'hook' or something else). It does *NOT* have any correspondance to the actual name of the module. That's why this is so frustrating!

What this really requires is a broader patch to add a real 'module' field to the table, rename the current one to 'hook' (or 'base' or some such), and change the logic so that the module declaring a node type is recorded in the table. Please! or look at my simpler patch, which rather requires each node-type module to do it manually.

What happens to existing nodes if their node type is deleted?

typically if the node type goes away, not much of the node is displayed - maybe the title and body. Also, you may not even be able to edit even these if the module is disabled since hook_form is gone. Try - it!

actually, I'm looking at this again now - the fundamental problem is that when we disable a module, hook_form is still in memory. So, maybe we can use $info_array to fix this by checking for . See attached patch - I'm so happy it seems to work!

Actual code changes are ~7 lines - the rest is changed indentation.

to test, enable then disable a node module like Forum.

without the patch, Forum is still listed ad node/add

you can also go, for example, to admin/content/taxonomy/add/vocabulary
without the patch the content type (forum) is listed even though the module has been disabled

Patch applies cleanly and works as intended for me: After enabling and disabling blog.module, the content type shows up in admin/content/taxonomy/add/vocabulary, but disappears on applying the patch.

(Haven't looked at the code itself)

Works as expected, code is clean.
A word of comment might be useful about the if ($type_object->module != 'node' part ?
Marking as 'needs work' for that, otherwise it looks RTBC to me.

er, "Marking as 'needs work' for that"...

Updated both the doxygen and code comments to improve the explanation.

.. which actually make _node_types_build() function clearer than it was before the patch :-)

Committed. Nothing to add. Great job.

This could be worth backporting I guess ?

yes, a version of this should certainly be backported to 5.x

since the menu part of disabled content types seems to work ok in 5.x as is, this patch is identical to the above minus the node_menu piece.

Again, you can look on a taxonomy vocabulary page, as an example of where a disable node type still appears.

Committed to 5.x.

This patch introduced a bug (see http://drupal.org/node/169049). Now all (module-defined) content types, that do not implement hook_form, are listed under node/add. But they are hidden (as expected) in the content type administration pages (admin/content/types).