Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 UTC on 18 March 2024, to get $100 off your ticket.
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.
Comment | File | Size | Author |
---|---|---|---|
#1 | add_hidden_field_id.patch | 623 bytes | davegan |
add_hidden_field_id.patch | 391 bytes | davegan | |
Comments
Comment #1
davegan CreditAttribution: davegan commentednew patch - added missing variable declaration.
EDIT (Important): Problem was only seen on comment form, not on node forms.
Comment #2
TwoDThis 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?
Comment #3
dragonwize CreditAttribution: dragonwize commentedAn 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.
Comment #4
davegan CreditAttribution: davegan commentedhaven'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.
Comment #5
dragonwize CreditAttribution: dragonwize commentedComment #6
quicksketchI'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.
Comment #7
dragonwize CreditAttribution: dragonwize commentedI 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.
Comment #8
TwoDYes, 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.
Comment #9
quicksketchThat 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.
Comment #10
quicksketchWell, 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).
Comment #11
quicksketchFor Rubik users: #947778: Rubik Breaks WYSIWYG when there is only one input format
Comment #12
dragonwize CreditAttribution: dragonwize commented@davegan: Are you using Rubik as well?
Comment #13
TwoDOh, Rubik, there's already an issue about that - #933222: rubik_filter_form() breaks WYSIWYG functionality.
Comment #14
davegan CreditAttribution: davegan commented@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.
Comment #15
dragonwize CreditAttribution: dragonwize commented