Gutenberg classic editor block is not showing custom mce buttons

[junixdev]

After updating to the latest WP 5.0 beta, the custom mce buttons are not showing up anymore in the classic editor block of Gutenberg.

This is still showing when using latest production version of WP and with Gutenberg version 4.3.0 plugin.

Steps to replicate this:

1. install latest WP 5.0 beta
2. install ThirstyAffiliates plugin, or any plugin that adds custom mce button
3. Edit post
4. add classic editor block to Gutenberg editor
5. issue: custom mce button is not showing

[junixdev]

latest WP with Gutenberg 4.3.0

[junixdev]

WP 5 beta editor (missing custom mce button)

[knutsp]

I see the same problem after testing Classic Block. Plugins add buttons here.

[pento]

Thank you for the bug report, @junixdev!

@azaozz: Could you have a look at this, please?

[azaozz]

Sure.

Edit: Uh, I'm not seeing stuff, sorry :)

@junixdev could you re-test without the Gutenberg plugin and in the Classic editor please. May need to install the Classic Editor plugin.

(Also, always clear browser cache before testing the editor!) :)

[junixdev]

@azaozz yeah I'm using WP beta without Gutenberg or the classic editor plugin installed/activated. custom mce buttons are not showing up for me.

[azaozz]

The problem is that the TinyMCE settings filters for the classic block are in wp_default_packages_inline_scripts() (here) which runs on the action wp_default_scripts (here), which is fired as soon as class WP_Scripts is initialized and then at init 0 (here).

Previously they were running quite later, near the end of the page where the TinyMCE scripts were printed. Looks like any plugin that is adding these filters at init or later will be affected.

Seems we will have to move that "down" again, and will have to echo the wpEditorL10n init object. Won't be able to use add_inline_script(), etc. At this point may be easier if we just reuse class-wp-editor.php to output that, no need to duplicate the code? Or can make another function in script-loader just for that and echo the settings on a later action? @pento @atimmer any ideas/thoughts?

(BTW why is it called wpEditorL10n anyway?) :)

[pento]

45338.diff​ moves the TinyMCE settings filter to run later.

Here's a cut down version of what the ThirstyAffiliates plugin is doing, which "works" (generates the appropriate error, that it couldn't find foo.js) with the patch.

<?php
add_action( 'init', function() {
        add_filter( 'mce_external_plugins', function( $mce_plugins ) {
                $mce_plugins['foo'] = 'foo.js';
                return $mce_plugins;
        } );
        add_filter( 'mce_buttons', function( $buttons ) {
                $buttons[] = 'foo';
                return $buttons;
        }, 5 );
} );

This is still earlier than edit-form-advanced.php runs these filters, but well after init. @azaozz: are you aware of anyone adding hooks to these filters between init and when edit-form-advanced.php calls wp_editor()?

[azaozz]

Replying to 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 here. It accepts an array for tinymce that overrides the default settings, 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 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 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 (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 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 :)

[azaozz]

Added #45348, #45350 and #45351 as follow up.

[azaozz]

As far as I see this works well. It makes these filters run "somewhere in the middle of the body HTML" :) Couldn't find plugins that fail after 45338.diff.

[pento]

In 43901:

Block Editor: Load TinyMCE inline scripts later.

Previously, the TinyMCE inline scripts were added on the init action in the block editor. In the classic editor, however, these scripts are loaded when the TinyMCE window is printed, and some plugins rely on them being loaded later, so they can attach to the appropriate filters.

See #45338.

[SergeyBiryukov]

In 44251:

Block Editor: Load TinyMCE inline scripts later.

Previously, the TinyMCE inline scripts were added on the init action in the block editor. In the classic editor, however, these scripts are loaded when the TinyMCE window is printed, and some plugins rely on them being loaded later, so they can attach to the appropriate filters.

Props pento.
Merges [43901] to trunk.
Fixes #45338.