Comment form appering only with a title field if content type of that node is deleted

investigating this now (at the dev summit code sprint)

Sounds like a simple issue of cleanup when node types are deleted - i.e. all the variables like comment_*_ need to get removed.

On the other hand, I wonder if that's really a critical bug .. seems to me likely desirable as not, e.g. if I delete a node type and then recreate it, keeping these old settings as the new defaults seems as likely as the normal node defaults.

> Sounds like a simple issue of cleanup when node types are deleted - i.e. all the variables like comment_*_ need to get removed.

That is already taken care of in comment_node_type_delete().

This might be kind of a 'quick and dirty' solution, but this patch hides the comment form and comment links of the node type has been deleted.

> On the other hand, I wonder if that's really a critical bug .. seems to me likely desirable as not, e.g. if I delete a node type and then recreate it, keeping these old settings as the new defaults seems as likely as the normal node defaults.

I think expected behavior is that the settings related to that node type are completely cleared out. Although there are rare circumstances where you might want settings to persist in this situation, I think if you delete/recreate a node type the expectation is that you are getting rid of all the cruft and starting fresh.

Looks like that patch didn't attach correctly (it's showing 0 bytes for me)... do you mind giving it another go?

er... empty patches make the baby druplicon cry...

Retrying.

> this patch hides the comment form and comment links of the node type has been deleted.

Default behaviour is for comments to be allowed, so I reckon we should follow that.

The problem is probably down in FieldAPI, in field_attach_form().

I'm actually wondering if this is a larger issue than just the comment form. It would seem to me the intuitive result of deleting a node type is that content of that nodes type is deleted as well. Outside of potential performance issues (which could be circumvented with a batch) of deleting all of the content of the node type on delete, Is there something obvious I'm missing that causes us to keep this data around?

If I were to approach Drupal with fresh eyes, I would definitely expect that deleting the content type would just clear out the content of that type as well. The current approach in this patch 'works' for the comment form, but every module which hooks into that node type is going to have to implement something similar. It might not be a huge deal in the case of core, but to potentially have dozens of contributed modules doing this is is pretty dirty.

I've actually struggled a couple times when somebody deleted a content types leaving some orphan nodes behind; is there a particular reason for these nodes to stay in?

The issue is actually in 'comment_field_extra_fields' which calls node_type_get_types() in order to add the body field to the various types. When node_get_types loses the type the fields go away.

In the spirit of bjaspan and moshe's recent posts, i've downgraded this from critical to normal. It seems to me there is no consensus on a lot of expected behaviour when a node type is deleted, and none of the current behaviour classifies as a show stopper.

Actually, my bias is that it's not even a bug, but a feature, but I won't push that point of view.

In response to some of the last postings: leaving the nodes around when a node type is deleted is sometimes a good thing.

@hunvreus & @beeradb - I agree, deleting the nodes would solve a number of problems we've found (see also #400450: Be more graceful when editing nodes with disabled node types & #232327: Deleting node type leaves orphan nodes)

I think we should just delete that stuff.

Removing priority change from (assumed) crosspost.

I'm also tagging as needing a usability review. I'd like to get Bojhan or Roy's opinion on whether or not the content should be deleted from a usability perspective.

Let's not lose the focus on this.

This is not about deleting or not deleting nodes. This is about a broken comment form appearing -- I would say that is critical.

Yeah, having a real answer to what to do with type deletions would be great.

If we keep the content we probably need to have node_get_type_names (and all of the related functions) also check the db for types to keep this and other things from breaking.

(Sorry about the severity bump before, that was sloppy.)

Argh, that was posted while I was typing, bumping back to critical.

There's a good bit of crossover with #874000: Automatically remove module's nodes upon module uninstallation on this. I would argue that we should take the same approach whether the node type was created by Drupal core, or provided by another module.

The comment form is the 'critical' part of this, but I still feel like there's a meta-issue at play here.

I don't think this is a critical. If you delete the node type, hell breaks loose. That's always been the case and not something we need to protect against. If that is something we want to fix, we need to fix 12 other things that go wrong when you delete a node type.

Nevermind about my comment here

I posted a patch at #232327: Deleting node type leaves orphan nodes that prevents you from deleting a node type if there are nodes in the db, that could prevent this issue from arising.

This is related to #775878: Comment form body field disappears when content type deleted. any work here might apply.

I can reproduce this with any type of content and its NOT ONLY keeping comments BUT ALSO titles of all nodes. Apart from others I think THIS is critical from a editorials point of view! Deleted content types should lead to only ONE of 2 possible solutions:

- keeping content and moving it with fitting fields to another content type
- or deleting really ALL of the nodes, plus relating fields and subs

WHY? Because: what do I need empty content items with titles and comments for, after the decision to delete corresponding content type? If the content item still would be there completely, then ok. But who has the time to manage 150 empty items manually under content administration, because you CAN'T even filter them no more by type to edit them all together!)

I have opened another issue for this (http://drupal.org/node/1151540), because this is a general bug with database handling while deleting content types.

If we would fix this, it would definitely be fixed in 8.x first.

I dont see a recent screenshot or patch?

On Drupal 8.9.0, and using the steps to reproduce in the IS I was not able to reproduce this problem. I installed the standard profile and used devel to generate 50 nodes with comments. Then went to delete the article content type. The failed with

Article is used by 52 pieces of content on your site. You may not remove Article until you have removed all of the Article content.

. Then I deleted all the content of type article and when navigating to any of those nodes ids I got a page not found. All the comments were deleted as well.

I tested again on Drupal 7 and this problem exists in Drupal7, changing Version.