I add CCK fields, both plain text and filter input...both of them have the CKEditor.

It also appears when I select "PHP code" as the input format, I have to manually click "Switch to plain text editor".

Any help why this appears on all textarea input fields?

Comments

wwalc’s picture

Check the CKEditor profile and adjust include/exclude settings - disable CKEditor on fields where it should be disabled.

Anonymous’s picture

No that's not the point. When you select PHP Code as input filter, the ckeditor should be disabled. Otherwise you'd have to manually set EVERY nod type with PHP code to disabled, like

*node/47*
*node/48*
*node/112*

Imagine thousands... Not good.

But the WYSIWYG module does that. You can switch to PHP code and it disables the wysiwyg completely. That's why I'm abandoning Ckeditor switching back to WYSIWYG + CKEd.

jcisio’s picture

First, if you want different behavior depending on input filter, use the WYSIWYG module. Only this module support that.

Secondly, CKEditor can disable on the textarea you don't like. By setting the path as you said, or by setting the textarea id, or node type. Try blog@*, it will disable the editor on any blog node.

TimG1’s picture

Subscribing.

I was using WYSIWYG w/CKeditor before but then tried to customize a toolbar. #735624: Enabling one button removes default editor toolbar

At the moment it seems if I use CKeditor alone I cannot control behavior depending on input filter but can control the toolbars. If I use WYSIWYG then I cannot control the toolbars but can have better control over the input filter.

Is that correct?

-Tim

goxom’s picture

I have the same problem like TimG. I installed WYSIWYG module, then CKeditor and now It seems that config.js configuration file doesnt work. Is it possible control CKeditor by site and also by config file?

monti’s picture

There are two main options:

(1) When you use the CKEditor module with the CKEditor editor, you can control the buttons layout through ckeditor.config.js and can exclude / include different text areas through the module's configuration page. Under each text area, you will find its ID. Look it up, but use with wildcard chars (syntax is shown in the module's configuration page) instead of [in|ex]cluding by particular IDs.

(2) When you use the Wysiwyg API module with the CKEditor editor, you can control the buttons layout through the module's configuration page, and control which input-format is associated with the editor. The rational of associating with input-formats rather than text areas IDs is actually to keep it simple. The input-format's filters define what a particular role can do. The editor is just a fancy/easy interface. The configured editor's buttons should exactly match the input-format's filters. You don't want the editor to be short on allowed tags (provide less options than its input-format) and you don't want extra buttons as they won't work (filtered out)... If you still would like to control where the editor is available, you might want to check Better Formats for additional flexibility.

thekevinday’s picture

I agree with #2.

In my case, I am dealing with ckeditor applying itself to "Plain Text Fields".

This could be a bug where ckeditor is not supposed to apply itself to "Plain Text Fields" but is in my case.
Despite that possibility, I still intend to make an argument in favor of #2.

