[wp-trac] [WordPress Trac] #37166: Correct way of rendering an wp_editor outside of the basic browser request cycle

WordPress Trac noreply at wordpress.org
Fri Jun 24 15:11:26 UTC 2016


#37166: Correct way of rendering an wp_editor outside of the basic browser request
cycle
--------------------------------------+-----------------------------
 Reporter:  andreiglingeanu           |      Owner:
     Type:  defect (bug)              |     Status:  new
 Priority:  normal                    |  Milestone:  Awaiting Review
Component:  Editor                    |    Version:  trunk
 Severity:  normal                    |   Keywords:
  Focuses:  administration, template  |
--------------------------------------+-----------------------------
 We all know what you need to do in order to get a tinyMce editor that's
 quite like standard post editor - call
 [https://github.com/WordPress/WordPress/blob/4.5.3/wp-includes/general-
 template.php#L2845 wp_editor()] and you'll get all you need in order to
 just get it working. Easy peasy.

 The problems start to arrive when you try to achieve more dynamic like
 that. Multiple editors on the same page, editors that are actually
 generated dynamically on the page and things like that.

 `wp_editor()` function (and its
 [https://github.com/WordPress/WordPress/blob/4.5.3/wp-includes/class-wp-
 editor.php _WP_Editors]) are very hard to use when you're trying to really
 separate the steps that its doing.

 Specifically, `_WP_Editors`, which is private btw and I should not know
 about it, is mixing settings generation with passing data to JavaScript
 and HTML building.

 I had to do a
 [https://github.com/andreiglingeanu/Unyson/blob/10b326ff5dcfacb41b637f192eed92df36a798dc/framework/includes
 /option-types/wp-editor/includes/class-fw-wp-editor-settings.php#L14 some]
 [https://github.com/ThemeFuse/Unyson/blob/10b326ff5dcfacb41b637f192eed92df36a798dc/framework/includes
 /option-types/wp-editor/includes/class-fw-wp-editor-settings.php#L158
 really]
 [https://github.com/ThemeFuse/Unyson/blob/10b326ff5dcfacb41b637f192eed92df36a798dc/framework/includes
 /option-types/wp-editor/includes/class-fw-wp-editor-settings.php#L225
 crazy] manipulations in order to just get some preinit data for the
 `tinyMCEPreInit.mceInit` and `tinyMCEPreInit.qtInit` JavaScript global
 variables. That's just plain wrong. There should be some entity that would
 give me this settings parsing functionality and it should not be some
 strange and private class like `_WP_Editors`.
 [https://github.com/ThemeFuse/Unyson/pull/1682 Here's] the whole story of
 it, by the way.

 Is there something that can be done with all of this? How can I help?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/37166>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list