Enable/Disable editor for specific textareas

The tinyMCE module allow that by declaring a theme function in your template.php. Don't know if WYSIWYG followed the same way, but it would be nice to see it. And it would be wonderfull to be abole to defne a list of textfield you want to hide or show tinyMCE (the same kind of field you define the url you want to activate tinyMCE)...

Wysiwyg implements the #wysiwyg FAPI property to control whether a Wysiwyg editor is allowed for a certain textarea. If #wysiwyg is set to FALSE, then no editor will be loaded.

@sun: I am sorry, but I am confused. Are you saying this feature already exists and if so, where?

The low-level feature exists - so a contrib or custom module is able to explicitly set '#wysiwyg' => FALSE on a textarea, which should not be wysiwyg-enabled in any case. Custom modules can implement http://api.drupal.org/api/function/hook_form_alter/6 to alter form definitions.

However, a feature like Gábor described in a recent blog post (which seems to be provided by FCKeditor module) does not exist yet, which is the reason why this issue is still open.

Marking as duplicate of #253600: Attach client-side editors to input format enabled textareas only

I don't this is a duplicate issue at all. There are some custom content types I'm using that really don't jive with wysiwig, so I really have to turn this off on a node type basis.

Also, I haven't been able to get the #wysiwyg FAPI feature to work at all. For example, to turn it off on the body field, I've tried:

$form['body_field']['body']['#wysiwyg'] = FALSE;
$form['body_field']['#wysiwyg'] = FALSE;
$form['body_field']['format']['#wysiwyg'] = FALSE;

I did set the wysiwyg weight in the system table to come after my custom module.

I couldn't find any reference to the #wysiwyg FAPI property in the code for this module either, so I wonder if this lower-level feature was lost at some point?

Of course I could've missed it or just be doing it incorrectly...

Ok. Until we have better support for input formats in D7, I can see the need for this.

However, I'm unsure whether we really want to re-implement the #wysiwyg FAPI property, or if we rather want to implement a configuration option to disable input formats for certain content-types.

And, on another thought, I'm questioning whether that would be sufficient. "Associate editors/profiles with input formats" is already on the task list (but no issue exists yet), which would allow to associate a certain editor with a certain input format. Combined with an configuration option to remove input formats for certain content-types, you could then for example only allow "Filtered HTML" for blog posts and associate no editor to that input format. Makes sense?

And, on yet another thought, input formats can already be limited via access permissions - so if the association between input formats and editors would be there, would that be sufficient for you use-case?

"... implement a configuration option to disable input formats for certain content-types."

Yes that would be very helpful.

But I think we've got it backwards. Instead of enabling wysiwyg for all textareas by default, what if the administrator had to enable the wysiwyg for specific fields or content types?

When enabling a module, you don't want to scour all your forms to see what parts of your site you now have to fix. You already know where you want wysiwyg capabilities, so you just enable wysiwyg for those textareas and know the rest of the site will be unaffected.

From the description of a profile, it sounds like that would be the intention: "A Wysiwyg Editor profile can define which pages receive this Wysiwyg Editor capability..."

I'm not sure how best to integrate with the "associate editors/profiles with input formats" feature you mentioned, but I think that will be an important component. I'll keep brainstorming too. :)

Oww. Thanks for this pointer - the help text is completely out-dated. Maybe that's the cause for some confusion regarding this issue, so let me clarify:

