Use vertical tabs on WYSIWYG profile form

Thanks for the patch, but I wonder if we shouldn't just set the #group property on the fieldsets instead of adding a parent to all elements. It's already pretty complex as is, and anyone altering the form would also have to move their alterations.
Core does this in user_admin_settings() for the email fields, which works since the vertical-tabs code looks for #group properties on non-child fieldsets as well.

Please note that we cannot put all fieldsets into vertical tabs. The vertical tabs user interface pattern is defined as follows:

- Vertical tabs must not be used for the primary form controls.

- Vertical tabs may only contain advanced options that the user may safely skip over and ignore entirely (assuming safe defaults).

In other words:

- There have to be primary form controls above the vertical tabs. (These should not be in fieldsets either, so that's a bug in the existing UI already.)

- Only advanced settings, for which the defaults are sane enough for the 80% use-case, can be moved into vertical tabs.

Most likely, we want to present the Buttons and plugins settings as the primary form controls.

Since 7.x-2.x is a stable release, we will have to do that in a backwards-compatible way; i.e.:

- Only adding a new #type vertical_tabs contianer on the top-level. Assign a #weight of 50, so the polluted vertical tabs container appears below the primary form controls.

- Change the #type of the Buttons and plugins 'fieldset' into 'container'.

Because all of that makes a shittonne of sense, let me quickly help you out there. ;)

That said, the button+plugins configuration looked a bit wonky without a wrapping fieldset, so I retained that but changed it to be not collapsible. We definitely need to improve that part of the interface... (separate issue)

I'd like to see an additional confirmation before commit, possibly by @TwoD.

Confirmed, this indeed makes sense and preserves a reasonable amount of backwards compatibility.

However, there's a small issue. Perhaps better suited as a follow-up to #696040: No way to cancel out of admin/settings/wysiwyg/profile/[profileID]/edit, but might as well bring it up here since the last change in this patch has no visible effect.

+++ b/wysiwyg.admin.incundefined
@@ -290,12 +293,18 @@ function wysiwyg_profile_form($form, &$form_state, $profile) {
-  $form['cancel'] = array(
+  $form['actions']['cancel'] = array(
     '#value' => l(t('Cancel'), 'admin/config/content/wysiwyg'),
     '#weight' => 110,

We should have changed #value to #markup in D7, or used the link element.

$form['actions']['cancel'] = array(
  '#type' => 'link',
  '#title' => t('Cancel'),
  '#href' => 'admin/config/content/wysiwyg',
  '#weight' => 110,
);

Sorry for dropping out btw, got sick...

Oh, well-spotted! :)

Thanks for reporting, reviewing, and testing! Committed and pushed.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

Sorry, forgot to amend: I quickly fixed that Cancel link glitch prior to commit. :)

Backported to 6.x-2.x.

Note: This does NOT introduce a dependency on Vertical Tabs for Wysiwyg 6.x, but it will be used if installed.