Ckeditor is for Filtered content types and should not apply to "Plain Text" Input Formats (and I guess PHP input formats as mentioned in #2).

For example:
I have a privileged, non-admin, user who can modify content types.
This user is allowed to create as many content types with any sort of name.
That user does not and should not have admin access to ckeditor controls.

Instead, whenever this user creates a field, this user must select either "Plain Text" or "Filtered Text".

When "Plain Text" is selected, ckeditor should not appear.
When "Filtered Text" is selected, it should appear based on any exclude / include rule.

Furthermore:
Using Ckeditor for "Plain Text" makes no sense whatsoever.
I can "Bold", "Change Font Size", "Add Images", to something that will treat all of the produced html as plain text.
Which means what they see and what they get have little relation.
All of the HTML symbols, such as the greater than and less than symbols, will be converted to their text based equivalents.
The end result will be nothing less than a complete mess:
<p><strong>A Simple  Example</strong></p>
Instead of
A Simple Example

If this is not enough, then there is also:
There are more pages than just the node/41 pages and node/add/some-content-type.
Each and every module added to the system has the potential to add a page that does not match a given rule.
Having to write rules for every single case can be unrealistic and is more work than necessary.

emilyf’s picture

subscribing. same issue as thekevinday

thalemn’s picture

I'm not sure if I'm having the same problems, but my issue with ckeditor is that it appears and disappears randomly. For example, one day it will be there for a new blog entry, and the next day it will be gone. True for regular page content, too.

If this is NOT related to the issues posted here, does anyone have any suggestions for me?

Thank you!

insitemotion’s picture

I have the same issue with the ckeditor randomly disappearing. Please advise.

Cyberflyer’s picture

CK Editor has a config file:

ckeditor.config.js

http://tinyurl.com/2dtg2wc

There is a whole list of configuration options in the documentation.

http://tinyurl.com/29gy98t

I crafted the following config file for my theme:

/*
Copyright (c) 2003-2010, CKSource - Frederico Knabben. All rights reserved.
For licensing, see LICENSE.html or http://ckeditor.com/license
*/

CKEDITOR.editorConfig = function( config )
{
	// Define changes to default configuration here. For example:
	// config.language = 'fr';
	// config.uiColor = '#AADC6E';
    config.protectedSource.push( /<\?[\s\S]*?\?>/g );   // PHP Code
    // config.extraPlugins = 'MediaEmbed';
    // config.bodyClass = 'singlepage';
    config.bodyId = 'page';
    config.extraCss += "body{background:#FFF;color:#111111;text-align:left;font-size:0.8em;padding-left:10px;width:490px;}";
    config.indentClasses = [ 'rteindent1', 'rteindent2', 'rteindent3', 'rteindent4' ];

	// [ Left, Center, Right, Justified ]
	config.justifyClasses = [ 'rteleft', 'rtecenter', 'rteright', 'rtejustify' ];
	
	// The minimum editor width, in pixels, when resizing it with the resize handle.
	config.resize_minWidth = 450;
	config.resize_maxWidth = 500;
	
	// Protect PHP code tags (<?...?>) so CKEditor will not break them when
	// switching from Source to WYSIWYG.
	// Uncommenting this line doesn't mean the user will not be able to type PHP
	// code in the source. This kind of prevention must be done in the server
	// side
	// (as does Drupal), so just leave this line as is.
	config.protectedSource.push(/<\?[\s\S]*?\?>/g); // PHP Code
	config.extraPlugins = '';
	if (Drupal.ckeditorCompareVersion('3.1')) {
	config.extraPlugins += (config.extraPlugins ? ',drupalbreaks' : 'drupalbreaks' );
	}
	
	if (Drupal.settings.ckeditor.linktocontent_node) {
	config.extraPlugins += (config.extraPlugins ? ',linktonode' : 'linktonode' );
	}
	if (Drupal.settings.ckeditor.linktocontent_menu) {
	config.extraPlugins += (config.extraPlugins ? ',linktomenu' : 'linktomenu' );
	}
	
	config.toolbar_Full =
[
    ['Source','-','Save','NewPage','Preview','-','Templates'],
    ['Cut','Copy','Paste','PasteText','PasteFromWord','-','Print', 'SpellChecker', 'Scayt'],
    '/',
    ['Undo','Redo','-','Find','Replace','-','SelectAll','RemoveFormat'],
    ['Form', 'Checkbox', 'Radio', 'TextField', 'Textarea', 'Select', 'Button', 'ImageButton', 'HiddenField'],
    '/',
    ['Bold','Italic','Underline','Strike','-','Subscript','Superscript'],
    ['NumberedList','BulletedList','-','Outdent','Indent','Blockquote','CreateDiv'],
    '/',
    ['JustifyLeft','JustifyCenter','JustifyRight','JustifyBlock'],
    ['Link','Unlink','Anchor'],
    ['Image','Flash','Table','HorizontalRule','Smiley','SpecialChar','PageBreak'],
    '/',
    ['Styles','Format','Font','FontSize'],
    ['TextColor','BGColor'],
    ['Maximize', 'ShowBlocks','-','About']
];



};

I save it at:

sites/all/libraries/ckeditor/config.js

All of this is ignored by WYSIWYG - CKEditor.

What I am REALLY trying to do is enable a tiny snippet of PHP that I need to run to make a LM_Paypal button work.

How come WYSIWYG - CKEditor ignores the CKEditor config file?

And has anyone gotten the combo to allow inclusion of PHP in a field?

edcable’s picture

Subscribing. Same issues as thekevinday.

jcisio’s picture

If you have such issue, switch from exclude to the include option. That solves the problem.

If you don't want to solve the problem with the current feature, but want something like WYSIWYG module, then turn this issue into "feature request" or use that module. That feature is not perfect, neither. For example, you don't know which filter to apply (if you have more than one) before you submit your form.

thekevinday’s picture

Category: support » feature

Switching from exclude to include implies that I have a known list of paths to add to the include, which I do not.
The paths are ultimately being created by end-users who will not have access to to the ckeditor admin.

With the exception of this feature, I find this ckeditor module functions better than the one from the wysiwig api.

I would say that this should be a feature request for enabling/disabling ckeditor based on the input field.

jcisio’s picture

Why per path? You can do it per form id. And it supports wildcard. I don't know any case in which admin cannot decide to enable/disable the editor. Thus, I'd love to see one.

thekevinday’s picture

Because the forms themselves can be generated by users as well..

jcisio’s picture

Can you give me an example please? Which module? It's easy for a module to disable CKEditor on its forms: $form['#wysiwyg'] = FALSE;

There're too many ways to do it. It just does not do it the way (that you think) it should do.

thekevinday’s picture

I have given limited access to CCK/create content for certain users.
They can create content types for whatever reason and some have the ability to use whatever path for the content types via pathauto.

These users only have enough permissions to set the type of textarea fields to plain text and html text.
The forms that are presented should be either a wysiwyg for html text and not a wysiwyg for plain text.

The created forms are then used by users or anonymous with only enough permissions so fill out a given form.

jcisio’s picture

So, it's easy. Ask your powerful users, with the "administer content types" permission, to prefix their plaintext fields, such as field_plain_NAME for plain text, then exclude them with wildcard. I haven't tested, but there's a chance that it works.

I asked for "which module". AFAIK, what you describe (limited in a certain field types, rich/plain textrea) is not available in CCK.

I don't care about the path, and even pathauto does nothing here. It's the administer URL alias permission (Drupal core) that allows user to change the path. Except that you was saying they have permission to modify pathauto admin settings! (if they have too much power, why just don't allow them to modify CKEditor admin settings).

Anyway, I can't imagine what your admin/user/permissions looks like when there is too many content types and too many fields.

This post does not mean to be offensive. I just remind you was not asking for feature, but for a different way to implement an existing feature. I thought a "per filter" setting was a "must have" but in fact now I think it is not such important.

thekevinday’s picture

Actually, I wrote wrappers that call the functions and remove a lot of the overly complicated stuff so that they don't have real admin.

The problem with prefixing the tables is that I am already experiencing problems with cck fields being too long and when combined with the views module, the lengths go beyond the maximum length in the database of 128 characters. (Something I never liked about postgres, a compiled in hardcoded limit)
A second problem is that the users change their mind or some sort of strange legal requirement causes something to change.
Changing the field name would require deleting the field.
Deleting the field would require losing the data associated with that field for existing content.

They don't actually have "administer content types" or admin privileges to "pathauto"...

I do not think I am understanding you here when you say:
"what you describe (limited in a certain field types, rich/plain textrea) is not available in CCK."

In CCK, take a Field type of "textfield" and a Widget type of "textarea".
From there, they can they have: "Filtered text (user selects input format)".
I only wish I could leave it at that, but there are cases where the users need to have the choice, say two different types of plain text fields.
(Personally, I believe that cck needs to have more flexibility here as well..)

Because I can have multiple input types and users may end up selecting them from forms.

Yes I have very complicated (and sometimes very weird) systems.
For that matter, I have ACL and content access and a ton of Roles in use to help automate permission management.

Based on all of the complex requirements I have, I am requesting to have some feature that allows me to select whether or not ckeditor will show based on the "input format".
Perhaps adding a checkbox "enable/disable ckeditor for this input format".

jcisio’s picture

Ok, I understand more after you elaborate it. Try this code in your hook_form_alter():

  if (is_array($form['#field_info'])) {
    foreach ($form['#field_info'] as $field) {
      if ($field['module'] == 'text') {
        foreach (array_values(element_children($form[$field['field_name']])) as $k) {
          $form[$field['field_name']][$k]['#wysiwyg'] = $field['text_processing'] == 1;
        }
      }
    }
  }

I haven't tested with CKEditor as I don't have it now in my test site. But I write it with the devel module. This sets the #wysiwyg attribute to TRUE/FALSE depending on your CCK field setting.

thekevinday’s picture

I have found two solutions for the cck fields.

First Solution:
When CCK has an input format for a text area set to formatted instead of plain text, it adds the field called 'format' in the '#columns' section of the $element array.

By adding the following code to ckeditor.module around line #425 in the ckeditor_process_textarea() function:

<?php
  if (isset($element['#columns']) && !in_array('format', $element['#columns'])){
    return $element;
  }
?>

The problem gets resolved.
What this does is make ckeditor process what cck does to communicate that the field is or is not a 'format' field.

Second Solution:
The second solution is to make CCK follow ckeditor instead of ckeditor follow CCK.
This would be to find out wherever they have a CCK field text area define, they should add the '#wysiwyg' element as mentioned in #21.

jantoine’s picture

jcisio,

As described in this thread, http://drupal.org/node/715408#comment-2686112, by many prominent Drupal contributors, using the #wysiwyg property is incorrect and a method for babysitting "broken code". It seems that the "Drupal way" will end up being that client-side editors should only work on input fields for filtered content. If the CKEditor module wants to be Drupal friendly and build strong community support, it should follow "best practices".

Anyway, I can't imagine what your admin/user/permissions looks like when there is too many content types and too many fields.

Whether its meant to be offensive or not, the above quote does in fact seem very offensive and inappropriate. Let's stay focused on the issue so we can get it resolved.

Ask your powerful users, with the "administer content types" permission, to prefix their plaintext fields, such as field_plain_NAME for plain text, then exclude them with wildcard.

Drupal's learning curve is already high enough due to its great flexibility. Placing additional requirements on end users is not a solution but a workaround.

Another use case for this feature is when the CKEditor module inappropriately takes over textareas in a modules settings area that require specific formatting such one item per line, etc. Requiring either the module maintainer to add code to the module or the webmaster to add those fields to CKEditors visibility section is a workaround, not a solution and is overall much more work than offering a proper solution. Imagine managing 100+ Drupal sites where you have to make these changes vs. CKEditor only replacing input fields for filtered content. I much prefer the latter.

+1 for client-side editors only replacing input fields for filtered content.

Cheers,

Antoine

jcisio’s picture

'#wysiwyg' is a workaround (they say that in the code, too). But it works. I just wanted to show a simple working solution. I think we could open a new issue 'CKEditor visibility and input format' (in fact there is #884686: CK Editor is shown on plaint text fields and php filter fields). But don't hold your breathe then. I saw feature delayed from Drupal 4.6 to 4.7, 5, 6 and 7.

John Franklin’s picture

I need this, too. I use WYSIWYG now, but i'd be so happy to dump it. On every site I've used the WYSIWYG module, I've had a nightmare of a time getting the editor to work well. Currently, it's not possible to set forcePasteAsPlainText with WYSIWYG (or I can't find that option), there is no way to group buttons, or reorder them or any of a number of other options.

All I need is to tell CKEditor to only show itself on *certain* input formats. This can't be that hard.

dago.aceves’s picture

So i needed to get wysiwyg out of my forms and im using ckeditor, turns out this works.

  // This was altering a node form so i can display some custom datapoints
  $form['datapoint-fs'] = array(
      '#type'         => 'fieldset',
      '#title'        => 'Datapoints',
      '#weight'       => 1,
      '#collapsible'  => TRUE,
      '#collapsed'    => FALSE,
    );
  foreach($node->datapoints as $dpid => $dp){
    $form['datapoint-fs']["datapoint-" . $dpid] = array(
      '#type'         => 'textarea',
      '#title'        => $dp->label,
      '#description'  => $dp->description,
      '#default_value' => $dp->value,
      '#wysiwyg'       => FALSE,  // This keeps ckeditor from trying to help my form. no need to go through admin.
    );
  }

You could alternately alter other forms where you want to get rid of wysiwyg without using rules.

Hope this helps.
Cheers mate.

jmlane’s picture

Title: CKEditor takes over all input fields » Implement toggling CKEditor and/or configuration profile based on field Input Format
Component: User interface » Code

+1 on the original request for a way to associate a CKEditor configuration profile with specific Input Formats. I find there is a lot of value in this functionality and is a good solution for issues like wanting to force a CKEditor profile or disable the editor, based on the Input Format being selected on individual fields/nodes.

@jcisio mentioned that this sort of functionality, as seen in the WYSIWYG module, has issues with it as well. I am hoping someone with some counter-examples for why this functionality is not worth implementing can jump-in and help move this thread toward finding a solution that works for everyone.

dczepierga’s picture

We discuss about this and finally we decide that we release 6.x-2.x version with input format support.
So in the beggining of February, I start to work on it, so asap i release DEV version of this module for review.

I will inform U about progress of my work in this issue...

Greetings

jmlane’s picture

Thank you, dczepierga. I look forward to the new development release.

jvieille’s picture

+1

cazam’s picture

Hi dczepierga,

It's now being 10 months since you informed us you would be working on adding support to "input formats", have you made any progress on this?

Kadu

mkesicki’s picture

Status: Active » Postponed

This is not yet done . Please be patient. Please remember that you can always create a patch to do this.

bermin’s picture

appears that ckeditor dev has this change made

uh wait, nope, still doesn't work.. still getting ckeditor in cck node fields that I have set to Plain Text.

Fannon’s picture

Is there Progress on this?

I'd like to deactivate CKEditor on pure Text Input. But i haven't found a way to do it yet.

greets,
Simon

wwalc’s picture

@Fannon - Unfortunately no. In fact I really doubt that this feature will be created for the 6.x line of CKEditor module, unless someone code it and come with a working patch.

CKEditor module is an Open Source project, so anyone can participate in it. If anyone is really interested in this feature, I'd like to encourage you to try implementing it and sharing it with others. If the code will run properly and other interested users will confirm that it works fine with most common use cases (Plain text/PHP/CCK), then we'll be very close to committing it and releasing the new 6.x-2.x family.

jcisio’s picture

In case anyone wants to work on a patch, I think we could look at $form['a_field_name']['format'] if that key does not exist, assign '#wysiwyg' => FALSE. Haven't tested, though.

mpaler’s picture

Issue summary: View changes

I'm good for $100 to anyone who can provide a working patch for this. Basically, the functionality as described in #2 -- ckeditor toggles on an off depending on the input formats it is connected to.