restore d6 style visibility settings (paths, fields, simplified toolbar, etc.)

In D7 simplified toolbar it's not needed because u have input format support...
If u ask on include/exclude fields support it would be added in 7.x-2.x version - we don't add support for this feature because when we project engine for CKEditor module it was beta version of D7 and then we think that all textareas fields will have input format support. Now we see that not all developers add support for there CKEditor wouldn't be attached...

If u have more questions about CKEditor module pls reopen this issue.

Greetings

I would love to see anything you were able to figure out. This is a critical feature for me.

subscribe

I have a bit of a work-around I wanted to post. I installed Better Formats and set my content creator role to not have privileges to select their own filter. This means that whichever text format is on the top of the list on http://ww.example.com/admin/config/content/formats will be the only one the content creator can use. That's not so great, so as the next step, make a custom module with this code:

/**
 * Implementation of hook_form_alter()
 */
function set_text_format_form_alter(&$form, &$form_state, $form_id) {
  $alter = array(
    'page_node_form'             => array('body' => 'filtered_html'),
    'showcase_onecol_node_form'  => array('field_sc_onecol_item' => 'video_embedding_html'),
    'field_sc_onecol_item'       => array('field_sc_onecol_item_video' => 'video_embedding_html'),
    'showcase_twocol_node_form'  => array('field_sc_twocol_item' => 'video_embedding_html'),
    'field_sc_twocol_item'       => array('field_sc_twocol_item_video' => 'video_embedding_html'),
    'spotlight_node_form'        => array('field_sl_video' => 'video_embedding_html'),
  );
  $field_collection_subfields = array(
    'field_sc_onecol_item'       => 'field_sc_onecol_item_video',
    'field_sc_twocol_item'       => 'field_sc_twocol_item_video',
  );
  // We set the $key to determine if a form should be altered, by checking if it is listed in the $alter array.
  // For node edit forms, $form_id is a good key, but we need to be more specific for field collection edit forms and use 
  // $form['field_name']['#value'].
  if (array_key_exists('#entity_type', $form) && $form['#entity_type'] == 'field_collection_item' && array_key_exists('field_name', $form)) {
    $key = $form['field_name']['#value'];
  } else {
    $key = $form_id;
  }
  // Check that we'd like to alter some text formats on this form, by seeing if the $key is in $alter.
  if (array_key_exists($key, $alter)) {
    // Get the fields on this form that we'd like to alter, along with the desired text format.
    $fields = $alter[$key];
    // Go through each field and set it to its designated format.
    foreach ($fields as $field => $format) {
      if (array_key_exists($field, $field_collection_subfields)) {
        // When a field to be altered is a subfield of a field collection displayed on a node edit form, then we need to go deeper 
        // into the $form array to set the #format.
        $items = $form[$field]['und'];
        for ($i = 0; $i <= $items['#max_delta']; $i++) {
          if (is_null($form[$field]['und'][$i][$field_collection_subfields[$field]]['und'][0]['#format'])){
            $form[$field]['und'][$i][$field_collection_subfields[$field]]['und'][0]['#format'] = $format; 
          }
        }
      } else {
        // When a field is not so deep in the $form array, we can set the #format like this.
        if (is_null($form[$field]['und'][0]['#format'])) {  
          $form[$field]['und'][0]['#format'] = $format;
        }
      }
    }
  }
}

There's a lot of stuff in there, but the main idea is that I'm checking to make sure I'm on a form I'd like to alter and then if I am, altering the field given in my $alter array. I have to do some fiddling because I'm using Field Collections and that makes the code more complicated than it would be otherwise. The most important line is this:

$form[$field]['und'][0]['#format'] = $format;

Here, I'm telling this field which format to default to. Since content creators can't change that, I've set it up so they will be using the correct field. For admins, it's just what the text format defaults to and then they can set it as they'd like.

This actually works pretty well for my use case, although it'd be nice if it were easier to do!

Anyone want to critique my code, feel free!

subscribe

Increasing the priority on this issue. Seems like the team eliminated a core feature of this module in the CKEditor module in the Drupal 7 upgrade. I won't be able to upgrade my systems to D7 until this feature is built back into this module.

