Does this module support disabling edtior via the #wysiwyg FAPI attribute?
Dave Reid - October 13, 2008 - 21:43
| Project: | YUI Rich Text Editor |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Description
Simple question. I'm the developer of the FeedBurner module and I've had problems before with a textarea in my module's settings being replaced with WYSIWYG editors, and will cause problems if that is done. I've been using the following to make sure no WYSIWYG editor overrides my textarea:
<?php
$form['mytextarea'] = array(
'#type' => 'textarea',
...
'#wysiwyg' => FALSE,
);
?>This action is supported by the WYSIWYG project, FCKeditor project, etc. Just wondering if YUI editor supports the same, or if you have any alternative method to ensure a textarea is never overridden?
#1
Anyone?
#2
There are no instances of the string "wysiwyg" in the yui_editor module code, so I would say that the answer to your first question is "No."
As for your second question, it depends on the particular textarea you're trying to protect. As long as you can distinguish it by "id" attribute (which should be unique per-page), then the answer is "Yes." The yui_editor only loads for one or more selected id's (default is "body-edit"). So if you have custom CCK textarea fields, it won't show up.
The main problem I see is when you're using an input format (such as "PHP code") that's incompatible with a rich-text editor.
Hmm.... Shouldn't be too hard to add another configuration textfield for "content-types" (blank means match all)... I'll work on it. Fortunately the code is clearly-written, so I can see exactly where I'd need to make the change.
#3
Done; here's the patch.
To apply:
cd $DRUPAL_SITE_ROOT/sites/all/modulescvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -r DRUPAL-6--1 -d yui_editor contributions/modules/yui_editor
wget -O - http://drupal.org/files/issues/yui_editor_fixes_2.diff | patch -p0 -d yui_editor
#4
Realized I solved a different problem than the one you're concerned with. Re-posted a separate issue at #328686: Activate YUI editor on per-content-type basis. Sorry for the dup here.
#5
I'll see if I can whip up a little patch today.
#6
Problem is that the decision whether to load the editor is made in the hook_init() call, at which point none of the form information is available.
If the "#wysiwyg" flag is visible to Javascript, then it's doable by wrapping the javascript call that initiates the editor; otherwise probably not.
#7
Maybe the hook_form_alter should be used?
#8
I needed to remove TinyMCE from the comments field. I already had a custom module set up with a form_alter function, so I modified that.
function my_module_form_alter($form_id, &$form) {if ($form_id['#id'] == 'comment-form') {
$form_id['comment_filter']['format'] = array();
}
}
I've posted more details and discussion on why I chose this method on my blog.