[wp-trac] [WordPress Trac] #19320: wp_tiny_mce() cannot call wp_editor(), and other issues
wp-trac at lists.automattic.com
Mon Nov 21 22:02:42 UTC 2011
#19320: wp_tiny_mce() cannot call wp_editor(), and other issues
Reporter: nacin | Owner:
Type: defect (bug) | Status: new
Priority: highest omg bbq | Milestone: 3.3
Component: Editor | Version:
Severity: blocker | Resolution:
Comment (by azaozz):
Replying to [ticket:19320 nacin]:
> IMO, we need to make it an absolute priority to make WP_Editor a
standard object that is instantiated for each editor.
We've been over this a few times now. There's no point instantiating it
for each editor instance. The different instances of the editors are in JS
not in PHP. It works exactly like WP_Scripts or WP_Styles (we don't
instantiate new WP_Scripts for each wp_enqueue_script).
The only reason it is a class is to keep track of what has been outputted
already and to allow lazy loading. The first can easily be done with
globals (although not the best way). The second cannot be easily done with
loose functions, so if we want to get rid of the class we will have to
include them on every page load. That's not good since these functions are
needed less than 0.001% of the time.
There is no reason for it to follow OOP patterns, WP's code is not OOP and
including a "standard" class is usually redundant.
> Anything that is static in terms of general initialization, rather than
specific to a single instance of an editor, should be just that —
In these terms all functions in WP_Editor are static. It doesn't make
sense to have more than one instance of them. There's nothing to be gained
from that, except it will "look" like OOP code.
> A bunch of functions, such as wp_fullscreen_html(), wp_link_dialog(),
and wp_link_query() were deprecated and merged into WP_Editor. This makes
sense if and only if these methods are going to then leverage the
individual editor instances.
All these functions **have to ignore** the number of editor instances.
They should be run once per page load. They were kept as separate function
as not all of them need to be run all the time an editor is included.
> But, I recently confirmed, all they do is render generic content. They
should be marked as static class methods, or even better, reverted to
become standalone functions until it makes sense to bring them into a
Yes, they work in exactly the same way as in 3.2. The only reason they are
in a class is to facilitate lazy loading, see above.
Ticket URL: <http://core.trac.wordpress.org/ticket/19320#comment:3>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac