Hide editor on a specific CCK field

Yes. Disable the "Filtered text" option for the CCK field (i.e. enable "Plain text" instead).

Wysiwyg API allows to attach an editor wherever an input format enabled textarea appears. It is not the job of this module to alter the available input formats.

Marking as duplicate of #350696: Per field format settings with full BF options via CCK widget. You can follow up on that issue to track its status instead. If any information from this issue is missing in the other issue, please make sure you provide it over there.

However, thanks for taking the time to report this issue.

I think the question of this issue is misunderstood from the beginning. In the old TinyMCE and TinytinyMCE modules for example, without changing input format, you could control if the editor will be used in a specific text field by the text area ID's without changing input format.

It would be a really useful option if we could control the availability of editor per field. After this very nice module, I dont want to use that old wyswyg editor modules anymore. But I cannot find any way to hide or show the editor for a specific field.

The pointed issue #350696, in my opinion, is irrelevant to this subject.

Like sun said, Wysiwyg module is different in the way that each editor profile is tied to an input format. That will not change, but one goal of 3.x is that you'll be able to have more than one profile per format. There's also an issue about improving the logic deciding whether the editor should be on by default, which when solved will allow your user to decide if they need the editor or not.
Editors cannot be configured for a textarea without a format (including a format selector or description in the GUI) as those are assumed to be plain text fields. D6 core doesn't always make this assumption easy because of missing selectors, but D7 is better there. Editors are no good on a plain text field anyway.

Better formats module allows you to control which content types (body field) and user roles are able to use which formats, and the issue sun links to will allow you to specify an input format for CCK fields as well. If you want a field to have markup, you choose a format allowing it. You've probably assigned an editor profile, and in 3.x maybe some variations of it, to the format in case your users are not comfortable hand coding markup. Depending on your users preferences, they might not see the editor at all, or one of the alternative profiles. They can at any time toggle the editor or switch to another profile on the same input format. If they have the permissions to do so, they could also switch to other formats (and in doing so, lock out users which do not have permission to use them) but then they will get another set of editor profiles especially configured for that format. Again, if they do not desire an editor on that format and have previously disabled it, no editor will show but they can still load it at will.

Wysiwyg module needs to support more profiles per format, and Better Formats (or CCK) module needs to be able to force a format on CCK fields, Which is why this issue was marked a duplicate of that. If you force a field to use an input format which does not have an editor, you've essentially done what this issue is about.

If Wysiwyg module had an additional [path/field-id based] condition on whether to load the editor or not, something like what TinyMCE.module used to have or what FCKeditor.module has now, it would be very hard to integrate into this. What has the highest priority? Should the path/id based condition force editors onto plain text fields if one has been specified? That can't be done though since it wouldn't know which editor to attach. Should it force users which have disabled the editor for a format to use it anyway? Should it disable the editor for users who have chosen to use one with a certain format because the admin forgot to include the textarea id, or a new one was generated by CCK and excluded by default?
A moderator which has permission to use a 'more advanced' input format decides to override something a regular user has typed into a field using the default format. Normal users aren't allowed to use markup, but when using that input format a moderator is, and he uses the editor. The field has been explicitly listed to not use editors in Wysiwyg module. Does the moderator get his editor?

Can you provide use cases where per field control, not based on input format availability, would be necessary? I'll leave this issue open a while for discussion.

I think, at this position we can omit per-role discussion. Let us say that I am the only user on a website. I have a custom content type named "game" and I have several text fields.

The first text field is named "game" and I want it to paste an embed code which I have copied from another website. I would prefer a full-HTML input format on this field, yet I don't want any text editor here.

The second text field is named "description" and I write some description text with styles applied on it where necessary, so I would prefer a full text and a text editor here.

At this point you can say that it is easy to turn on / off a text editor, but if I regularly post content, I may forget to turn off the editor sometimes.

You may also suggest defining a new input format, allow necessary tags and use it on the second text field without an editor at all. It is totally acceptable and then this issue can be combined with issue #350696 (previously stated as duplicate of this issue).

But the ultimate solution is to allow this WYSIWYG module to control per-field setting. I dont know if it is easy though. Mine is just a suggestion.

Cheers,
Sinan

The issue about 'intelligent logic' for the on/off state of the editor included that it should remember the last state, so if you've turned it off once it'll stay off on the same field/format. That is a separate discussion though and probably not very relevant to this anyway.

I would indeed create a unique input format (without editor), but for the 'game' field. Like you say, you don't want to filter any contents in that field because it could destroy the game code, but I'm guessing you don't want to allow this filter anywhere else .
Forcing only this format on the field will of course require #350696 if is not the body field, but naming it something with 'Game' in it will most likely be enough to remember to use that format. A note about it in the field description would probably be nice too. It's not the optimal solution of course, since the field should only accept that format but I could live with it.

The 'description' field could have a regular 'Filtered HTML' format with an editor suitable for the allowed formatting, which you probably use on some other fields which allows similar input.

Since the fields have different requirements on the content they should have different input formats. I currently don't see the need to have "per-field-editor-availability-control" (can't find a good term...) when the fields use different formats. If two fields are using the same format, why should one of them have an editor but not the other, considering they accept the same type of input? That's the question I'm seeking an answer to.

So far I've heard people talking about the editor not fitting into small fields, or disrupting the layout because there are too many buttons in the toolbar when the format/editor allows for pretty much anything. We hope that supporting multiple editor profiles per format will help with that. The editor instance can still handle/allow the same type of input, but with less buttons. Showing a 'source mode' button or just disabling the editor would still allow the more advanced users to take advantage of all the things the visible buttons don't include. If users can also switch between the profiles, they can still show the full toolbar, and hit a 'fullscreen' button if the editor supports it. One could also configure an editor profile without a toolbar and you'll have just a WYSIWYG 'area'.

