Vertical tabs cannot be disabled

Correct. There is no customization for it in D7 by design. Likely it would be provided by the vertical tabs module ported to D7.

Changing to feature request, setting active. There are plenty of cases where vertical tabs are undesirable.

Actually can you have an option to disable vertical tabs for authenticated users only?

I want vertical tabs to be enabled for admins.

Since normal users don't get all the other options which needs vertical tabs, some fields are being displayed incorrectly (pushed to the right side as if there's a virtual tab on the left) when they add or edit new nodes.

Subscribe. I would simply like a way to decide which fieldsets show up in the vertical tabs. Maybe there is already a way to do this but I haven't found one yet. I know with the Verticle Tabs module in D6 this option was available when editing content types.

Features are added in head first

For comment #7, if there are places where v-tabs are not displaying correctly then please file a bug against the CSS component for that issue.

#4 pleasae provide use-cases.

Use cases:
* I want to be able to order / group items that belong together (publishing and authored by, menu settings and pathauto, ...).
* I just don't like the ui of vertical tabs and prefer them in a left column (e.g. nodeformcols or panel forms or ds forms).

Good news: with http://drupal.org/project/rel field_group can turn the vertical tabs in e.g. fieldsets.

I don't think this should be marked "works as designed". Vertical tabs don't make sense (and look extremely awkward) if a user only has permission to edit the data contained within one vertical tab. Why use vertical tabs when there's only one vertical tab? e.g. http://i.imgur.com/iLHv9.png

I agree. This should not be "works as designed" as there are use cases where you may not want vertical tabs. If this is a "wont fix" item that's different, but seeing as there are people who want this feature I believe it should be an active issue.

If someone can explain a way to disable them then we can close this issue, but until then it should remain open. Maybe it could be marked as a lower priority item though.

The workaround in #3 worked for me.

Depending upon your needs you may need to move all of the fieldsets back out of the 'additional_options' array.

Node Form Columns was able to move the additional_options array into the sidebar.

I just found that:

$form['additional_settings']['#access'] = FALSE;

has, in effect, the same result as hiding the vertical tabs. Additional_settings includes all the settings in the vertical tabs, such as path, menu, etc. This assumes that you don't want to show any of the additional settings at all, you can also hide each setting/tab individually using a similar approach, e.g. $form['path']['#access'] = FALSE;.

For completeness, here is the code I have in my template.php file (I'm using a switch to only hide for a specific content type, you can remove to apply everywhere):

function themename_form_alter(&$form, $form_state, $form_id) {

  switch ($form_id) {
    case 'node_type_node_form': // just for 'node_type', remove if you want broader      
      $form['additional_settings']['#access'] = FALSE;
    break; 
  }

}

Thanks @RogerRogers!

Be sure not to allow for the forms you don't realize you are processing, too, or you might get an "Undefined index: #type" error after adding your hook_form_alter() to your template.php file.

For example, I got this error because I hadn't allowed for the basic 'search_block_form'. And, to "fix" this error, I changed the first line of my if statement to ignore that form_id (see code below).

function MYTHEMENAME_form_alter(&$form, $form_state, $form_id) {

    global $user;

    if ($form_id == 'search_block_form') {
        
    } else {
        if (in_array('anonymous user', $user->roles)) {
            $form['revision_information']['#access'] = FALSE;
        } else {
            $form['revision_information']['#access'] = TRUE;
        }
    }
}

Don't come up with crazy irrelevant tags please.

Otherwise, what #10 said.

#18, this is not an issue about vertical tags being broken (the reply in #10) but about being able to disable the vertical tabs altogether so developers can create a nicer user experience (in my opinion vertical tabs are not very good when it comes to UX and some use cases have been provided since then, #11, #12).

If you want to disable a specific vertical tab

function mymodule_form_alter(&$form, &$form_state, $form_id) {
  // node edit forms
  if (substr($form_id, -10) == '_node_form') {
    // un-tab publishing options
    unset($form['options']['#group']);
    $form['options']['#collapsible'] = FALSE;
    $form['options']['#collapsed'] = FALSE;
  }
}

I dont know whether this issue is still open but I have created a module for this.
http://drupal.org/project/node_vertical_tab_elements

This module aims for cleaning up node edit forms but only when panels are used to override node edit forms.

This modules provides for disabling some or all of the components of node edit vertical tab components
and also rearranging them to any position in the page.

thanks a lot RogerRogers! that worked just fine!

On #15
I know this solution but it is not working on server. What to do?

I'm new to drupal and vertical tabs is proving one of those 'breaking points' where I'm inclined to pack the whole thing in and suffer with a stupid Wordpress site instead.

I have installed the microblog module and have the form in a block on the sidebar.

I now want to activate the Book module, but when I do that what I now know as a "vertical tab" appears in the block, and it appears impossible to switch off.

It seems this was easier to manage in Drupal 6. With Drupal 7 it seems something has been added without adequate, accessible means for novice users for managing those new 'features'.

The standard solution it seems is to instal yet more modules to solve this, which in this case seem to be Renderable Elements https://drupal.org/project/rel and Field Group https://drupal.org/project/field_group. This will likely mean yet more bloat to my instal, and more learning curve with many more hours invested in overcoming the simplest step. I'm all for learning, but in Dupal it seems to be hours and hours for the simplest tweak.

Probably these modules will turn out to be awesome, and I guess that's the way 'learning Drupal' goes, but it is frustrating to do this to solve such simple problems that appear to be engineered in as 'features' without adequate scope for novice users to adjust the settings.

Drupal has many great things, but there is still the sense that building websites like this should remain the province of professional developers - keeping them employed and everyone else excluded. Supposedly the whole Drupal idea is to make this accessible, but I am not always sure this is really borne out.

if that is not solved on D8 we don't put it back to D7. and if you put it back to 7.x, set it to the dev version, not a fixed version.

Update re griping at #24:

Installed Renderable Elements https://drupal.org/project/rel and Field Group https://drupal.org/project/field_group.

Seemed to fix the problem in my case. You can deactivate these modules again and the fix seems to stay.

Only burned through half a day on this one :-) Now to the next problem https://drupal.org/node/87545.