I agree with WorldFallz. This feature in D6 was the main reason I used this module instead of the WYSIWYG module.

subscribe

Adding testimony: This is a critical omission. Better Formats, while excellent, IN NO WAY addresses my primary use-cases for restricting visibility on some fields.

WYSIWYG is not an alternative for my use-cases, since it essentially provides no way to produce a usable toolbar.

Like others in this posting, this feature was a key factor in choosing this module. I'm very grateful to somanyfish for posting a workaround that might help me, but would be much happier to just have the feature put back into D7 (and future releases) and not have to add another work item to D6 upgrades. It's a great feature!

Subscribing: perhaps the greatest feature in CKE 6.x !
Priority 'critical' !

In case anyone still needs a use-case to justify this, here's what we do for all sites we build in D6:

First, we set the CKEditor module to display only on specified fields. This reduces page load time on pages with lots of text fields -- we typically have at least four text fields on our main page, and may have several other fields that would need to be excluded if we used it in exclusion mode.

It also gives us the latitude to never permit CKEditor to display on some fields, e.g. in some block edit pages. That's often been important because we use blocks to create formatting elements, thus giving clients access to edit and alter their own design elements when it's needed. Sometimes we need to prevent CKEditor from modifying code in those fields, and the only way to do that is to ensure that it's never loaded.

Finally, without inclusion/exclusion, we don't have a way to be certain that CKEditor won't be displayed on particular text fields. That's an absolute necessity.

Effectively, this omission removes one of my last two barriers to WYSIWYG migration. If the WYSIWYG project can ever figure out how to let us configure our own toolbars, then the CKEditor module will pretty much be redundant.

Subscribe ...

Is this feature really never going to be brought back? It's quite evident from this issue and from the numerous duplicates of it that it is a required feature.

I ended up in a discussion similar to this on another issue that is closed. I had a thought today, but I couldn't make it work. Maybe someone better at hook_form_alter() could do it, if they think it could work.
My problem lies mainly with comments. The system as is makes it so they can be plain text or one of the text formats. I'd like to allow authenticated users the ability to use a simple toolbar in comments, but the regular filtered one for content adding. So far the best solution was to make a comments text format, move it to the top position, so it's the default, and assign it to authenticated users. Make a ckeditor profile that uses the comments text format, and has just a simple toolbar. This works, but it makes it so people have to understand they can change the toolbar if they need it for content editing. My assumption is users will not understand this.

My thought was could you use hook_form_alter() to change the comments format pulldown, making it so it defaults to the desired text format, even if it's not the default format. Then you could use CSS to make the pulldown not visible at all in comments.

I tried to add this into a custom module I have already:

function mymodule_form_alter(&$form, $form_state, $form_id) {
  if($form_id == 'comment-form'){
    $form['comment_body'][ $form['comment_body']['und'][0]['format']['#options']['#default_value'] = 'comment_edit';
  }
}

Then #edit-comment-body-und-0-format {visibility: hidden; display: none;} to make it go away. I obviously don't have the hook_form _alter correct because nothing happened.

Another use-case for this:

On a site I'm just finishing up right now, there's a ton of jQuery enabled interactivity.

Most of this stuff breaks spectacularly if we allow CKeditor to render it.

The ideal, simple, one-step response would be to disable CKEditor for the pages that require said interactivity.

Being able to stipulate that CKEditor should not be loaded for certain content types or certain nodes would be a simple, elegant solution to this problem. Instead, I'm going to have to do what WorldFallz suggests (install an additional module and do a bunch of additional configuration), instead of the relatively simple approach that was possible before.

Also, thanks WorldFallz for the suggestion -- that sounds like it should work for us, assuming what you describe is actually possible in the D7 release (which is still beta and avowedly unstable per its authors).

I agree that this would be a useful feature. Patches are welcome. I'll commit if there is a RTBC patch.

Subscribe. A little stunned that such critical functionality was left out of D7. That's a serious devolution. Any updates?

You might be interested in my patch at #2273977: Allow configuration based on fields instead of only text formats.