[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