![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
#26183 closed defect (bug) (fixed)
Calling quicktags *after* initial setup results in an empty toolbar
| Reported by: | PeterRKnight | Owned by: | azaozz |
|---|---|---|---|
| Priority: | normal | Milestone: | 4.8 |
| Component: | Editor | Version: | 3.7.1 |
| Severity: | minor | Keywords: | has-patch needs-refresh dev-feedback needs-testing |
| Cc: | Focuses: |
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
@
12 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
@
12 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
@
12 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
@
11 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.
Thanks for the report. Looks lie Quicktags will need an
addInstance( settings )method to handle this properly.