WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#37166 closed defect (bug) (maybelater)

Correct way of rendering an wp_editor outside of the basic browser request cycle

Reported by: andreiglingeanu Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Editor Keywords:
Focuses: Cc:

Description

We all know what you need to do in order to get a tinyMce editor that's quite like standard post editor - call 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 _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 some really 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. 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?

Change History (5)

#1 @azaozz
4 years ago

  • Focuses administration template removed
  • Milestone changed from Awaiting Review to Future Release

wp_editor() is meant to make it (very) easy to output the exact same editor like on the Edit Post screens, including TinyMCE initialization, Quicktags/Text editor, etc.

You can also use it to output multiple editor instances with different configuration on the same screen, as long as you need them to be pretty similar to the Edit Post editor.

If you need to use TinyMCE in a different way like inline instance(s), dynamically added instance(s), in a modal, etc. you would generally need to initialize it yourself. In its current state wp_editor() is not meant to handle all the different ways TinyMCE can be used.

On the other hand it's time to look again at wp_editor() and see how we can improve it so plugins can make better use of it. Ideas and example patches welcome :)

#2 @ocean90
4 years ago

  • Version trunk deleted

#3 @andreiglingeanu
3 years ago

@azaozz Thanks for looking into that!

Hey, I'm sorry for late reply to this thread!

But, in the meantime the hacks I used to do some time ago turn out be pretty stable. We shipped it live in this
[plugin](https://wordpress.org/plugins/unyson/) and we received no problems other than some autop glitches, which are easily fixed. That is 8months of stable usage with 50k+ installs for Unyson. This shit is working pretty fine :)

I haven't really looked for ways to improve the situation with wp_editor for plugin editors because I'm not sure how to deal with backwards compatible changes and I'm really afraid to break anything in the core.

For now, it looks like I'm fine with what we currently have but I may come with more changes, as requirements will arise.

#4 @andreiglingeanu
3 years ago

  • Resolution set to maybelater
  • Status changed from new to closed

#5 @netweb
3 years ago

  • Milestone Future Release deleted
Note: See TracTickets for help on using tickets.