Disable rich-text broken: jQuery Update required

I'm unable to replicate this bug. Could you please elaborate further? For example (but not limited to): Which version of Wysiwyg do you have installed, which version of jQuery is in use, on which page does this happen, aso.

Well, two caveats here:

- When using jQuery 1.2.6, jQuery Update module is required.
- TinyMCE 3.x is not yet supported, see #270780: TinyMCE 3.x support

Based on these details, I'll mark this won't fix, because the cause is clear and already known.

I'm having the same problem: The "disable rich text" (or "enable rich text") link doesn't work. I'm using Drupal 5.11 with WYSIWYG module 5.x-0.3 and jQuery 1.2.6 with the jQuery Update module 5.x-2.0. The editor appearance always stays with the default display option (on/off), but I can't change it through the link.

Since TinyMCE is supported now, I think this problem should be addressed again.

One more thing: The link that says "Disable rich-text" doesn't contain any href statement:

<a style="cursor: pointer;" id="wysiwyg4edit-body">Disable rich-text</a>

Using the TinyMCE module, it looks as follows:

<a href="javascript:mceToggle('edit-body', 'wysiwyg4body');" id="wysiwyg4body">disable rich-text</a>

This should be working in CVS. Hence, marking as fixed. Either wait for the next stable release or use the development snapshot if you can't wait. However, be sure to clear your browser's cache and RESTART your browser after updating the module. Unfortunately, those editor JS libraries tend to be cached regardless of the browser's cache state.

Thanks for the quick reply. 5.x-1.x-dev didn't solve my problem, actually it got even weirder. The Link only shows up below the body textarea, but not for the teaser (using the Excerpt module). Plus, when I click on it, the whole textarea disappears. Additionally I got a different error (maybe that helps you):

* warning: Invalid argument supplied for foreach() in /.../sites/all/modules/wysiwyg/wysiwyg_editor.admin.inc on line 359.
* warning: array_filter() [function.array-filter]: The first argument should be an array in /.../sites/all/modules/wysiwyg/wysiwyg_editor.admin.inc on line 364.

I'll wait for the next stable release then.

I am using 5.x-0.4, TinyMCE 3.2.02, disable works but when I enable the body textarea disappears.

sun wants me to test this on a clean site.

@yan: I'm unsure whether Excerpt module implements a second input format selector for the additional textarea. I guess not, since I believe its contents are just prepended and stored in front of the body field, separated by <--break-->... If this is the case, then Excerpt would be only known edge-case, which is incompatible to Wysiwyg API's approach of attaching editors to input formats. However, at the very least, there should appear an editor for the body field. Did you try 0.4 already?

Hi Sun,

I just tried 5.x-0.4 in a clean Drupal 5.11 install, but the problem is still the same. Installing it, besides the "Wysiwyg" module there is a module called "Wysiwyg Editor UNINSTALL" although I didn't have the older version of the module installed since it is a clean install. When I click on "uninstall", the module doesn't show up to be uninstalled. I guess this module should only be there if an older version was installed already.

Then, when I create a new profile, I get an error message:

* warning: Invalid argument supplied for foreach() in /.../sites/all/modules/wysiwyg/wysiwyg.admin.inc on line 361.
* warning: array_filter() [function.array-filter]: The first argument should be an array in /.../sites/all/modules/wysiwyg/wysiwyg.admin.inc on line 366.

When "Enabled by default" is checked, the problem with the rich text link is as follows:

• Editor shows on body field (not on excerpt)
• I can use the editor without problems
• When I click on "Disable rich-text", the editor disappears and I can see the html
• When I then click on "Enable rich-text", the whole body field disappears
• The body field doesn't show up again

When "Enabled by default" is not checked, the problem with the rich text link is as follows:

• The "Enable rich-text" link shows below the body field (not below the excerpt)
• When I click on "Enable rich-text", the editor doesn't show, but I can see the grey field to change the size of the text area (before it wasn't there); the text stays the same: "Enable rich-text"
• When I then click on "Enable rich-text" again, the whole body field disappears and the text changes to "Disable rich-text"
• The body field doesn't show up again

a) Yes, the Wysiwyg *Editor* (UNINSTALL) module is just for users of an earlier version. Will be removed in 0.5.

