#26183 closed defect (bug) (fixed)
Calling quicktags *after* initial setup results in an empty toolbar
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 4.8 | Priority: | normal |
Severity: | minor | Version: | 3.7.1 |
Component: | Editor | Keywords: | has-patch needs-refresh dev-feedback needs-testing |
Focuses: | Cc: |
Description
Quicktags.js has a limitation in that if you call quicktags on a textarea after it has been previously been initialized it fails to attach buttons.
To reproduce this bug, go to a post editing page and bring up the console and attempt to call quicktags on a textarea, like:
quicktags({id:"metavalue", buttons: "strong,link,em"});
The expected result is a quicktags toolbar with buttons, instead you get an empty toolbar. This is because of the following lines:
if ( !qt.instances[0] ) { qt.instances[0] = qt.instances[id]; _domReady( function(){ qt._buttonsInit(); } ); }
Because qt.instances[0] has been set, it fails to continue on to rendering the buttons on a new textarea.
This strikes me as a bug, or at least an unnecessary limitation. I stumbled against this when trying to add a quicktag enabled textarea dynamically.
Attachments (1)
Change History (10)
#2
@
11 years ago
I've had this problem for years! http://wordpress.stackexchange.com/questions/44993/use-quicktags-toolbar-on-any-textarea I wasn't able to track it down or I might've reported it... instead I just thought I was going crazy.
Now that I've come back to my problem code, I've found a very similar issue with the
if ( tinyMCEPreInit.mceInit[ id ] && tinyMCEPreInit.mceInit[ id ].wpautop ) { txtarea_el.value = t.wpautop( txtarea_el.value ); }
in switchEditors()
. I've gotten around it by using javascript to add my settings for my dynamically added textarea to the tinyMCEPreInit.mceInit object.
// my_settings can be whatever, but I've cloned them from the #content's settings var settings = $.extend( {}, my_settings, { selector : "#" + id } ); // add our copy to the collection in the tinyMCEPreInit object because switch editors tinyMCEPreInit.mceInit[id] = settings;
So if the quicktags did at least the same as the tinymce if ( tinyMCEPreInit.mceInit[ id ] )
we could hack our way around it.
If there is an add_Instance(settings)
added for quicktags, it'd be great to have that added to tinyMCE as well!
Changing the offending code to this actually seems to resolve it for me (assuming a similar hackish way of adding to the qtInit property):
if ( qt.instances[id] ) { _domReady( function(){ qt._buttonsInit(); } ); }
#3
@
11 years ago
I took a stab at an add instance method and coupled with the above change seems to allow for the dynamic addition of quicktags editors.
qt.addInstance = function(settings) { if( 'id' in settings ) return qt.instances[settings.id] = settings; };
Now to got figure out how to make a patch.
#4
@
11 years ago
- Keywords has-patch needs-refresh dev-feedback needs-testing 2nd-opinion added
Any movement here? this seems like a no-brainer to me.
#5
@
10 years ago
What's the status on this?
How comes this was reported 16 months ago, fixed 12 months ago, and then ... nothing? This prevents me from using a fully functional wp_editor with AJAX.
#7
@
10 years ago
- Keywords 2nd-opinion removed
- Milestone changed from 4.2 to Future Release
Patch still needs a refresh, no meaningful activity in about a year. Punting.
@azaozz: Feel free to pull this one back for 4.2 if an updated patch is created in time.
Thanks for the report. Looks lie Quicktags will need an
addInstance( settings )
method to handle this properly.