[wp-trac] [WordPress Trac] #19320: wp_tiny_mce() cannot call wp_editor(), and other issues

[WordPress Trac]

#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:
 Keywords:                   |
-----------------------------+------------------

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 —
 `static`.

 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
 class.

 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