Relocate or delete topics on forum deletion to avoid leaving stale data in database.

I agree. The delete would be quite difficult esp that if there is a shadow copy then it does not need to be deleted... Also it's not entirely impossible that there are other navigation means leading to said nodes (you can tag them for eg) so deleting might not be desired at all.

I can't roll a patch right now, unfortunately, but there is a double space between sentences in this string (and is it missing a comma near "if any")?

Agreed that we'd rather document this good now, and revisit this in D7. Even if this is a string change for translators, oh well. Committed this one.

I committed the help text fixes to D7. I'm not sure this is critical so lowering the priority to 'normal'.

There is no good or wrong here -- the solution will be non-trivial if we want to take into account all the use cases. Posts can belong to multiple forums (or multiple taxonomy terms), different node types can be in a forum, etc. We can investigate this more, but I'm tempted to suggest that we should focus our efforts on the mass node administration pages. They already allow complex filtering and mass-deletion. There is room for improvement there that might make this particular issue easier to deal with as well. Food for thought, huh.

Related issue: http://drupal.org/node/90202

I don't understand, #0 claims that deleting a forum does not delete the associated nodes.
#90202: Tests for deleting forums and http://api.drupal.org/api/function/forum_taxonomy indicate otherwise!

wait a minute... moved topics get deleted... and non-moved topics doesn't get deleted... does someone sees a pattern there???

The issue here is not about the fact that forum topics persist after their forum or container is deleted. The issue is how do we handled these orphaned nodes.

The choices are summed up well in #16:

1) Delete a forum, with no posts
2) Delete a forum, with posts, no other forums exist
3) Delete a forum, with posts, other forums exist

1) No change need. Forum is deleted without a problem.
2) Confirm with user that posts will be deleted too. There shouldn't be an alternative like moving them to another forum, they're deleting the only forum and making a new one would be synonymous with just editting the original one.
3) Give the user the choice to either delete the posts or move them to a forum of their choosing.

Do these approaches sound reasonable?

This patch creates a forum overview area in the delete forum confirmation form to give admins a chance to move topics in the forum they're going to delete. It also affects forum deletion so that all topics in that forum are deleted along with the forum so topics are not orphaned without a forum; that seems to be the normal and expected behaviour.

Looking at in from the 3 scenarios from #16:

1. Deleting a forum with no posts doesn't really change.
2. Deleting a forum with posts, where no other forums exist, displays a table of topics that will be deleted along with the forum; admins can't move it anywhere since there is no forum to which these topics can be moved.
3. Deleting a forum with posts, where other forums do exist, displays the same table of topics and provides checkboxes and a move section to allow admins to move topics to other forums before deleting.

There is still some work to be done:

• The patch doesn't support nested forums and containers yet. Deleting containers and forums will delete topics of these forums and sub-forums, but not the topics in these sub-forums.
• It also doesn't detect topics in these sub-forums so they can be moved. The patch also incorrectly allows topics to be moved into containers, which are only allowed to contain forums (not topics).

The patch is accompanied by screenshots. There's a before shot, and after shots for the 3 scenarios.

stupid bot.

naughty pifr bot again

Just want to point to another forums problem that might be connected with this (it is marked duplicate because of the underlying taxonomy issues). Maybe this can/has to be solved in one wash because deleting forums often includes deleting the vocabulary and that results in such mishaps.

#24274: Accidentally Deleting Forums Vocabulary in Categories Breaks Forums?

I am currently struggling with this in D6 and this is definitely a critical showstopper for noobs.

If this is not connected or already dealt with please don't hit me.

Thanks for bringing up the other issue. I'll have to find some time to look into it. At a glance, I don't think #24274 is related to this issue, although they both affect forum administration.

