I'm running Drupal 7 beta1 and latest WYSIWYG 7.x-2.x dev (10/22/2010) and when only having the singular filter format, the editor doesn't show. There are no JavaScript errors and the JavaScript files are included in the header.

But as soon as I added a second filter format, both formats have corresponding editors (two separate editors so they were switching nicely). I guess the targeting mechanism may be a bit off when there is only a single filter format?

The two editors were TinyMCE and CKEditor


TwoD’s picture

Are you using the Rubik theme?
If so, duplicate of #947778: Rubik Breaks WYSIWYG when there is only one input format.

Alan D.’s picture

Sorry, I'm using Bartik clone that has no core modifications at this stage, simply some JavaScript includes for a inline MP3 player and a context menu.

I switched to Garland and disabled the second format. The editor didn't show.

I see "edit-field-description-und-0-format--2" in the Drupal.settings string for the trigger, but this doesn't map to any class or id in the HTML. The fieldset format ID is "edit-field-description-und-0-format" which maps to the settings.

I did see this, so the process has started, but something is preventing the complete init():

<input type="hidden" value="1" name="field_description[und][0][format]" class="wysiwyg wysiwyg-processed">

Let me know if any other info could be useful. The lowest common denominator is the different HTML that is rendered for a single format help fieldset.

Alan D.’s picture

I'm running as admin / uid 1, just in case this helps

Alan D.’s picture

And just found a related different bug. They appear to be related to the dynamically changing filter tips form, so I will not open a new issue.

I added a new filter format, as I needed the WYSIWYG. I had deleted the default format that was being used, so the filter options had a third option, 'select filter' or something similar when I tried to create a new page or edit an existing page with the same deleted format. The editors didn't show.

By saving the existing page with an existing format, then re-editting it, the editors appeared. Also, I had to resave the content type so that it would have an existing format in the field settings, (not the stale deleted one). Only after this, did the editors start working again on new content pages.

In both cases, there was a drop-down with the third option and no editors. After setting the new filter format, the editors appeared and the third option disappeared.

TwoD’s picture

Status: Active » Needs review
1.58 KB

Found the causes of the problems.
First; A field's id is no longer set via #id, we need to use #attributes instead.
This patch changes that in wysiwyg.module.

Second; If the active format is no longer available, the extra option added to the selectbox will have a blank value - as it doesn't represent an input format id.
Wysiwyg's clientside init code in wysiwyg.js will not process a textarea if its selectbox doesn't have a value. I've removed that "filter" in this patch so it'll attach our "none" editor instead, which will attach/detache the resizing functionality provided by Core.

A couple of quick tests reveled no downsides to this, but I might have overlooked some special case. Need to confirm this with Sun as he wrote that part.

Alan D.’s picture

First look is good, applied the patch and deleted the format and the editor appeared.

Nice work for looking at this so fast!


sun’s picture

Let's try this one. Possibly also fixes #934976: Provide method to hide input format fields without disabling WYSIWYG in one fell swoop.

TwoD’s picture

Status: Needs review » Reviewed & tested by the community

Knew I should have put nicer indents in there... ;)

Patch works great! Tested by allowing a role access to a single format (Plain text) with an editor set. Before the patch no editor was shown, with the patch I get the assigned editor.

sun’s picture

Status: Reviewed & tested by the community » Fixed

Thanks for reporting, reviewing, and testing! Committed to HEAD.

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

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.