Opened 10 years ago
Last modified 4 years ago
#30942 new defect (bug)
In quicktags settings, setting buttons to zero-length string doesn't give empty toolbar.
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | 4.1 |
Component: | Editor | Keywords: | has-patch needs-refresh |
Focuses: | Cc: |
Description (last modified by )
This issue was raised on WordPress stackexchange http://wordpress.stackexchange.com/a/174086/57034.
If you set the buttons of the quicktags settings to a zero-length string, eg by using the 'quicktags_settings'
filter
add_filter( 'quicktags_settings', function ( $qtInit ) { $qtInit['buttons'] = ''; return $qtInit; } );
which typically results in the following setting in tinyMCEPreInit
qtInit: {'content': id:"content",buttons:""},'replycontent': id:"replycontent",buttons:""}}
then quicktags just ignores it and uses the default buttons, due to this falsey test on line 263 of "wp-includes/js/quicktags.js"
if ( settings.buttons ) { use = ','+settings.buttons+','; }
This can be worked around by using any non-falsey value in setting $qtInit['buttons']
but that's somewhat non-intuitive. The proposed simple patch tests for string type so you can use ''
(and also tests for boolean false
which is nice to have as well).
if ( typeof settings.buttons === 'string' ) { use = ','+settings.buttons+','; } else if ( settings.buttons === false ) { use = ' '; // Any old truthy string. }
Attachments (5)
Change History (10)
This ticket was mentioned in Slack in #core by jorbin. View the logs.
10 years ago
#3
@
9 years ago
30942_quicktags2.diff won't work well any more. Now the Quicktags toolbar is added from PHP. If no buttons it remains visible and empty, so needs to be hidden.
I'm still not sure how useful this is. Also, kind of easier to do with a little CSS :)
#4
@
9 years ago
Thanks for responding.
That's better, more understandable code, but personally would leave out the ed.toolbar.style.display = 'none';
bit as it leaves a blank gap instead of an empty toolbar (due to the margin-top on the textarea) and a) is ignored with the workaround version and b) I find the later more aesthetically pleasing :)
(It's useful in the sense that the filter will do what one expects.)
Proposed patch.