Standard attribute name disallowing rich-text in textareas

+1 for this

+1 for standardization, tinyMCE, FCKeditor, Quicktags and many others may benefit

use cases please

I think the use case is that when using WYSIWYG editors, node/add/page's body textarea should be WYSIWYG-enabled, and admin/settings/user's e-mail body textarea should not. Right now, there's no way to differentiate between the two.

However, I don't like this implementation idea.

1. It's not "Drupalish" to stick unused properties in for contrib modules. That relationship should be the other way around (contrib modules should be able to add properties to core).
2. It sticks cruft in core that not everyone will use (not one site I admin uses WYSIWYG editors, and I am totally fine with that)
3. Whether it defaults to true or false, almost every module on the face of the planet is going to have to implement this property in one form or another, either to turn it off or turn it on for certain fields.

A better way to do this might be to build in a feature to the Form API to allow modules to dynamically register properties. Something like a hook_form_properties(). Then there could be a wysiwyg.module in contrib that would hook_form_alter all node bodies and other known places and adds a '#wyswiyg' => TRUE property, and TinyMCE, FCK, and others could require the use of that module in order to know where they should apply.

+1 for allowing modules (and sub-modules especially regarding CCK) to define whether a textarea CAN'T render rich.

Thought quite some time about this issue and IMHO it is necessary to do the opposite - define for which textareas rich-text isn't allowed. In most of my Drupal installations I end up with removing the pre-defined paths of TinyMCE and allowing rich-text editing site-wide for all registered users or specific user roles. On all of those sites I face the same problem: RTEs are well placed, except of some weird areas which were not built for and never thought of being rich-text.

Look at the project module: A project description can surely be rich-text, whereas the Components textarea (for defining one Component per line) - even with disabled RTE - becomes garbage upon reload since line breaks aren't converted proper - due to the re-activated RTE. User saves - Component list trashed.

This property has to be supported by the Forms API, so any kind of module - including custom text fields in CCK - is able to declare whether a textarea can be rendered rich. This should be a optional property.

It is not necessary to give admins or users control over these field settings since we have to deal with mistakenly rendered textareas in terms of usability. General availability of rich-text editing can be controlled by different editor profiles (as of [leading?] TinyMCE).

