[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