Editors are no longer tied to textareas. Instead, they are tied to input formats. This means, whereever a textarea appears, which is input format enabled, an editor *might* appear. Whether an editor appears or not, depends on the selected input format. (Well, that's not yet the case, but we are very close to it)

So, what you can do already is to define a textarea in CCK and configure it to be plain-text. No editor will appear for this field.

Additionally, input formats are already granted by role. So if you configure an input format, associate an editor to it, and certain users are not permitted to use it, no editor would appear (for them).

In the end, this issue is a bit hypothetic at the moment, since one cannot associate a Wysiwyg profile to an input format yet. However, when that is done (separate issue), the remaining topic of this issue is whether we are somehow able to limit input formats for certain content-types, and maybe bug CCK developers to add additional configuration options for CCK text fields that are input format enabled (called "formatted" in there).

It's no longer hypothetical. Editors are associated to input formats in the latest development snapshot, and multiple editors can be loaded on a single page. Someone mentioned http://drupal.org/project/filterbynodetype in another issue. So what else is needed for this issue to be fixed?

Thanks Sun, combining filterbynodetype and associating editors with input formats does most of the job. Thanks a lot for this new functionality. Although we still can't affect the defaults for individual textareas, we can change their input format now manually, so that's good. If CCK allowed administrators to set default input formats for each field, we wouldn't even have that problem.

One drawback of this method is that I had to basically double the number of filters I'm maintaining.

• Filter A with WYSIWYG
• Filter A without WYSIWYG
• Filter B with WYSIWYG
• Filter B without WYSIWYG

etc.

Despite that minor annoyance, I think we can safely close this issue. Thanks again for all your hard work on this!

Hm. Thanks for reporting back. However, please beware that the input format configuration you outlined is - due to how input formats work in Drupal - a rather permanent configuration and in my POV, not a "minor annoyance". If we will ever overcome this by implementing additional features into Wysiwyg API or Drupal core, you will probably be stuck with dozens of contents that use one of the "Filter X without WYSIWYG" input formats. You will need advanced Drupal/PHP/DB/developer skills to change the input format in all existing contents to the corresponding format "... with WYSIWYG". Personally, I would not recommend doubling the input formats. Why do you need to duplicate them? It looks like you just want to allow users to use an input format without an editor attached by default. If that is the case, you probably want to reconsider and contribute to #322433: Replace default editor status option(s) with intelligent logic. If not, elaborate on your use-case, please.

How about this - I could be to create one input format for each node type, and then use the filterbynodetype module to only allow the node type's associated format for that node type. That way if I change my mind in the future about how we're filtering that node type I don't have to worry about how the other node types are handled, and there isn't any confusion about with or without WYSIWYG.

Do you think that solves some of the problems with my previous suggestion?

p.s. I tried to contact you earlier through the contact form associated with your profile and never heard back. I want to donate some money to your work on the WYSIWYG API project, but have to send a check. Is there another way to get in touch with you?

Well, that sounds a bit more sane, but at the same time, it is still a hack/workaround that might lead to serious issues after all. A potential reason is: Input formats are not only used for nodes - if your users will use one of those input formats for their user signature or in any other textarea provided by a contrib module that supports input formats, they can choose from all formats they are allowed to use.

Unfortunately, you still did not explain your use-case/scenario and why you think you need workarounds like this.

@jumpfightgo: I replied to your original mail, and also tried to reply using your contact form on drupal.org - did you receive anything?

Hi sun,

Here are some possible use cases that I come across that require such feature
- disable editor for all paths under /admin
- enable/disable editor for certain pages/paths,
- or complex requirements by using php to determine where to show the editor, based on role, etc.
- other module's text area which does not has a associated input format, e.g. legal module, site information, etc. which does support HTML markup #337590: tinymce visibility options??

Perhaps a simple checking like what tinymce has on editor appearance (visibility), based on path, php?

Here are some possible use cases that I come across that require such feature

None of the listed points is a real use-case. Could you please be more concrete?

- disable editor for all paths under /admin

Editors won't show up there already - as long as there is no form field that is input format enabled.

- enable/disable editor for certain pages/paths,

Why? Also, this does not work out, since the path is irrelevant - what matters is/are the form field(s).

- or complex requirements by using php to determine where to show the editor, based on role, etc.

Input formats are already bound to user roles. Isn't that sufficient?

- other module's text area which does not has a associated input format, e.g. legal module, site information, etc. which does support HTML markup #337590: tinymce visibility options??

Regarding Legal, fix the Legal module instead. If the module's purpose is to allow HTML markup in the output, it should properly implement input format support.

Regarding other Drupal core system forms, as analyzed and outlined by Gábor, I am thinking of a small helper module that ships with Wysiwyg and can be optionally enabled to add dummy input format selectors to the various places in core where core is wrong. Most sites won't need this, but I agree that there should be a simple way to enable and use editors on the stated form fields and areas of Drupal core prior D7.

Here's a situation I find myself in that might serve as a use case.

We have a site with various sorts of user-contributed objects, including forum posts and tasks (where tasks are something managed by our custom module). Posts can have pictures in them; tasks cannot. It follows that the customer wants for the Add Image button to be present in the TinyMCE toolbar for forum posts but not for tasks.

We can go some way towards fulfilling this requirement by having separate input formats, say 'Filtered HTML' and 'Filtered HTML sans images' with TinyMCE's settings tweaked appropriately for each. The problem is ensuring that only one of these two formats is shown in the Formats menu for the respective textareas. Maybe some ahackery via hook_form_alter will do it.

@damiancugley: You might want to have a look at http://drupal.org/project/better_formats

To consider any actions for this issue, I need proper use-case scenarios. Most (if not all) of what has been mentioned so far can be achieved using the Better Formats module.

I'll mark this issue won't fix if there will be no information for two weeks.

This might be a use-case scenario, though I want to admit at the beginning I could be missing something obvious:

I have two fields in a CCK Type, Races. The main body field should use WYSIWYG/TinyMCE with Rich Text as its input. This field works just fine.

I have a second "map" field where I want users to paste google maps code. If the field settings are set to "plain text" which does not allow user choice, the google code is pasted and it is the code that shows up in the node, not the map. I have modified my plain text input filter to exactly match my rich text filter, no affect.

However, if I allow a user to select the input format (which I really don't want), the field defaults to Rich Text (the site default), WYSIWYG pops on (which is good), and promptly eats the google code (not so good). The only way to get the code to show up is to disable the editor, repaste the code, and save. But if you edit the post, same problem, the code is eaten.

For the sake of users with very limited web experience, I want the map field to be rich text WITHOUT wysiwyg/tinymce.

Is that a use-case scenario? If it is, let me know the solution. I looked at better_formats, but it does not do field-level control.

Thanks,
Maria

Well, that's finally a real use-case, so thanks, Maria.

However, I consider the entire approach as a wrong design. If you want your users to just be able to store geo information in a field (and nothing else), then you should not use the gmap filter with a CCK text field. Instead, use one of the modules that provide a real CCK field for entering and displaying a Google Map. I do not know which module provides such a CCK gmap field, but I'm sure there is one.

Marking as won't fix.

I'm trying to do the same thing as #21. To be clear, I'm not asking the users to enter geo data. I only want them to paste the embed code (usually an iframe) into a cck textarea. For reasons stated above, the field has to allow the necessary tags and can't use a wysiwyg editor.

If I use a textfield (not set to plain text) instead of an area it will work, but there is a wysiwyg error that pops up "Error: The TEXTAREA with id or name set to "edit-field-map-embed-0-value" was not found." Further, the textfield is pretty small and hard to use.

There is the iframe project, but it doesn't work with gmaps and would not work for me in all cases.

All I need is to simply turn off wysiwyg by default with no options for the user to select a format for this field.

Advice is appreciated. Thanks.

I've a similar problem: I've to paste a "youtube" embbedded video on a block. I've solved creating a "plain text" input format and I've not associated to wysiwyg and I've solved the problem :)

Better_formats seems the way to go :)

The recommended techniques didn't work *at all* for me. The only way to prevent WYSIWYG from showing up for a specific content type was to set $element['format']['#access'] to FALSE in a #after_build handler. Otherwise some module (probably better_formats, didn't check) added back the whole filter format fieldset. What a pain in the ass :(

Please reimplement #wysiwyg FAPI-attribute again or add a per field ui-solution (i.e as ckeditor.module does). This seems the only practical possibility to disable wysiwyg for certain fields. Using other modules like BetterFormats is too much overhead to achieve this.

Use case:
Content Type with body field and additional textarea. User has access to "filtered html". To be able to display entered linebreaks in the textarea you need to set its input format to a format with linebreak-converter.
However, if I create a new input format without wysiwyg and grant the user access to it, it results in having an input-filter select option under each field - just because there's no other way to disable wysiwyg for a certain field. And additionally the user has to select "Filtered HTML - no WYSIWYG" input filter manually.

Better Formats has very little overhead in my experience, though for this use case I would not need it.

Try the Wysiwyg force linebreaks module instead and optionally set the editor to be disabled by default. (Wysiwyg 6.x-2.2 and 7.x-2.0 also fixed the option to let users choses the default state on their user form for editor profiles configured to allow that.)

That will allow you to use the Linebreak converter filter and have the editor automatically convert them to the proper tags and back again when needed.

Subscribing (I realize it's closed but you never know):
Am I to understand that this function (permanent disable for specific fields like block fields) will not be a part of WYSIWYG?

I switched to WYSIWYG about 6 months ago and I'm used to being able to do this with TinyTinyMCE. Now I use TinyMCE as my WYSIWYG editor of choice and would like to be able to turn off a specific list of admin type textfields.

@awasson, I count the "truly" admin-type textfields in Drupal as those which don't have a format selector and perhaps use filter_xss_admin() for displaying the results instead of check_markup(). Due to the relationship with formats, editor profiles in Wysiwyg will naturally not "bind" to those fields. If other fields are to be considered only accessible by admins, I strongly suggest using a special format for them. You don't need to assign an editor to it, and users without permissions to use that format will not be able to edit the fields it has been applied to (D7 handles that part better, but it's still possible in D6).
If the field on which format availability needs to be controlled is a CCK textfield, I'd suggest trying the latest patch for Better Formats in #350696: Per field format settings with full BF options via CCK widget.

If you're writing a module which applies complex processing to input from a special field, and it's something WYSIWYG editors are unlikely to be able to handle well even with plugins, we've recently re-added the #wysiwyg FAPI property. Setting it to FALSE will make Wysiwyg skip the field completely. Note however it hasn't been included in an official release yet.

@TwoD, thanks for the reply. You've got me thinking that in D7 I should be able to deal with this with its more granular input formats and yes, I have used BF in D6 so that should be a good solution there as well.

BTW: I'm a huge fan of WYSIWYG. I used TinyTinyMCE and FCKEditor before I discovered WYSIWYG and it really is the best of solutions. Thanks for all the work!

@TWoD: I have the latest -dev of wysiwyg module and trying to disable the editor using
$form['field_bla']['#wysiwyg'] = FALSE; or $form['field_bla'][0]['#wysiwyg'] = FALSE; but neither works.. am I missing something?

And reading the discussion above, it's ridiculous to say that there is no use case in having this kind of control.. you might not always want multiple editors per page.. and one just needs to be able to control these things.. for some reason CKEditor offers a brilliantly user-friendly approach to this while here I can only see some weird arguments. Anyway.

We re-implemented support for #wysiwyg => FALSE in D7 only.

Given a manual test + confirmation of the patch in #33, this may have a chance to be contained in the next official release, which we plan to do very very, very soon. Thus, if you want this, please test now.

patch applied, only it doesn't really work.. when I dump the $field at that point, it seems to have no #wysiwyg attribute set, even though I do so using hook_form_alter in a module.. possible issue with processing being done before/after something or some module weights?

thanks

Tested manually myself, works fine.

@arski: You're likely trying to set the property on a CCK field... that most likely requires some workaround, since CCK sets a #process on the form element, which expands or may even replace the original form element.

Thanks for reporting, reviewing, and testing! Committed to 6.x-2.x.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

hmm, so, any chance to make it work for CCK fields? Which is indeed the thing I'm using.

It also works for CCK fields. You merely need to figure out the right location and time to assign the #wysiwyg property. I've forgotten about CCK's weird field widget processing logic already (which took several weeks to clean up for D7), so perhaps someone else on this issue can help out.

Hmm, tried it with #after_build on either form or element, but either way the #wysiwyg just doesn't make it to the final stage where this module checks the attribute.. grr.. If someone could give me a hint it would be greatly appreciated! Thanks!

could someone please chime in on how to actually use this fix for CCK fields? Thanks a lot!

Have you tried the UTIL module? You can enable module weights. Then weight your custom module heavier than CCK widgets. This eliminates the need for #after_build in some cases. In some cases I can't get any attributes added via hook_form_alter to show up using #after_build.
http://drupal.org/project/util

The support for #wysiwyg in D7 doesn't seem to work when you just do $form['field_bla']['#wysiwyg'] = FALSE in a hook_form_alter. wysiwyg_pre_render_text_format() isn't actually called at all on my node edit form in my test, I'm not sure why.

UPDATE: never mind, figured out what I botched: it needs to be set at the correct level, which is $form['field_bla']['und'][0]['#wysiwyg'].

Hi,

What stage is this at for Drupal 7? Is it possible to enable/disable on a per field basis?

Many thanks, Joe

@tirdadc's solution in #43 works for me, too, on Drupal 7. I didn't realize you need to set #wysiwyg on the ['und'][0].

Here's an example I'm using for the node form for a content type with the machine name 'closedquestion'. (As a work-around for #1334452: ClosedQuestion JavaScript error makes changing options impossible - happens with WYSIWYG enabled.)

Hopefully this snippet might help others formulate their own form_alters for this:

/**
 * Implements hook_form_FORM_ID_alter(). Works on DRUPAL 7.
 */
function MYMODULE_form_closedquestion_node_form_alter(&$form, &$form_state) {
  // Don't let the WYSIWYG appear for our Question Directions field. Any WYSIWYG
  // appearing on the node edit form breaks Closed Question's JavaScript-based
  // XML editor: http ://drupal.org/node/1334452
  $form['field_question_directions']['und'][0]['#wysiwyg'] = FALSE;
}

#45 - seemed like it would be cool if that easy; but not working so far.

i wanted to add W to term description field so added this in a form_alter

  if ($form_id == 'taxonomy_form_term') {
    $form['identification']['description']['format'] = filter_form();
  }

i can see it has added the filter formats array but nothing on my form has changed including no input format selector (not if that's expected). http://screencast.com/t/2XWNDv97

@liquidcms I'm assuming you're on Drupal 7. I don't know for sure but I think you have to change the field's #type to 'text_format'. See the forms API reference for text_format.

actually, this was for D6; but will check if something like that is required here as well. thanks.

This is not working for in D6. Not sure where I am going wrong with this. Any help?

function video_form_form_video_node_form_alter(&$form, &$form_state) {
	$form['#field_info']['field_video_embed']['#wysiwyg'] = FALSE;
}

edit: the value is being set correctly and the array has been checked with print_r()

I can confirm the technique in #26 from smk-ka works for D6.

Needed to do this as a field for one of my nodes had a WYSIWYG editor on it for about 6 months when it shouldn't. Enabling "plain text" screwed with my views as even with "filter HTML" set in the view, the raw html that had already been entered by users still came through in the display.

Regardless, I still actually wanted that field to use the Filtered HTML input filter, setting it to "plain text" seemed like a hack to me.

Better formats only gives me per-node settings but I need per-field settings. Arguably this is definitely a feature request for CCK rather than WYSIWYG but it is nice to know that the 'wysiwyg' => FALSE method doesn't work at all for CCK but setting the access restriction for the format element in a after_build callback does.

Sad to see so many people struggling with this when the solution is available about halfway through this thread :(

Building on #26 and #51, this custom module worked for me on a CCK field in D6...

function MODULENAME_form_alter(&$form, $form_state, $form_id) {
  // target content type is called 'resource'
  if ($form_id == 'resource_node_form') {
    $form['#after_build'][] = 'resource_node_form_after_build';
  }
}

function resource_node_form_after_build($form, &$form_state) {
  // target field name is 'slideshare1'
  $form['field_slideshare1'][0]['format']['#access'] = FALSE;
  return $form;
}

Did anyone have a solution for this on Drupal 7?

It's a reall annoyance.

@Sigvard try https://drupal.org/project/wysiwyg_exclude_field

To be honest, I have not yet seen a use case for a feature like this to exist in the core module itself. If a module writer for some reason makes a field format enabled without actually allowing the user to use the tools they've configured for that format, they can set the #wysiwyg property and have Wysiwyg module ignore it (which on its own is very confusing to some users since it in every other way still looks like a regular format enabled field). If the module does not set the property, a patch can be submitted. If the patch isn't accepted, which would be even stranger, a custom module can take care of it, as seen above.

If all else fails or you can't create a custom module, we now have wyswyg_exclude_field.module thanks to jygastaud. Hence, I'm finally closing this support request. (For D6/CCK, the solution by TimeBandit in #52 could be merged into a D6 version of wysiwyg_exclude_field with very little effort.)

I forgot to thank you.

Thank you!