Convert confirm_form() in forum.admin.inc to the new form interface

so this
a) converts the confirm form to use ConfirmFormBase/FormInterface
b) Ditches the old $_POST foo for the delete operation (welcome to Drupal 5 forum module, this is form api, form api this is forum).
c) adds a new route for the delete callback (yes there is no path for it at the moment, it is just tied up in some funky $_POST variables)
d) moves the save submit handler on the edit form to the button instead of the form
e) removes the ?destination= hardcoded in the edit form (this might be an issue for taxonomy conversions too), unless they use drupal_goto (which is smelly)
f) adds some more tests for this
g) drops the 'Add container' 'Add forum' local tasks on the delete form (and adds tests for that).

Awesome!!!
g) seems a bit tricky :)

#2: forum-confirm-1946414.1.patch queued for re-testing.

+++ b/core/modules/forum/forum.admin.inc
@@ -189,45 +196,28 @@ function forum_form_container($form, &$form_state, $edit = array()) {
+function forum_forum_delete($form, &$form_state) {
+  $form_state['redirect'] = 'admin/structure/forum/delete/forum/' . $form_state['values']['tid'];

Why is this still a function and not a method?

@Crell this issue is to deal with the confirm_form(), that will be fixed in #1951278: Create taxonomy term form controller for forum terms (ie not default) and use that for admin/structure/forum/edit/{forum|contain

This is blocking #1951278: Create taxonomy term form controller for forum terms (ie not default) and use that for admin/structure/forum/edit/{forum|contain

Chasing HEAD

Patch 8 had hunk from another issue

This is only blocking a normal task, so downgrading to normal. I'll try and look at this over the weekend.

The changes to forum_form_main() look a little odd in the patch, but make sense when you apply it and read it.
The rest of it is pretty straightforward.

+++ b/core/modules/forum/forum.admin.incundefined
@@ -73,12 +70,22 @@ function forum_form_forum($form, &$form_state, $edit = array()) {
-  $form['#submit'][] = 'forum_form_submit';
+  // Ensure that forum_form_submit() doesn't run for both buttons.
+  $form['#submit'] = array();

Can we not just not set $form['#submit'] as you've done in forum_form_container()?

+++ b/core/modules/forum/forum.admin.incundefined
@@ -189,45 +196,28 @@ function forum_form_container($form, &$form_state, $edit = array()) {
+ * Handler for when 'delete' is clicked

No fullstop and could do with @see \Drupal\forum\Form\DeleteForm

+++ b/core/modules/forum/lib/Drupal/forum/Form/DeleteForm.phpundefined
@@ -0,0 +1,72 @@
+   * Implements \Drupal\Core\Form\FormInterface::getFormID().
...
+   * Implements \Drupal\Core\Form\ConfirmFormBase::getQuestion().
...
+   * Implements \Drupal\Core\Form\ConfirmFormBase::getCancelPath().
...
+   * Overrides \Drupal\Core\Form\ConfirmFormBase::getConfirmText().
...
+   * Overrides \Drupal\Core\Form\ConfirmFormBase::buildForm().
...
+   * Implements \Drupal\Core\Form\FormInterface::submitForm().

These can all be changed to {@inheritdoc} - see http://drupal.org/coding-standards/docs#inheritdoc

Can we not just not set $form['#submit'] as you've done in forum_form_container()?

For some reason I thought the form id and the submit handler lined up (If $form['#submit'] is not set, Drupal will automatically add {form_id}_submit as the submit handler - Forcing it to an empty array avoids this behaviour). But in this case the form id is forum_form_forum() and the submit handler is forum_form_submit(). Fixed.

These can all be changed to {@inheritdoc}

Hopefully phpcs can sniff for these, currently the new format throws warnings when I run the coding standards.
All other issues fixed.

Ah, that's an improvement. Thanks!

Committed 8743406 and pushed to 8.x. Thanks!