Restrict to some node types

I am interested in this as well. Thanks, Ivan

new features are only introduced in HEAD.

So it would be nice to have settings page where it would be possible to restrict quicktags to be shown only on some certain node types. Only on blogs and story for example.

This is a good idea. This feature is especially required when modifying different content types are allowed to different roles with different filter settings. So, several content types bodies may have these buttons disabled bbcode filter - in this case all entered tags won't be formatted, they are just annoying the user.

Thanks.

alacarteinternet developers and I are working on some nice features for switching the quicktags on and off based on very nifty features. So far, it looks really cool whats coming up! General idea is to render a checkbox/fieldset with each textarea (based on several settings and a permission) wich allows you to change quicktags settings for that specific textarea. PAtches and screenshots soon to come.

Sounds great! It would be nice if this system took into account not just node types, but also comment text areas, contact/feedback form textareas, profile textareas, etc.

Looking forward to it!

hello

excellent module - but: it is nearly useless for my customers without the possibility to activate/deactivate for contenttype, roles etc. - did anybody worked on this?
it would be such a nice alternative for heavy stuff like tinymce - it has the possibility to grow to a "mini-drupal-editor" ....

thanks and greetings
momper

.. if its 'nearly useless' for you, then either don't use it or improve it. That's the way open soure works. Moaning will not get yo anywhere, puttung your effort where your mouth is, will :)

Not moaning, but just nicely asking if they developement mentioned in #4 still is active? I liked the idea.

Sorry, its not. I have asked for the code, but w/o luck.

This is a feature that I'd really like to see. I've created an "add on" module for quicktags which uses Wiki formatting (in conjunction with pearwiki_filter and wikitools), but I'd only like quicktags to be used for the wiki and have tinyMCE for other content types.

I've had a look at the tinymce.module (v 1.90.4.16) file and can roughly see where their code is setting up to determine which pages/content types tinymce will be visible. Unfortunately the code is a bit too complex for me to follow and see how it actually flows.

As I follow it, there is this function which checks some settings to determine whether to show tinymce on a textarea (around line #1081):

/**
 * Determine if TinyMCE has permission to be used on the current page.
 *
 * @return
 *   TRUE if can render, FALSE if not allowed.
 */
function _tinymce_page_match($edit) {
  $page_match = FALSE;

  // Kill TinyMCE if we're editing a textarea with PHP in it!
  // PHP input formats are #2 in the filters table.
  if (is_numeric(arg(1)) && arg(2) == 'edit') {
    $node = node_load(arg(1));
    if ($node->format == 2) {
      return FALSE;
    }
  }

  if ($edit->settings['access_pages']) {
    // If the PHP option wasn't selected
    if ($edit->settings['access'] < 2) {
      $path = drupal_get_path_alias($_GET['q']);
      $regexp = '/^('. preg_replace(array('/(\r\n?|\n)/', '/\\\\\*/', '/(^|\|)\\\\<front\\\\>($|\|)/'), array('|', '.*', '\1'. preg_quote(variable_get('site_frontpage', 'node'), '/') .'\2'), preg_quote($edit->settings['access_pages'], '/')) .')$/';
      $page_match = !($edit->settings['access'] xor preg_match($regexp, $path));
    }
    else {
      $page_match = drupal_eval($edit->settings['access_pages']);
    }
  }
  // No pages were specified to block so show on all
  else {
    $page_match = TRUE;
  }

  return $page_match;
}

This looks to be coupled with some admin settings which give the options for determining display (around line #732):

$form['visibility'] = array(
    '#type' => 'fieldset', 
    '#title' => t('Visibility'), 
    '#collapsible' => TRUE, 
    '#collapsed' => TRUE
  );
  
  $access = user_access('use PHP for block visibility');

  // If the visibility is set to PHP mode but the user doesn't have this block permission, don't allow them to edit nor see this PHP code
  if ($edit->settings['access'] == 2 && !$access) {
    $form['visibility'] = array();
    $form['visibility']['access'] = array(
      '#type' => 'value', 
      '#value' => 2
    );
    $form['visibility']['access_pages'] = array(
      '#type' => 'value', 
      '#value' => $edit->settings['access_pages']
    );
  }
  else {
    $options = array(t('Show on every page except the listed pages.'), t('Show on only the listed pages.'));
    $description = t("Enter one page per line as Drupal paths. The '*' character is a wildcard. Example paths are '!blog' for the blog page and !blog-wildcard for every personal blog. !front is the front page.", array('!blog' => theme('placeholder', 'blog'), '!blog-wildcard' =>  theme('placeholder', 'blog/*'), '!front' => theme('placeholder', '<front>')));

    if ($access) {
      $options[] = t('Show if the following PHP code returns [code]TRUE[/code] (PHP-mode, experts only).');
      $description .= t('If the PHP-mode is chosen, enter PHP code between !php. Note that executing incorrect PHP-code can break your Drupal site.', array('!php' => theme('placeholder', '&lt;?php ?&gt;')));
    }
    $form['visibility']['access'] = array(
      '#type' => 'radios', 
      '#title' => t('Show tinymce on specific pages'), 
      '#default_value' => isset($edit->settings['access']) ? $edit->settings['access'] : 1, 
      '#options' => $options
    );
    $form['visibility']['access_pages'] = array(
      '#type' => 'textarea', 
      '#title' => t('Pages'), 
      '#default_value' => isset($edit->settings['access_pages']) ? $edit->settings['access_pages'] : tinymce_help('admin/settings/tinymce#pages'), 
      '#description' => $description
    );
  }

(please note in the above I had to replace some '<' and '/> in order keep the 'code' block formatting)

What I can't figure out is how to get the settings into the database and call them out again as necessary. I'm probably also missing something else.

Anyone willing to take up the gauntlet?

I added "Show quicktags on specific pages" textarea to specify visibility.

Just updating status since there is a patch here

I applied this patch to $Id: quicktags.module,v 1.21 2007/02/03 10:59:25 ber Exp $ which i downloaded today seems to work fine, you get a reject on the $Id:$ tag comment line is all, not that it of course matters there.

Subscribing, greetings, Martijn

@kalin but did it add the feature as you suspected it would? I'd like to hear some positive reviews before I go ahead and commit the patch.