b) The PHP notice appearing when one adds a new profile is a known issue. It happens, because Wysiwyg tries to find buttons and plugins for the configured editor in a profile, but since it is a new profile, there is no editor configured yet. Will be fixed in one of the next versions. Aside from that, no harm by those messages; just re-edit the profile after creating it to add some buttons/plugins to the editor.

c) "Editor shows on body field (not on excerpt)": As mentioned in #11, it's perfectly possible that Excerpt may be an (or the?) edge-case, which cannot be supported by Wysiwyg, unless Excerpt implements explicit support for Wysiwyg.

d) "When I then click on "Enable rich-text", the whole body field disappears; The body field doesn't show up again": This should not happen. Does this also happen when Excerpt module is disabled?

e) "When "Enabled by default" is /not/ checked...": Admittedly, I never tested that. Another reason for dropping this option and replacing it with a more intelligent solution, treated over at #322433: Replace default editor status option(s) with intelligent logic. The current logic of this toggle link may lead to a reversed behavior if the editor is disabled by default. However, that should also be dealt in the other issue, and should not affect the overall functionality.

Long story short: I'd like to focus on d) in this issue.

EDIT: btw, b) is #320038: PHP notices when creating a profile

Regarding c), I don't think that's the case. Until now I have been using the TinyMCE Module and because of a problem with it, I discovered this module's approach. But in TinyMCE module, WYSIWYG editing of the (excerpt-) teaser was possible without any problems. So I guess it's not an Excerpt problem.

Regarding d): Yes it also happens without the excerpt module. I can't see any difference in the malfunction when Excerpt module is disabled.

Long story short: I'd like to focus on d) in this issue.

Yes, that looks like the main problem to me, too. Although Excerpt support is important for me too...

c) Maybe I have not communicated this sufficiently: Wysiwyg API uses a completely different approach than the obsolete TinyMCE module to detect whether an editor may attach to a textarea. Do you recall the "Visibility settings" fieldset in TinyMCE module's settings? That has been completely removed and replaced with a logic that automatically determines whether a textarea is input format enabled or not. In Excerpt's case, the module is dividing the very same body field into two textareas and only one of them is input format enabled (i.e. the regular body field, not the teaser field). That's because the contents of both fields are merged into one value after submitting the form and only that merged value is stored in the database. In turn, the database supports only one input format value for this field, so even if Excerpt would expose an input format selector for the teaser field, its value would have to be the same as the input format value for the body field. And that is why I am saying that Excerpt module is a hard edge-case and would have to implement special support for Wysiwyg API. Fortunately, if that won't happen, there are other workarounds for this issue, such as using CCK to add a *real* new teaser field to a node along with a proper input format value. Btw, this strange teaser/body input format handling issue has already been identified in http://groups.drupal.org/node/9072

d) If it also does not work with Excerpt module disabled, please test whether the editor works if you remove all buttons/plugins from the profile except 1-2 simple buttons, such as body + italic. If it does not, you might want to consider joining #drupal-wysiwyg in IRC to investigate this further (and live).

c) I think I understand what you're saying about Excerpt. Some thoughts though:

In Excerpt's case, the module is dividing the very same body field into two textareas and only one of them is input format enabled (i.e. the regular body field, not the teaser field). That's because the contents of both fields are merged into one value after submitting the form and only that merged value is stored in the database. (...) And that is why I am saying that Excerpt module is a hard edge-case and would have to implement special support for Wysiwyg API.

At least there is a field for the body and one for the teaser in node_revisions table. But ok, so that'd be an Exerpt issue. But if I understood correctly, the module is obsolete for Drupal 6 and above. I doubt that they'll do such major changes. But let's see.

Fortunately, if that won't happen, there are other workarounds for this issue, such as using CCK to add a *real* new teaser field to a node along with a proper input format value.

Is an input format selector automatically "assigned" to a CCK field that is a textarea?

d) Yes, it's exactly the same, also without Excerpt and just some simple buttons enabled. I'll visit IRC soon...

c) Excerpt has been deprecated for D6, because of the new teaser splitter functionality in Drupal core, which is a whole other mess. Current considerations for D7 are to remove the teaser splitter again. I'm not yet sure what we will have in D7, but in the case we'll have "fields in core", I'd currently predict that we'll have a separate teaser field finally, just like you can add via CCK today.

In CCK, you can configure whether the textarea should be input format enabled.

d) Any updates?

yan reported in IRC that installing jquery_update 2.x and updating jQuery solves this bug. So a module dependency is in order.

Committed attached patch now.

Committed attached patch.