[wp-trac] [WordPress Trac] #19906: Quicktags docs recommend code causing JS error: Uncaught ReferenceError: QTags is not defined

WordPress Trac wp-trac at lists.automattic.com
Fri Jan 27 16:42:38 UTC 2012


#19906: Quicktags docs recommend code causing JS error: Uncaught ReferenceError:
QTags is not defined
------------------------------------------------+--------------------------
 Reporter:  jeremyclarke                        |       Owner:
     Type:  enhancement                         |      Status:  reopened
 Priority:  normal                              |   Milestone:  Awaiting
Component:  Inline Docs                         |  Review
 Severity:  trivial                             |     Version:  3.3.1
 Keywords:  has-patch needs-codex dev-feedback  |  Resolution:
------------------------------------------------+--------------------------
Changes (by jeremyclarke):

 * status:  closed => reopened
 * resolution:  invalid =>


Comment:

 Hi Tobias, thanks for replying, but I don't think we should close this
 ticket. Whether your solution works or not, I think there is still a need
 for clarification in the inline docs because right now it encourages
 something that throws a javascript error which causes all kinds of havoc.

 We should decide on the clearest solution and refer to it in the docs and
 on the wiki.


 > the solution is much easier: You'll just need to enqueue the "quicktags"
 script before you add your footer print action. There's no need to enqueue
 a script that *depends*, you just enqueue "quicktags" directly.
 > {{{
 > wp_enqueue_script( 'quicktags' );
 > }}}

 This solution involves using two hooked functions instead of just one
 right? That's how I got it working but not really how you made it sound.
 Two hooked functions on the same hook seems unnecessarily complicated to
 me, though I can see how it is simpler for people who don't know JS at all
 and just want to use standard WP-PHP. Notably though, this method doesn't
 seem to work if you use the `admin_print_footer_scripts` instead of
 `wp_footer`, so if this is the official solution we need to be clear in
 the docs that you must use `wp_footer`.

 > The script would only be loaded on all pages if you don't use the
 correct hooks. Script enqueuing should only be done when you know that you
 are on your plugin's admin screen, e.g. in "load-{$plugin_hook}".

 The quicktags are intended for anything with `wp_editor()`, not for a
 specific plugin screen, so we can't assume that people will know what
 screen they want to add it to. In theory we could tell people all the
 different screens/conditionals that would imply the presence of an editor,
 but with the increasing proliferation of `wp_editor()` the buttons might
 be needed just about anywhere. If we go the route of telling people to
 enqueue quicktags we will pretty much have to tell them to enqueue it
 everywhere just in case, which is a waste IMHO.

 It seems like a good solution would be to just define the buttons all the
 time as long as it doesn't break anything when there's no editor, they
 don't take up much space after all. Checking if `QTags` is defined is a
 simple way to neutralize the javascript without having to worry about
 every possible scenario where it would be needed.

 Is there some way to know if `wp_editor()` was called during the current
 pageload? If we could know that with PHP then that would be the ideal
 solution, as it would truly be just one line of code in the
 `admin_print_footer_scripts` action to determine whether to output the
 button definitions or not. Alternately a footer hook that only fires if
 the editor was used during the current page, though that seems more
 convoluted than necessary.

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


More information about the wp-trac mailing list