[wp-trac] [WordPress Trac] #45338: Gutenberg classic editor block is not showing custom mce buttons

[WordPress Trac]

#45338: Gutenberg classic editor block is not showing custom mce buttons
-----------------------------+---------------------
 Reporter:  junixdev         |       Owner:  (none)
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  5.0
Component:  Editor           |     Version:  5.0
 Severity:  normal           |  Resolution:
 Keywords:  has-screenshots  |     Focuses:
-----------------------------+---------------------

Comment (by azaozz):

 Replying to [comment:7 pento]:

 Can confirm 45338.diff fixes the above issue, the buttons and the TinyMCE
 plugin are added properly.

 > @azaozz: are you aware of anyone adding hooks to these filters between
 `init` and when `edit-form-advanced.php` calls `wp_editor()`?

 Not off the top of my head, however the editor is probably the most
 filtered part of WP :) I understand the desire to simplify and improve how
 it is enqueued and outputted for the classic block but that may bring some
 problems with plugins.

 Looking through class-wp-editor.php, there are several filters that are
 missing from (the new) `function wp_tinymce_inline_scripts()`.

 1. Most importantly the `wp_editor_settings` filter
 [https://core.trac.wordpress.org/browser/branches/5.0/src/wp-includes
 /class-wp-editor.php#L71 here]. It accepts an array for `tinymce` that
 overrides the default settings,
 [https://core.trac.wordpress.org/browser/branches/5.0/src/wp-includes
 /class-wp-editor.php#L673 here]. Thinking we should add that, both to be
 able to override the defaults and also some plugins may be using it to add
 the other settings filters. A quick GH search shows 47k hits for this
 filter (most are duplicated code, but still...).

 2. Perhaps we won't need to keep `the_editor_content` filter
 [https://core.trac.wordpress.org/browser/branches/5.0/src/wp-includes
 /class-wp-editor.php#L264 here]. We can't filter the classic block content
 through it, at least not in time. On the other hand it's been around from
 the very beginning, WP 2.1. A lot of hits on GH too (77k) but most seem to
 copy what core is doing: prepare the content for output in the editor
 textarea.

 3. IMHO we can skip the deprecated `richedit_pre` and `htmledit_pre`
 [https://core.trac.wordpress.org/browser/branches/5.0/src/wp-includes
 /class-wp-editor.php#L280 here]. Again, we have no `$content` to filter at
 that time.

 4. We would probably need to do the equivalent of
 https://core.trac.wordpress.org/browser/branches/5.0/src/wp-includes
 /class-wp-editor.php#L289. As the classic block instance is in a `<div>`,
 we need to force-encode any raw `</div` in the content. This is even more
 important if we don't filter the content with `add_filter(
 'the_editor_content', 'format_for_editor', 10, 2 )`.

 5. There are other (missing) filters for individual editor settings that
 have been around "forever". Thinking we can keep `disable_captions`
 ([https://core.trac.wordpress.org/browser/branches/5.0/src/wp-includes
 /class-wp-editor.php#L522 here]). It just passes a setting from PHP to JS.
 That seems to be used quite a bit too, according to GH search.

 6. Another one is `mce_css`
 [https://core.trac.wordpress.org/browser/branches/5.0/src/wp-includes
 /class-wp-editor.php#L541 here]. This is the "nicer" way of adding
 stylesheets inside the editor. Can be somewhat problematic as now these
 stylesheets will have to be added to the whole page (as the classic block
 instance is inline). Around 100k hits in a quick GH search.

 There are also some editor settings that are missing. It's true, no bugs
 have been reported yet but we may run into problems later. Looking through
 https://core.trac.wordpress.org/browser/branches/5.0/src/wp-includes
 /class-wp-editor.php#L933, there are a few WP specific (at the bottom)
 that should probably be in there. Also things like `keep_styles`,
 `end_container_on_empty_block` change the way the editor behaves. We
 probably want these. Also missing are some things that affect content
 "cleanup": `relative_urls`, `remove_script_host`, `convert_urls`,
 `entities`, `entity_encoding`, oh, and `browser_spellcheck` should be
 `true`.

 Ugh, this became a huge list, sorry. Better to split it in individual
 tickets. @iseulde could you have a look :)

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