Isn't this already fixed in d8 ? D8 is going to use a right column instead of the vertical tabs ?

By using

$form['additional_settings']['#access'] = FALSE;

It actually won't allow the status and options to save, instead I have to set all the tabs individually:

$form['revision_information']['#access'] = FALSE;
$form['author']['#access'] = FALSE;
$form['path']['#access'] = FALSE;
$form['options']['#access'] = FALSE;

There's a much simpler way to disable vertical tabs on a form, by simply changing the $form['additional_settings']['#type'] variable's value to 'fieldset' in an implementation of hook_form_alter() or hook_form_FORM_ID_alter(), if it's equal to 'vertical_tabs'.
You don't need to change the access settings or walk the whole array recursively, the latter consumes unnecessarily too much resources.

/**
 * Disable Vertical tabs on a form with simply changing the value of $form['additional_settings']['#type']
 * @see https:// drupal.org/node/1048644
 */
function form_disable_vertical_tabs(&$form){
  // originally $form['additional_settings']['#type'] equals to 'vertical_tabs'
  if(isset($form['additional_settings']['#type']) && ($form['additional_settings']['#type'] === 'vertical_tabs')){
    $form['additional_settings']['#type'] = 'fieldset';
  }
}

/**
 * Implements hook_form_alter().
 */
function MYMODULEORTHEMENAME_form_alter(&$form, &$form_state, $form_id) {

  if($form_id == 'my_form_id'){
    // disable vertical tabs for this form
    form_disable_vertical_tabs($form);
  }
}

That's all, of course, substitute MYMODULEORTHEMENAME to your own module's or theme's name (the latter in a template.php file), and my_form_id to your form's id.

You can also disable the vertical fields only for users who do NOT have the administrator role:

/**
 * Implements hook_form_alter().
 */
function MYMODULEORTHEMENAME_form_alter(&$form, &$form_state, $form_id) {

  global $user;
  $is_administrator = in_array('administrator', array_values($user->roles));
 
  if($form_id == 'my_form_id'){
    // if $user does NOT have the administrator role.
    if (!$is_administrator) {
      // disable vertical tabs for this form
      form_disable_vertical_tabs($form);
    }
  }
}

In case someone is interested, I attached a patch to Dripman's sandbox module: #2080739: Simplify the method of disabling Vertical tabs with just changing the $form['additional_settings']['#type'] to 'fieldset'.

I am working on this issue.

#30 worked for us. Thank you!

Our use case was with the Bootstrap base theme. The vertical tabs looked odd #1 and #2 the anchor scroll behavior didn't work with our custom sub-theme.

Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Since there's been no follow up and a feature request going to close out. If heavily desired to change think a simple contrib module could be written.