[wp-trac] [WordPress Trac] #35243: Extending the text widget to also allow visual mode

[WordPress Trac]

#35243: Extending the text widget to also allow visual mode
-------------------------+------------------
 Reporter:  paaljoachim  |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  4.8
Component:  Widgets      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |     Focuses:
-------------------------+------------------

Comment (by azaozz):

 Replying to [comment:24 westonruter]:
 > @azaozz also I understand that without #35760 it isn't currently
 feasible to make the full featured WP TinyMCE editor available in the Text
 widget since it currently requires `wp_editor()` to be called in PHP for
 each instance...

 Not quite. `wp_editor()` was made so plugins can add an editor exactly the
 same as the "main" editor, with the same features, plugins and UI. Once
 TinyMCE is loaded on a page, we can initialize (from JS) as many instances
 of it as we need.

 This is currently not supported as separate option in `wp_editor()` as
 that function also outputs the HTML around both editors. If that HTML is
 generated in another way, we can initialize an unlimited amount of other
 instances (as long as the browser has enough memory/CPU power), either
 with the same configuration or different.

 > Nevertheless, one key feature of the Text widget visual editor would be
 the WP Links interface which isn't part of vanilla TinyMCE.

 Yes, one of the harder things would be to add the (old) wplink dialog as
 it is external to TinyMCE. The new inline link would work properly as it
 is essentially a TinyMCE plugin.

 > Do you or @iseulde have recommendations on the JS code required to
 dynamically create new basic editors as mocked by @melchoyce?

 Until #35760 is done, the best way would be to load wp-tinymce.php or
 tinymce.js directly the same way as in class-wp-editor.php:
 https://core.trac.wordpress.org/browser/tags/4.7.1/src/wp-includes/class-
 wp-editor.php#L1245 including the translated strings. Then initialize it
 with a "mostly hard-coded" init settings. It will still need
 `tinyMCEPreInit` object with `baseURL` and `suffix` properties that come
 from PHP.

 Most of the actual init options should be filterable only in JS. Think
 this is the better option as if we use all available PHP filters from
 class-wp-editor.php, the Text widget instance of the editor will end up
 affected by most WordPress plugins that are meant only for the main
 editor.

 Once the init options object is created (and filtered), we can initialize
 as many editor instances as needed. Note that the editor, once
 initialized, cannot be moved in the DOM. This is a security limitations
 for iframes in all browsers. If moving is necessary, it has to be
 unloaded, then initialized again.

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