Attach client-side editors to input format enabled textareas only

It is an awesome idea. Don't seems to be an easy task but it would bring the drupal integration to the next level.

Hell yeah! zoo33 was so nice to point me to WYMeditor module (which should not be used on production sites IMHO, btw), which implements something like that, but in a very limited fashion.

On a second thought, I recalled our perversions with Form API in #translatable, and thought: hey, why not simply parse the form parents?!

Soo...

Attached patch removes the "Visibility" configuration setting from Wysiwyg API's profile settings. Instead, each form is scanned for form elements that filter_form() can produce. If one is found, the FAPI #parents of the preceding form element are added to a stack of "matched elements". In turn, those matched elements (i.e. input format enabled textareas) are processed so that our neat JavaScript trickery can attach to them. 8)

Known issues: Patch checks for #type == 'fieldset' only, while filter_form() can also produce simple markup (also in "format").

Hi Sun,

I applied the patch and updated. I was able to make this work as you describe above...

But the problem is I now can't specify which pages to see the WYSIWYG editor on... I know this was by design, but...

Here's my immediate problem -- What about text areas that are set to use php input format? at the moment, the wysiwyg editor is called on those areas as well (like block body in a custom block) -- so it strips out my PHP :(

I could set the WYSIWYG editor to not show by default, but that would defeat the purpose of making it easy on editors to just edit a node and use the wysiwyg without having to click the 'enable rich text' link.

Is there a way to still allow us to limit which pages this displays on?

Thanks :)
Scott

I can see your issue and already thought about enhancing the current process for attaching editors to textareas, so that editors are invoked by the currently selected input format. However, I'd like to move on in atomic improvements/patches. First, we should get this one in shape. Afterwards, we can think about improvements...

...albeit there is one foreseeable caveat: We will not be able to easily determine the designated input format for textareas, when the user only has access to one input format (hence, no input format selector is displayed) -- or is this always FILTER_FORMAT_DEFAULT?

In that case, the patch seems to work as designed - for now ;)
I've tested on various user and admin areas of the site - so far so good. Do we need more testers to set this to RTBC?

sun, should we add this problem (the php stripping thing) as a separate issue then? I'm not sure that makes sense, because without this patch we'd be able to set which pages to attach / not attach the editor. How should we proceed?

I guess this is the kind of patch where you're unlikely to get a lot of good reviews. I don't know Wysiwyg good enough to review this properly, but you have my support!

Probably Ready To Be Committed(tm).

Taking this to the next level. YAY!

New features added:

- Editors are now bound to input formats.
- Invocation of editors is controlled by input formats. Preventing an editor to show up if an input format (f.e. PHP) has no editor associated.
- Default behaviors of Drupal core are now supported. Textareas are resizable again after disabling an editor. Implemented as the special editor "none".
- Reworked discovery of input format enabled textareas for performance.
- Editor toggle callbacks have been removed; toggling an editor via the "enable/disable rich-text" link means to remove/add an instance now.
- Simplified editor integration code due to all of this.

Todo:

- Plenty of documentation, explaining the how's and why's.

Next steps (probably separate issues):

- Implement a way to associate an editor/profile with an input format. Consider whether multiple editors/profiles per input format make sense at all. Remove access permissions per profile and rely on input format permissions otherwise. :)
- Rework JS settings structure (as outlined in the comments), so we can use multiple, different editors on a single page. The new JS code has built-in support for this already.

Many thanks to smk-ka, who first reviewed, then helped with this awesome rewrite.

Now with complete docs.

Please, can anyone confirm that this works? This is most probably the most incredible patch I have ever worked on 8)

Feedback on the docs would be awesome, too ;)

Testing patch in #8 -- my results...

Positive:
* If php input format is selected, the wysiwyg editor is not there - Yay!
* And when starting with php input (no editor) – if I change the input format to 'filtered html' for instance, the wysiwyg editor immediately shows up, and works. very cool!

Negative:
* The one problem I see is that the Disable rich text link does not work.

Questions:
* If I select 'php' while the editor is already present, the wysiwyg does not disappear again in the same way (not sure how necessary that is, but it does seem like that would make sense).
* If I then click 'preview' with php selected, the wysiwyg editor does disappear as expected (however, the php is stripped during the process - this may not be a problem, but letting you know how it works for me).

Otherwise (and overall), this works perfectly -- especially for the problems we were experiencing :)

PS - haven't updated to D6.5 yet -- still testing in 6.4 -- all other modules are up to date (as of yesterday anyway!)

Wow! Thanks for reviewing so fast!
Regarding your negative points and questions:

0 + 1) This worked for me. Maybe a browser caching issue? Which browser are you testing in? I used FF3/Win.
2) I did not test that, good point. It's possible that our Form API trickery does not use the posted value, but the default value again (ie. wrong data source). I'll look into this.

Are you on IRC? If you are, we might discuss/troubleshoot this faster - ping me aka. tha_sun.

Points 0 + 1 of your list should be fixed in attached patch. (Note, that those bugs applied to TinyMCE 2.x only)

So only 2) remaining.

Tested 2) now, but was not able to replicate it. My steps:

a) Go to node/add/story.
b) Set input format to PHP - editor should disappear.
c) Enter some contents into body.
d) Click on preview.
e) Page reloads - and body field does not have an editor attached.
f) Save content.
g) Edit content - body field still does not have an editor attached.

Test with TinyMCE 3.

Can you confirm?

Ok... sun, you saw this on IRC & email.. but for everyone else:
* Tested now with TinyMCE 2 & 3
* tested ad user/1 and also other users with role that has perms to use WYSIWYG...
* tried switching input formats, enabling and disabling rich text links in as many combinations as I could think of...
* checked text areas on different parts of the site (not exhaustive, but the areas I noticed problems before)...
and all works like a dream. Thanks sun!

Committed! 8)

I appreciate the work done so far, but I am running WYSIWYG API 6x.1.2 but still require the ability to limit whether the rich-text editor is available for specific content types. I am currently running CKEditor 3.5, and WYSIWYG profiles allows me to control whether "filtered" of "full" -html content types can use the editor.

Filtered and Full HTML does not give enough control. I'd prefer to be able control by content type too, is this possible?

Also, another feature I'd like to see is to turn off rich text editors when signed in as the admin (uid 1). Possible?

Thanks