[wp-trac] [WordPress Trac] #19098: QTags.addButton not working according to the docblocks

[WordPress Trac]

#19098: QTags.addButton not working according to the docblocks
--------------------------+------------------------------
 Reporter:  amereservant  |       Owner:  azaozz
     Type:  defect (bug)  |      Status:  reviewing
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  General       |     Version:  3.3
 Severity:  minor         |  Resolution:
 Keywords:                |
--------------------------+------------------------------

Comment (by amereservant):

 Replying to [comment:5 azaozz]:
 > If we make the Quicktags buttons depend on a PHP var/array, we could
 filter them the "normal" way (similar to how the TinyMCE buttons are
 handled). Was thinking about that earlier. The downside is that Quicktags
 stops being a self-contained script, i.e. it will have to always be used
 together with WP_Editor class.

 Well it wouldn't be any different from it currently relying on
 '''quicktagsL10n''', which is a localized variable created by PHP.  And
 like I mentioned above, it could still run independently ''(not sure why
 or when it would need to)'' from WP_Editor by checking if the buttons
 added by WordPress exist or not before beginning to iterate over them.

 Considering the fact quicktags.js is meant to be used with the editor, I
 don't know why integrating it to work with WordPress' WP_Editor class
 would be a drawback.  If someone wants to use quicktags.js for other uses
 than how it can be used in WordPress, then they can always download it
 from Alex's site.
 Making it integrate better with WordPress so users can further customize
 WordPress for their needs would seem to me to be the better choice since
 WordPress is meant to work together and yet provide a great deal of
 flexibility to the developer building upon it.

 Here's sorta what I was thinking starting at
 http://core.trac.wordpress.org/browser/trunk/wp-
 includes/js/quicktags.dev.js#L633, although this is a rough concept to
 show the idea because I'm not taking the scope of the settings variable
 into account:
 {{{
 if( typeof settings.buttons == 'undefined' ) return;
 for( i=0; i < settings.buttons.length; i++ ) {
     // If the keys are the priority order, this will need to be done
 differently...
     if( typeof settings.buttons[i] != 'undefined' ) {
         var curBtn = settings.buttons[i];
         edButtons[i] = new qt.TagButton(curBtn.id, curBtn.title,
 curBtn.arg1, curBtn.arg2, curBtn.accesskey);
     }
 }
 }}}


 I dunno, that's just my 2 1/2 cents on it.... with the '''quicktagsL10n'''
 variable being relied upon within the js already, I don't see where it'd
 make much difference.  A simple test for {{{ if( qtInit.buttons typeof
 'undefined' ) return; }}} before adding the buttons would make it just as
 flexible as now.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/19098#comment:6>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software