TinyMCE will not enable if it does not see the id on the hidden form field if there is only one format available or form is being hidden.

This patch adds the id to the hidden form field in better_formats_filter_form.

CommentFileSizeAuthor
#1 add_hidden_field_id.patch623 bytesdavegan
add_hidden_field_id.patch391 bytesdavegan
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

davegan’s picture

Project: Better Formats » Wysiwyg
FileSize
623 bytes

new patch - added missing variable declaration.

EDIT (Important): Problem was only seen on comment form, not on node forms.

TwoD’s picture

Project: Wysiwyg » Better Formats

This should go in the Better Formats queue as that's what the patch is aimed at.
For the record, the regular filter_form function does not do what this patch does for Better Formats, and yet Wysiwyg + TinyMCE works fine without the id when there are no radio buttons.
I'm not sure how this patch would have any effect. Fields with '#type' => 'value' only uses two keys, '#type' and '#value' and it's completely internal to the FAP (never represented by anything visible to the client), so TinyMCE couldn't benefit from this patch.

Could you please explain in more detail why this is needed?

dragonwize’s picture

An example of how to reproduce the issue would be nice as well.

I use the (WYSIWYG + TinyMCE + Better Formats) combo in almost all of my sites and have not seen an issue so I have not been able to reproduce this. In fact I gave a live demo last month on Better Formats for a training class on Drupal Formats with a clean install and everything went fine including the time when I showed that you could limit or hide the formats to force a format to be used and it worked perfectly. Also as TwoD said, there has been a large effort to ensure that BF works the same way core does that way modules including WYSIWYG work well with BF. Any additional modules that modify your formats or node form you have enabled would be nice to know as well.

davegan’s picture

haven't tested extensively, will try to do more when my current project is complete and I have time. thought i'd submit the patch in case anyone else was having similar problems.

Should have mentioned the problem only occurred on the comment form - was late last night when I submitted the patch.

Problem didn't occur when there were multiple formats available, or if Better Formats was disabled.

dragonwize’s picture

Project: Wysiwyg » Better Formats
Status: Active » Postponed (maintainer needs more info)
quicksketch’s picture

I'm struggling with the same problem. WYSIWYG works great when there is more than one format or when Better Formats is disabled. I should be capable of getting this working, but for some reason this is thwarting me. The WYSIWYG settings get added to the page as JSON, seems that the JS just doesn't start processing the textarea if there's only one (hidden) format available.

dragonwize’s picture

I just tested again on my sandbox site and did not have any issues with wysiwyg editor showing up when forcing only one hidden format both on the node and on the comment box. There has to be another factor that is not being mentioned or found.

TwoD’s picture

Yes, that sounds likely. On the site(s) where you can reproduce the issue; are there any "wysiwyg-"-prefixed classes on the div normally holding the format description? (When a single format is available.) There should be an empty div to hold these "parameters" even if the descriptioms are disabled via Better Formats.

quicksketch’s picture

are there any "wysiwyg-"-prefixed classes on the div normally holding the format description?

That seems to be the source of the problem. WYSIWYG finds the format in the FAPI structure and adds the settings to the page, but the format description div is never printed out at all (meaning the "wysiwyg" class on it is also missing). So the WYSIWYG JavaScript then can't activate the editor.

quicksketch’s picture

Well, after an afternoon of trying to reproduce this problem, the solution became entirely too obvious. Turns out it wasn't the fault of Better Formats (directly) at all. It was Dev Seed's Rubik admin theme. I should have figured it was responsible, since it does all kinds of things to the input format selection to "clean it up". I'll file a separate issue in the Rubik queue (wherever that lives).

quicksketch’s picture

dragonwize’s picture

@davegan: Are you using Rubik as well?

TwoD’s picture

Oh, Rubik, there's already an issue about that - #933222: rubik_filter_form() breaks WYSIWYG functionality.

davegan’s picture

@dragonwize: Nope, I'm not, but I suspect that it's a similar problem to quicksketch. I've got a lot of theme customizations so it will just be a matter of working through that. This is probably safe to close for now.

dragonwize’s picture

Status: Postponed (maintainer needs more info) » Closed (duplicate)