[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 nacin):

 Replying to [comment:3 azaozz]:
 > 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).

 Yes, and those are classes architected specifically for the singleton
 pattern. The script-enqueueing process and the style-enqueueing process
 each happen, in total, once per page.

 Here we have multiple editors. There are very, very good reasons to ensure
 that the PHP class is instantiated individually for each editor. This
 includes the ability to properly extend it for a particular editor, and
 finely control various pieces and values. Additionally, it prevents us
 from having our hands seriously tied in the future.

 At WordCamp Philly, I tried my hardest to enable the visual editor for a
 non-logged-in user on the frontend. Due to the singleton pattern and
 singular array of arguments, I found it to be impossible. Not all
 arguments belong in JS only, far from it.

 I am far from a preacher of OOP patterns. But from a practical
 perspective, this makes sense not only now, but for maintaining and
 extending it for years to come.

 Anything that is meant to be static, can be static. We can make it so
 things only run once regardless of how many times it is instantiated. This
 is easy.

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

 The functions didn't need to be deprecated to facilitate lazy-loading.
 They could have been moved to wp-includes/editor.php. I sure hope no one
 was using them directly, because backwards compatibility was not
 maintained.

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