It's a bit hard to explain how we (or at least I) envision this as we don't have much code to work with for these features yet.

Btw, a bit OT, but I can recommend the WYSIWYG Filter module, it gives much greater control over what is allowed than the standard HTML filter does. It never allows the script tag and some others for security reasons just like HTML Filter, but it allows you to create more specific input formats and adapt them to fit each section of your site. Having generic input formats will work for few user sites where everyone involved can agree on what kind of content fits where.

Thank you for your time and consideration. Your reply is convincing for me...

Sinan

As someone who is familiar with fapi, I feel that there ought to be a way to do this (that is, control, per field, whether wysiwyg is enabled by default, disabled by default, or disabled completely). I understand that wysiwyg works with input filters instead of field types, but does that necessarily mean it can't respect a flag set for a particular field?

I thought I had found the answer when I ran across this code in pathauto.admin.inc:

$form['general']['pathauto_ignore_words'] = array(
  '#type' => 'textarea',
  '#description' => t('Words to strip... do not use WYSIWYG editors on this field'),
  '#wysiwyg' => FALSE,
  ... etc.

So using hook_form_alter, I inserted the #wysiwyg flag into the array of a cck field and... nothing happened. So it must be designed for some other module, or maybe it's obsolete.

So my question is, is there a fapi solution to this, and if not, is there any reason why a condition couldn't be added to the wysiwyg module to check for such a flag when the form is being built?

No. Wysiwyg module doesn't look for that flag.
The only reason I can think of for a field to actually block WYSIWYG editors completely would be if it only supports plain text (with or without tokens) or PHP (without <?php ... ?>). In that case, there shouldn't be a format selector, and Wysiwyg module will ignore the field.
Some other WYSIWYG-related modules do (or once did) check that flag, and I think it is because when they allow users to exclude editors on a per-field basis, there's a great risk of an editor being attached to that field simply because the user didn't exclude it.

Once "format availability control" improves (I'm mostly thinking about CCK fields which currently can't be limited in which formats they allow), and Wysiwyg module gets support for multiple profiles - their availability may become controllable on a per field basis - it will become easier to adapt the editor appearance to suit fields which may not have room for a full-blown editor. It may also become possible to select our "none"/"null" editor as a profile, it basically handles the resize bar state when no real editor is active.

Some other WYSIWYG-related modules do (or once did) check that flag...

Actually it was Wysiwyg module that introduced the #wysiwyg form element property in major versions 0.x or 1.x. Only after doing so, other editor integration modules took over the idea. However, when Wysiwyg module was even further improved to only be triggered/invoked on text fields that actually support HTML formatting, the #wysiwyg property no longer made sense and was removed, but other editor integration modules did not follow this time; most likely because they realized that separate editor integration modules no longer make sense to maintain.

However, some recent issues asked for re-introduction of the #wysiwyg property - for edge-cases, in which text formatting is allowed, but the text field won't ever contain formatted content but some special/custom HTML stuff instead. Re-adding support for a purely negative #wysiwyg => FALSE assignment should be quickly doable - but doesn't seem to be the main topic of this issue.

Ah right, thanks for that Sun. To my defense, it was before my time on this module. ;)

Now that you say that, wasn't their main concern input[type=text] fields? Perhaps related to the spin-off discussion in #466054: FCKeditor: Breaks on CCK textfield (not textarea)?

Either way, I don't really have a huge objection to re-adding '#wysiwyg' to cover those edge cases, but like you said that's not what this particular issue is about.
What I would object to is moving away from using the availability of input formats as a means for determinig editor status. #350696: Per field format settings with full BF options via CCK widget seems to be getting closer to being fixed which I think will alleviate many of the problems discussed here, in combo with the use of specialized CCK fields where appropriate - and eventually multiple profiles in Wysiwyg 3.x.

Thanks Sun and TwoD for filling me in. I totally agree that the input-filter approach works great for WYSIWYG, and the BF module seems to be making good progress on giving more control over individual fields. What I'm suggesting is that we could fairly easily add even more control by allowing the #wysiwyg flag to override the 'defaults' that have been set for a field's input filter. It doesn't have to be a boolean, either (although we could still read it if it is, for backward-compatibility). My suggestion is to have three possible values for #wysiwyg: 'on', 'off', or 'disabled' (or, if a boolean is passed in, on=TRUE and disabled=FALSE).

So when the wysiwyg module parses through the form, it would do something like this (in pseudo-code):

if ( !empty($field['#wysiwyg']) ){

  if ( $field['#wysiwyg'] == TRUE || $field['#wysiwyg'] == 'on' )
    //turn on wysiwyg editor, even if it is disabled by default (but only if there is an editor associated with this input format, of course)

  if ( $field['#wysiwyg'] == 'off' )
    //if there's an editor on this field, have it be disabled by default (user can enable it if $toggle is set)

  if ( $field['#wysiwyg'] == FALSE|| $field['#wysiwyg'] == 'disabled' )
    //disable wysiwyg editor for this field
}

This opens the door for future modules to make use of this flag, one could even create a gui for allowing site admins to set it per field.

See #524126: Ability to hide WYSIWYG on certain fields for #wysiwyg => FALSE

Support for #wysiwyg => FALSE has been re-introduced in the latest official release.