@dddave, just to clarify, are you currently struggling with this issue (#206820) or the one you mentioned (#24274)?

I was apprehensive about my patch in #23 as it changes the way forums and containers are removed, but I think it's for the better. Someone, or - preferably - some people, need to review it.

If we get a green light, I'll backport the patch to 6.x.

Sorry for the ambigious formulation. I am struggling with (#24274).
I posted it here http://drupal.org/node/509604, got some valuable input from Michelle and I am going to try two solutions I found during my resarch (any progress will be posted there so I don't polute this issue here). Anyways, if "my" issue still exists (that means I didn't mess it up myself) it should definitly be solved in D7 as it is a brick wall for inexperienced users.

Good luck with the problem at hand.

I had the exact same problem these days (forum posts without assigned forum). However, I fear that it's too late to rush in such a large change into D7.

Bugs cannot target D8, as the tree is not open yet.

OK, I think we can safely move this the D7 tree now.

Re-rolled patch in #23 for current 8.x checkout, and fixed some problems identified by coder.

Also, better title, I think.

The original bug was fixed in #13. Back then, a new issue should have been created for the remaining feature request. But anyway, let's move on here.

+++ b/modules/forum/forum.admin.inc
@@ -182,26 +182,213 @@ function forum_form_container($form, &$form_state, $edit = array()) {
+  $question = t('Are you sure you want to delete the forum %name?', array('%name' => $term->name));
+  $description = format_plural(count($topics), 'This forum contains 1 topic. Deleting a forum or container will also delete its sub-forums and topics. This action cannot be undone.', 'This forum contains @count topics. Deleting a forum or container will also delete its sub-forums and topics. This action cannot be undone.');
+  $yes = t('Delete');
+  $cancel = l(t('Cancel'), 'admin/build/forum');
+
+  drupal_set_title($question, PASS_THROUGH);
...
+  $form['description'] = array('#markup' => $description);
...
-  return confirm_form($form, t('Are you sure you want to delete the forum %name?', array('%name' => $term->name)), 'admin/structure/forum', t('Deleting a forum or container will also delete its sub-forums, if any. To delete posts in this forum, visit <a href="@content">content administration</a> first. This action cannot be undone.', array('@content' => url('admin/content'))), t('Delete'), t('Cancel'));
...
+  $form['actions'] = array('#prefix' => '<div class="container-inline">', '#suffix' => '</div>');
+  $form['actions']['submit'] = array('#type' => 'submit', '#value' => $yes ? $yes : t('Confirm'));
+  $form['actions']['cancel'] = array('#markup' => $cancel);
+  $form['#theme'] = 'forum_confirm_delete';

I don't see why confirm_form() needs to be entirely re-implemented here. Simply call

$form = confirm_form($form, ...);

and work off the result. This is the form constructor that owns the form, so it is perfectly valid to call the generic helper to get 90% done and revert/adjust/tweak the remaining to its liking.

That said, note that in D7, confirm_form() only sets #theme if it isn't set already. Thus, set it before calling it.

+++ b/modules/forum/forum.admin.inc
@@ -182,26 +182,213 @@ function forum_form_container($form, &$form_state, $edit = array()) {
+    $multilanguage = (module_exists('translation') || db_query("SELECT COUNT(*) FROM {node} WHERE language <> ''")->fetchField());

Should be

db_query_range('SELECT 1 FROM {node} ...', 0, 1)->fetchField();

+++ b/modules/forum/forum.admin.inc
@@ -182,26 +182,213 @@ function forum_form_container($form, &$form_state, $edit = array()) {
+    if (isset($topic->forum_tid) && $topic->forum_tid!= $tid)
+      unset($topics[$nid]);

Coding standards violation.

+++ b/modules/forum/forum.admin.inc
@@ -182,26 +182,213 @@ function forum_form_container($form, &$form_state, $edit = array()) {
+    print_r($topics);
+    print_r($term_dst);
...
+    print_r($topics);

debugging code.

+++ b/modules/forum/forum.admin.inc
@@ -182,26 +182,213 @@ function forum_form_container($form, &$form_state, $edit = array()) {
+function theme_forum_confirm_delete($form) {

D6-style theme function.

+++ b/modules/forum/forum.module
@@ -80,6 +80,10 @@ function forum_theme() {
+    'forum_confirm_delete' => array(
+      'arguments' => array('form' => NULL),

Should use 'render element' instead of 'variables' (again, D6 style here).

+++ b/modules/forum/forum.module
@@ -995,7 +999,7 @@ function template_preprocess_forums(&$variables) {
-  drupal_set_title($title);
+  drupal_set_title(check_plain($title));

Bogus, please revert.

Powered by Dreditor.

Re-rolled with most of the suggested changes, but someone else is going to have to take over maintenance of this patch because I'm frankly out of my depth and don't use forums anyway.

• Simply call $form = confirm_form($form, ...); and work off the result.

  Only partially done.

• +++ b/modules/forum/forum.admin.inc
  @@ -182,26 +182,213 @@ function forum_form_container($form, &$form_state, $edit = array()) {
  +function theme_forum_confirm_delete($form) {

  D6-style theme function.

  Not done.

Naming patch file to avoid re-test and leaving at "needs work" because it does.

I'm attaching a patch for D7. It's mostly a re-roll of the one in #41, but I had several errors when I applied it (or #23) to a D7 site. I'm also attaching an interdiff between the two, but I had a little trouble applying the patch, and had to apply it manually, so the interdiff might not be perfect.

I'll try to work on a D8 version soon.

There were a few issues I saw with the previous patch.

• Pager isn't actually used
• Even when I changed to use the pager, it doesn't make sense in context of delete confirmation because the confirmation form is at the same url as the edit form, and only visible due to the form (POST) state. As soon as you click a link you have left the delete confirmation form. I suggest moving confirmation form to a new page callback.
• There is still nothing to delete topics that aren't moved. I suggest it should delete topics in a batch process.
• When there are no other forums the table doesn't have the right number of columns in the rows
• The select all checkbox in the header is missing

The attached patch should address all those things.

EDIT: Attached patch is for D7

Same applies to forum data on uninstall #2224581: Delete forum data on uninstall

Forum is approved for removal. See #1898812: [policy] Deprecate forum module for removal in Drupal 11

This is now Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.

It will be moved to the contributed extension once the Drupal 11 branch is open.

I think this is outdated but