[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