tags:

views:

33

answers:

2

Similar to the question posting form on SO, Drupal adds a draggable expander to the bottom of textareas created through the form api. How can I disable this in a nice manner?

+4  A: 

The draggable expander gets added via the behavior defined in 'misc/textearea.js'. From that you can see that it applies to textareas having a class 'resizable'. You can prevent the output of this class if you set the '#resizable' property on a textareas FAPI definition to FALSE (it defaults to TRUE if not explicitly set).

So for your own forms, you can just declare the textareas accordingly. For other forms, youD need to adjust them via hook_form_alter().

Henrik Opel
Ahh thanks! I looked through the form api several times but couldn't see that. I was looking for `#expandable`!
Finbarr
+1  A: 

The simplest, would be to remove the file /misc/textarea.js.

The harder, but probably nicer way is to fix this in either your theme, or in a tiny module.

In your theme, you have two options again:

  • use a preprocess to remove the textarea.js from the list of javascript files.
  • use a theme override (yourtheme_textarea) to remove the class resizable-textarea from the rendered HTML. Some information on that in the forums

The option in a module, would be to run a hook_form_alter() to grab any form and run that trough a processor:

/**
 * Implementation of hook_form_alter().
 *
 * Before Drupal 7, there is no way to easily identify form fields that are
 * input format enabled. As a workaround, we assign a form #after_build
 * processing callback that is executed on all forms after they have been
 * completely built, so form elements are in their effective order
 * and position already.
 *
 * @see wysiwyg_process_form()
 */    /**
 * Implementation of hook_form_alter().
 *
 * Before Drupal 7, there is no way to easily identify form fields that are
 * input format enabled. As a workaround, we assign a form #after_build
 * processing callback that is executed on all forms after they have been
 * completely built, so form elements are in their effective order
 * and position already.
 *
 * @see wysiwyg_process_form()
 */
function wysiwyg_form_alter(&$form, &$form_state) {
  $form['#after_build'][] = 'wysiwyg_process_form';
  // Teaser splitter is unconditionally removed and NOT supported.
  if (isset($form['body_field'])) {
    unset($form['body_field']['teaser_js']);
  }
}

function wysiwyg_process_form(&$form) {
  // Iterate over element children; resetting array keys to access last index.
  if ($children = array_values(element_children($form))) {
    foreach ($children as $index => $item) {
      $element = &$form[$item];

      // filter_form() always uses the key 'format'. We need a type-agnostic
      // match to prevent false positives. Also, there must have been at least
      // one element on this level.
      if (($item === 'format' || $item === 'signature_format') && $index > 0) {
        // Make sure we either match a input format selector or input format
        // guidelines (displayed if user has access to one input format only).
        if ((isset($element['#type']) && $element['#type'] == 'fieldset') || isset($element['format']['guidelines'])) {
          // The element before this element is the target form field.
          $field = &$form[$children[$index - 1]];

          $extra_class = '';
          if (!empty($field['#resizable'])) {
            $extra_class = ' wysiwyg-resizable-1';
            drupal_add_js('misc/textarea.js');
          }

          // If we loaded at least one editor, then the 'none' editor will
          // handle resizable textareas instead of core.
          if (isset($loaded) && !empty($field['#resizable'])) {
            $field['#resizable'] = FALSE;
          }
        }
        // If this element is 'format', do not recurse further.
        continue;
      }
      // Recurse into children.
      wysiwyg_process_form($element);
    }
  }
  return $form;
}

These examples are from WYSIWYG module, and slightly altered.

In your theme is far simple, but requires a theme that you can override. The module is both performance-wise worse, and a lot more complex. However, it will work on any theme.

berkes
You should never remove files from /misc/: every thing except for the sites directory should be pristine. hook_form_alter is the right way to remove it.
Mark Trapp
I disagree. Albeit, this is a good rule of thumb, and there are many reasons to not touch Drupal Core, it /is/ but a Dogma. Often the overhead of extra code, modules maintainance and overhead is not worth managing one simple core patch in a proper RCS.
berkes
You can stop javascript files loading in the theme layer, which is preferable to just flat out deleting them.
cam8001

related questions