I am not sure if this is a bug or intended behavior, but I thought I would post just in case.
We just upgraded to the mode recent version of the module. Once we did the HTML editor in the Body field of nodes was not visible to any role except administrator. When we reverted the the previous version of the module the HTML editor appeared for all roles.
We upgrade the module again to the current release and unchecked the option Text format selection in the Nodes section of the configuration page. At that point the HTML editor appeared for all roles.
I originally had Text format selection in the Nodes section checked to hide the text format drop down under the Body field.
So, is hiding the HTML editor in the Body field the intended behavior if the Text format selection in the Nodes section is checked?
Comment | File | Size | Author |
---|---|---|---|
#2 | hide_text_format_with_CSS-2477343-2.patch | 437 bytes | BWPanda |
Comments
Comment #1
BWPanda CreditAttribution: BWPanda commentedHiding the WYSIWYG editor is certainly not the intended behaviour here. It seems that WYSIWYG's
wysiwyg_pre_render_text_format()
function doesn't like the missing text_format element.I was able to fix this by replacing a line of code in Simplify's
simplify_hide_text_format_element()
function:Replace
$element['format']['#access'] = FALSE;
with
$element['format']['#attributes']['class'][] = 'element-invisible';
(i.e. hide the element with CSS rather than through the Form API).
However this still makes WYSIWYG whinge about the missing element (don't know why), but the editor appears ok. I don't really want to make a patch for this change until I can work out/fix the WYSIWYG errors... Assistance greatly appreciated!
Comment #2
BWPanda CreditAttribution: BWPanda commentedOk, so I think the WYSIWYG errors were fixed in #2483393: Multiple notices and warnings when used together with wysiwyg.module, so now we can focus on getting the editor displaying properly again.
My solution above (using CSS to hide the text format selection field) seems to work, but I want to make sure it doesn't adversely affect anything else (such as the AJAX issue we recently fixed). I was hesitant to simply add a class which would then hide the field, but since that class is defined in Drupal's core System module, I don't think this'll be a problem.
Here's a patch of my above change that you can apply and test. Please let me know if anything stops working the way you expect, or if anything starts happening that shouldn't.
Comment #3
webservant316 CreditAttribution: webservant316 commentedPatch #2 appears to be working for me. Wow, I had this problem on my production site and didn't notice till today. Thanks for the fix!
Comment #4
Jim Bacon CreditAttribution: Jim Bacon commentedI am trying patch #2. No adverse effects noticed so far.
Comment #5
efruin CreditAttribution: efruin commentedPatch #2 solved the problem for me.
Comment #6
jelo CreditAttribution: jelo commentedPatch #2 worked for me as well...
Comment #8
BWPanda CreditAttribution: BWPanda commented