By speaking of that, TinyMCE provides a method for controlling textarea replacements (http://tinymce.moxiecode.com/tinymce/docs/option_editor_deselector.html).

#wysiwyg = true for fields that you always want to have a rich text editor
#wysiwyg = false for fields that you never want a rich text editor
All other fields will be handled as they are now - maybe even a flag in the richt text editor settings saying:
[] Optimistic mode: show editor for fields without #wysiwyg / Cautious mode: don't show editor for fields without #wysiwyg

1. It's not "Drupalish" to stick unused properties in for contrib modules. That relationship should be the other way around (contrib modules should be able to add properties to core).

Uhm we have #resizable and #collapsible .. why not #wysiwyg?

Because #resizable and #collapsible are used by core. #wysiwyg is not.

I agree a flag for never use wysiwyg on this area is the one needed.
These are the only cases I've had to go trawling through some great xpath-like pattern to disable the editors from totally screwing up configuration fields.

Because #resizable and #collapsible are used by core. #wysiwyg is not.

Ok, that is true

Still I'd love to have a standardized #wysiwyg flag, it makes life easier for wysiwyg addon modules

+1 for standardizing this sort of flag on text areas. However, it seems like this could be standardized wthout adding anything to the Froms API by specifying a XHTML class attribute?

$form['mytext'] = array('#type' => 'textarea', '#attributes' => array('class' => 'no-wysiwyg'));

pwolanin, I totally agree with you. As for TinyMCE this would work, since

tinyMCE.init({
	...
	editor_deselector : "no-wysiwyg"
});

and

<textarea id="myarea1" class="no-wysiwyg">This will NOT be replaced.</textarea>

would be enough to disable the editor for particular fields.

But what we need here, is a standardized behaviour - so every module can rely on it. I don't know if we really need any support from core team for realizing this - though I would certainly feel better with that... since this extension would affect any rich-text contrib module for Drupal.

Also I think I'd prefer a tag named "no-rte", since WYSIWYG is of a bit more meaning. We're dealing with a rich-text editor which is a RTE abbreviated, so the corresponding class name should be "no-rte", too, or even cleaner "disable-rte".

I don't know if we really need any support from core team for realizing this...

Right, this was my point -- I don't see an extra attribute getting into core unless core uses it in some way, which it won't, since core has no innate support for a wysiwyg editor (and shouldn't, in order to keep the flexibility to be able to edit text however you like).

What I was thinking instead is that this could actually be done with one central module, say, "rte_fields.module" or "wysiwyg_fields.module" or whatever you'd like, which the various rich-text editors would require. It could be co-managed by each of the rich-text editor contrib maintainers.

The module would consist of one large hook_form_alter implementation for core, which added the appropriate attributes onto the appropriate fields. include files could be present for handling other, non-core contrib modules as well, perhaps, to keep the logic from getting unwieldy.

And actually, maybe the logic isn't even that complicated. Maybe it's just, "does this textfield have an input format associated with it, and is it NOT the PHP input format? If so, enable it for wysiwyg editing." This would then work for CCK fields, too.

@webcheck - I'm obviously missing something, since it seems like this is really an area that just requires collaboration/documentation to set a standard, rather than any new hooks or code, right?

If contributors of editors agree on an attribute, and that's standardized, and documented (and publicized) other contrib modules that have special fields can take advantage of it. Maybe the only sticking point comes if/when more of CCK gets into core. However, even in that case the editor contrib module could implement the necessary hook_form_alter (or use another method) to avoid the forbidden territory that's part of core.

Of course, you can do this in template.php for TinyMCE along with specifying which paths can/can't use TinyMCE:

function phptemplate_tinymce_theme($init, $textarea_name, $theme_name, $is_running) {
  switch ($textarea_name) {
    // Disable tinymce for these textareas
    case 'log': // book and page log
    case 'img_assist_pages':
    case 'caption': // signature
    case 'pages':
    case 'access_pages': //TinyMCE profile settings.
    case 'user_mail_welcome_body': // user config settings
    case 'user_mail_approval_body': // user config settings
    case 'user_mail_pass_body': // user config settings
    case 'synonyms': // taxonomy terms
    case 'description': // taxonomy terms
    case 'components': // project module
    case 'help': // project module
      unset($init);
      break;

    // Force the 'simple' theme for some of the smaller textareas.
    case 'signature':
    case 'site_mission':
    case 'site_footer':
    case 'site_offline_message':
    case 'page_help':
    case 'user_registration_help':
    case 'user_picture_guidelines':
      $init['theme'] = 'simple';
      foreach ($init as $k => $v) {
        if (strstr($k, 'theme_advanced_')) unset($init[$k]);
      }
      break;
  }

  /* Example, add some extra features when using the advanced theme. */

  // If $init is available, we can extend it
  if (isset($init)) {
    switch ($theme_name) {
     case 'advanced':
      // ...
      break;
    }
  }

  // Always return $init
  return $init;
}

But it isn't totally accurate as it just goes off the field name and not the actual instance of the field, so you could have a "log" on one page where you want an editor and another where you don't. Close, but a wysiwyg_form.module could be a good place to have a running list for hook_form_alter().

At the moment FCKeditor (cvs) uses a similar approach, only that the excluded textareas are set in the administration settings for the module.
This fieldname based approach has a serious drawback; some fields have the same name, what if I want to enable the node body, but not the message body for an email...

A whole extra module to manage the fields seems really overkill, since core might not even need to include anything except an extra classname for textarea's -- there are unused classnames in core right -- this would be enough for most RTE and meet the request for standardisation.

@FredCK: I think you misinterpreted the tough answer style of webchick. Core will support what it has to support to make things work for all reasonable use cases.

You're right: A management by RTE modules or by one RTE controller module is too late. Look how many modules are released per week. Contrib modules and also core modules have to use a standard for disallowing RTEs for particular fields.
So the support question for Drupal core team is:

What should be the standardized class name for textareas that must not be replaced with a rich-text editor?

If this question is answered, all modules (including core [look at /admin/settings/user...] and RTE contrib modules can rely on this class name. This includes custom CCK fields, too.
If a contrib module alters the behaviour of a field of another contrib module and needs a RTE, it is able to remove the class name with form_alter.

Changing subject and category. Although this could already apply to 4.7, I'm leaving CVS.

Form API totally disregards unknown attributes so there is nothing to stop you from writing a wysiwyg_editor framework module which would handle a #wysiwyg attribute for textareas with an UI and so on. I think htmlarea of old had something in this. I do not see core getting this.

Here's why -- there would be an endless debate for certain forms and rightly so. I can't even imagine a textarea in core where WYSIWYG can be ruled out.

@chx: We're talking about a standardized class name, not a field property. Please reconceive, we badly need a standard here.

I don't see how a form property or a class name changes the result here. The answer is for the various RTE module contributors to collaborate together and come up with a single set of rules for said classes, and include them in a single contrib module which all will then use. It's basically the same approach that most voting-style apps use; they rely on the Voting API module to provide core functionality, such as score calculation and storage. Once it's proven in contrib, and once someone actually home-rolls a RTE rather than relying on third-party apps, we might be able to revisit including it in Drupal in a future release. Groups.Drupal.org might be a good spot for this to happen.

However, I'll leave this active until chx has a chance to review again.

All the better if there is no text field in core that needs to use this class attribute. Then the only way this discussion affects "core" is that we should add the information to the handbook in the module developers guide, and to the FAPI documentation.

Most RTE have a function that just scans a html page for textareas with a certain attribute (class, custom attribute etc.) and then replace the textarea's that fit the rule (similar to sIFR that only changes certain headings)
This way of checking a page and modifying it client side is considered to be degrading gracefully for clients that do not support the RTE...

One way to check if a textarea is a candidate for RTE replacement would be if a format is associated with it... but not always. Sometimes you know your textarea will work with HTML, even without a format enabled and other times you know you do not want a textarea to be replaced by a RTE ever...

That's why module maintainers would benefit from having a standardized attribute (in whatever form #wysiwyg=true #no-rte=true class="wysiwyg") without api call's and people having to maintain a full module to manage it all. This would effectively remove the need for an extra module that site maintainers need to install, have to update, must manage, can whine about etc.

@chx: any textarea that feeds input to the drupal mail handling should be without RTE, unless core enables html mail

BTW, the reason why an attribute in FAPI would be usefull is that some RTE use form alter to insert the code for initializing the rich editor... and a class needs to be present for moduels that scan the html and dynamically replace the textareas.

so it must be an attribute that is visible on the code level to php, as well as on the html output level to javascript - similar to #resizable and #collapsible

Does there need to be a separate FAPI attribute for this? Using my example in #13, at the PHP level it seems as though this should work (obviously real code would be iterating over each of the form elements):

if (isset($form['mytext']['#attributes']) && in_array('no-wysiwyg', $form['mytext']['#attributes'])) {
  //make sure not to add the editor to this form element
}
else {
  //enable the editor
}

I'd like to try to clarify some things:
When core devs argue against a new Forms API attribute, are they aware of the fact that the attribute itself is a mere standardization (ie. a name for the attribute) that we would agree on, and that the Drupal core wouldn't be touched at all?

Think of cck already supporting the new attribute and letting users select whether a textfield should be Rich Text or not, it would internally set $form['some_textarea']['#no-rte'] = TRUE; at some point.

TinyMCE in turn gets all textareas passed into its own callback tinymce_process_textarea(), which would then just check if the attribute exists and simply do nothing if it does.

So all we need would be settling on an attribute name, update the handbook with a bit of documentation and ask the editor maintainers to add support for it.

Moreover I'm not shure if all available RTE's support a (client-side) class name-based toggle, that's why I've adjusted the topic title.

Just my 2¢.

--
Stefan Kudwien
http://www.unleashedmind.com

When core devs argue against a new Forms API attribute, are they aware of the fact that the attribute itself is a mere standardization (ie. a name for the attribute) that we would agree on, and that the Drupal core wouldn't be touched at all?

No, because that is incorrect.

Let's say the property is called #rte-enable and it defaults to FALSE, meaning textareas won't be RTE-enabled unless specified.

Node body textareas in core need to be altered to have a '#rte-enabled' => TRUE property.
Comment textareas in core need to be altered to have a '#rte-enabled' => TRUE property.
// Repeat for all other fields that need their textareas to be RTE-enabled.

Or, let's suppose the property is called #rte-enable and it defaults to TRUE.

All textareas on settings pages in core must now be altered to have a '#rte-enabled' => FALSE property.

This property is cruft, as far as core is concerned. It is not used by core. It will in fact only be used by a small handful of contrib modules. It does NOT belong in core!

So please, guys, start a group at groups.drupal.org to discuss strategies around implementing a single framework that all RTE editors can rely on to tell which core and contrib textareas should be RTE-enabled.

@webchick - I was envisioning this as a supplement to the current methods the editors use (at least for tinymce, path-based) to avoid activating on the settings pages etc. It seems to me the real issue at hand is how to allow custom node types to declare certain fields to be off limits, rather than the issue being how to handle this for every form in Drupal.

To solve the problem of having to handle form items without the attribute set I came up with optimistic and pessimistic mode in #8

But according too your argument #resizable is cruft too... even when it is used in core, the fact that core happens to use javascript to do something with that attribute does not change the fact that the #resizable attribute is not essential to the function of a textarea and that modules must define it as false if they don't want a resizable textarea.

http://api.drupal.org/api/4.7/function/theme_textarea

function theme_textarea($element) {
  $class = array('form-textarea');
  if ($element['#resizable'] !== false) {
    drupal_add_js('misc/textarea.js');
    $class[] = 'resizable';
  }

  $cols = $element['#cols'] ? ' cols="'. $element['#cols'] .'"' : '';
  _form_set_class($element, $class);
  return theme('form_element', $element['#title'], '<textarea'. $cols .' rows="'. $element['#rows'] .'" 
   name="'. $element['#name'] .'" id="' . $element['#id'] .'" '. drupal_attributes($element['#attributes']) .'>'.
   check_plain($element['#value']) .'</textarea>', $element['#description'], $element['#id'],
   $element['#required'], form_get_error($element));
} 

@webchick: So we should use hook_form_alter for managing the resizable attribute too... right?

If we find a way to use a standardized attribute without extra code, for example with standardizing on a class attribute - the code for core will not be more or less hairy.

I like the idea of pwolanin in #13

$form['mytext'] = array('#type' => 'textarea', '#attributes' => array('class' => 'no-wysiwyg'));

In that case, In PHP I only need to check if #attribute['class'] contains no-wysiwyg and client side scripts will be able to check it too.. We only need to add a recommendatuin to the documentation for FAPI

-----------

Or if we include an extra attribute _form_set_class functions might be appended with another statement for including the extra attribute

http://api.drupal.org/api/4.7/function/_form_set_class

function _form_set_class(&$element, $class = array()) {
  if ($element['#required']) {
    $class[] = 'required';
  }
  if ($element['#no-rte']) { // rte attribute might be added
    $class[] = 'no-rte';
  } // end rte attribute
  if (form_get_error($element)){
    $class[] = 'error';
  }
  if (isset($element['#attributes']['class'])) {
    $class[] = $element['#attributes']['class'];
  }
  $element['#attributes']['class'] = implode(' ', $class);
} 

In this case we have added a few lines of code, and won't need an extra module, or an extra hook to be called

Core is right, this does not belong in core.
We will develop a new module "RTE field controller" (rte) that will add the attribute #rte with either TRUE or FALSE as value to specific textarea fields in Drupal core.

Contrib modules may provide that attribute for specific textareas by themselves. This can be discussed as feature request for that module for sure.

RTE module will need no administrative settings so far. Any additions to that might also be discussed as feature request.

Rich-Text-Editor module maintainers will have to implement a condition to their injections, to explicitly show (#rte = TRUE) or hide (#rte = FALSE) the editor for a textarea.

If time permits RTE module will be available within one week. If you want to help out, leave me a message.

Core might add this optional attribute to Forms API documentation at a later time, even though it isn't supported by Drupal core. Anyway, RTE module maintainers should include that info on their project pages.

@sun- I think you did not follow read the conversation completely. The idea is to standardize an attribute and ancourage contrib module maintainers of editors to look for it in their code. This does not require any additions or changes to the core code! The only change to "core" would be in documenting the standardized attribute.

No - core modules won't be altered, so their text-areas will remain the same. That is true for unwanted mis-placed rich-text-areas in core, too. So to prevent them, we need to develop a contrib module that does a form_alter on all core forms. The proposal was to name this module simply 'rte' and introduce a field attribute '#rte' that is either 'true' to force or 'false' to prevent a rich-text-editor from rendering (see posts above for their meaning). No further core support is needed. rte module should be co-maintained by current rte module maintainers since core modules and their forms might change from time to time and so rte module needs patches from time to time.

If rte module could also alter forms of contrib modules is another question which might be debated later on.
Didn't find the time yet(tm) to start with coding.

Here's an alternative proposal that may make this one redundent: http://drupal.org/node/87806

Just once more: I think there's no real chance to get core support for adding a handbook notice for an attribute that is not supported by Drupal core. If we'd have that info in core documentation, we could have all contrib module documentations in core documentation.

Core helping out for defining that one and only attribute term (f.e. '#rte') is a possibility - but there seems not much interest of core on that issue.

Thanks to Drupal architecture, naming is not a big deal - so the code can come first. And might be renamed later on. I definitely would like to see some votes from RTE module maintainers on the attribute term issue!

All contrib modules *are* documented in the handbook! http://drupal.org/handbook/config/contribmodules

Nothing to see here for Drupal core, move on. That "RTE field controller" might be a good idea, I also suggested it in the past but nothing of this belongs to core.

Just wanted to follow-up and say thanks, sun, for taking this on. I think once completed, rte.module will be a huge boon in centralizing this logic in a clean way.

I'm warming up to the RTE controller module idea, because it has the potential that admins can override the behaviour.

An #rte attribute used in all modules is a nice guideline, but what if I have an email/smtp method that handles rich text, and the module for that one email field tells me not to use RTE's ...

A module is also a practical way to make a standard that also works for modules where there's no rte attribute, and with the new dependencies it will be clearer to install too.

I agree that the lack of core support for the use of RTEs is a strike against Drupal in the current market. I don't like them personally, and I agree that for various reasons there shouldn't be a 3rd party RTE built in at this point, but core should at least make it less painful to hook in an RTE.

It looks like it's a no-go for core at this point though, which is unfortunate. If it can be developed as a a contrib module, though, develop it with intent to package into core in Drupal 6. Most core modules started that way. urlfilter just merged int Drupal 5, and CCK is slowly moving in bit by bit. Make sure this "RTE Helper" module is up to core's coding standards from day 1, and we can see about getting it moved into core next version. That would even let people leave it disabled if they wanted. That seems like the most reasonable way to proceed at the moment.

Do not hold your breath. All RTEs are producing broken HTML. So there is not much love lost for them...

I see the point about not cluttering core with properties not implemented in core. Personally I don't see the need for such a hard division. Certainly it would be premature to add anything to core at this point--we don't have a contrib standard to build on. If we reached the point where we have a broadly adopted and implemented approach in contrib, then it might be worth returning to consider support in core.

Here are relevant issues in fckeditor http://drupal.org/node/122008 and tinmyce http://drupal.org/node/119862.

This issue may also be related: http://drupal.org/node/125315

Since this topic is active the devel list, moving status back

IMO I would won't fix this and move efforts into 125315. The other issue is a feature request for a general property that can be used for lots of things (themes, etc.) in addition to WYSIWYG editors. #wysiwyg is just a hack.

Agreeing with webchick. As long as that issue is not committed to HEAD, the idea of a rte.module is still realizable for 5.x. Didn't have the time to code this module yet.

Finally. Moving over to wysiwyg queue.

I've posted a summarization of all follow-ups along with own thoughts in http://drupal.org/node/181825

I urge all editor/plugin module maintainers and everyone interested in this whole topic to participate in these efforts.
Start by reading what has been identified so far.