[wp-trac] [WordPress Trac] #19173: Issues with wp_editor() when used inside of a meta box.

WordPress Trac noreply at wordpress.org
Tue Sep 15 15:09:19 UTC 2015


#19173: Issues with wp_editor() when used inside of a meta box.
--------------------------+-----------------------
 Reporter:  goto10        |       Owner:  azaozz
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:
Component:  Editor        |     Version:  3.3
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+-----------------------

Comment (by mboynes):

 > - Safe the content and destroy the editor instance on dragStart, then
 initialize the editor again and load the content on dragEnd. This is more
 complex and will make the dragging somewhat hard as processing and saving
 the editor content can be slow.

 I've tried that, and it provides a crummy UX. The editor disappears and
 leaves an HTML-filled textarea on drag. In [http://fieldmanager.org/
 Fieldmanager], we [https://github.com/alleyinteractive/wordpress-
 fieldmanager/blob/master/js/richtext.js#L58-L95 reinit the editors] after
 [https://github.com/alleyinteractive/wordpress-
 fieldmanager/blob/master/js/richtext.js#L151-L153 the user drags them].
 This way, TinyMCE sticks around for the drag, which is much less confusing
 for users. In terms of performance, this seems to work well (though I've
 never tried it on an older machine).

 It would be nice if there were a more elegant solution, but this is the
 best I was able to come up with, and it works. To @azaozz's point, this is
 a solution I implemented on the plugin level, and I didn't think much of
 needing to do so. I don't think that core necessarily needs to support
 this behavior, but I also wouldn't oppose it.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/19173#comment:24>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list