[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 [comment:4 nacin]:
 > 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.

 So is the editors "enqueueing". At first, when starting to code it was a
 multi-instance class, but later dropped that in favor of the same design
 like WP_Scripts. WP_Editor does nothing more than enqueue html, js and css
 for the editor instances. It enqueues several components for each
 instance, similarly to WP_Scripts that enqueues several scripts for each
 wp_enqueue_script() to satisfy dependencies and doesn't enqueue the same
 script twice.

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

 Think the only thing that stops this at the moment is user_can_richedit()
 which expects the user to be logged in. That works the same way as
 the_editor() in 3.2.

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

 I'm sure we can make it work as "proper" OOP class. My doubts are if we
 really need that / what are the benefits of making it more complicated. It
 is a simple semi-private class that has to be called from an external
 function to load. If in the future we decide to change it, there will be
 no problems maintaining back-compat in that function like instantiating it
 multiple times, etc.

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

 Lazy-loading seems to work best when used with one class = one file. Of
 course we can break these functions apart and do `if ( !
 function_exists(...) ) include_once(...)` for each.

 BTW nearly done with making wp_tiny_mce() fully back-compat. Thinking we
 can use that code whether or not we change WP_Editor.

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