TinyMCE editor not rendering correctly in visual mode using wp_editor function in a meta box on a page with the Block editor enabled in WP 5.9

[rickcurran]

Using the wp_editor function on a meta box on WP 5.9 with the block editor enabled on a page results in the TinyMCE editor not rendering correctly in Visual mode.

I note that there are several prior tickets about this same issue which unfortunately seem to have been unresolved due to being unable to be reproduced consistently: #52133, #52050, #53644.

Sadly I am also unable to reproduce this bug consistently either, I am experiencing it on both the development version and live versions of a particular site I'm working on at the moment, prior to the 5.9 update the wp_editor had been working correctly on both of these sites. As a test I made two clean installations on another server of both 5.8 and 5.9 with no additional plugins and a simple theme with metabox added to it and the wp_editor works correctly. So there is something specific about the particular combination of code in my site that is preventing the wp_editor from working in visual mode that didn't seem to be occurring before 5.9 for some reason, even though on these simple test installations they seem to be fine.

I am able to workaround the issue by the following steps: switch to the Text view tab in the wp_editor, refresh the page and then switch back to the Visual view tab. These steps were indicated in one of the previous tickets linked above.

The following is an example of the code I am using to add the metabox with wp_editor in it:

function tools_next_steps_metabox() {
	global $post;
	
	$custom = get_post_custom( $post->ID );
        $next_steps_links = isset( $custom[ 'next_steps_links' ][0] ) ? $custom[ 'next_steps_links' ][0] : '';
	
	echo '<ul>';
        echo '<li>This panel allows entering of text content for the “Next Steps” stage of the tool.</li>';
        echo '<li>';
	wp_editor( $next_steps_links, 'next_steps_links_id', array(
		'wpautop' => true,
		'tinymce' => array(
			'toolbar1' => 'bold,italic,bullist,link,unlink',
		),
		'media_buttons' => false,
		'quicktags' => array( 
			'buttons' => 'strong,em,underline,ul,li,link'
		),
		'textarea_name' => 'next_steps_links',
		'textarea_rows' => get_option('default_post_edit_rows', 10),
		'teeny' => true,
        
        ) );
	wp_editor( $next_steps_links, 'next_steps_links_id' );
        echo '</li>';
	echo '</ul>';
}

add_action( 'add_meta_boxes', 'render_page_metaboxes' );
function render_page_metaboxes() {
	add_meta_box( 'a_tools_next_steps_metabox', 'Next Steps', 'tools_next_steps_metabox', 'page', 'normal', 'low' );
}

I appreciate this is perhaps not the most helpful ticket but given that issue has been reported in the past there is obviously some circumstance where using metaboxes and the wp_editor on pages using the block editor results in the editor not getting activated on load when the wp_editor is in visual mode. On the pages where I have the error occurring I have tried disabling the block editor on those pages and the wp_editor works correctly when the block editor is disabled.

[burnside]

I'm seeing a similar issue on my dev site. The following line of code will produce a fatal error:

$args = array(
  'tinymce' => array(
    'toolbar1' => 'bold,italic,bullist,link,unlink',
   )
);
wp_editor( $editor_content, $editor_id, $args );

Error:

PHP Fatal error: Uncaught TypeError: call_user_func_array(): Argument #1 ($callback) must be a valid callback, function "tinymce" not found or invalid function name in /nas/content/live/dev/wp-includes/class-wp-hook.php:307

Stack trace:\n#0 /nas/content/live/dev/wp-includes/plugin.php(189): WP_Hook->apply_filters('html', Array)\n#1 /nas/content/live/dev/wp-includes/general-template.php(3519): apply_filters('wp_default_edit...', 'html')\n#2 /nas/content/live/dev/wp-includes/class-wp-editor.php(183): wp_default_editor()\n#3 /nas/content/live/dev/wp-includes/general-template.php(3547): _WP_Editors::editor('Abstract and bi...', 'content', Array)\n#4 /nas/content/live/dev/wp-admin/edit-form-advanced.php(604): wp_editor('Abstract and bi...', 'content', Array)\n#5 /nas/content/live/dev/wp-admin/post.php(206): require('/nas/content/li...')\n#6 {main}\n thrown in /nas/content/live/dev/wp-includes/class-wp-hook.php on line 307

[rickcurran]

Replying to burnside:

I'm seeing a similar issue on my dev site. The following line of code will produce a fatal error:

$args = array(
  'tinymce' => array(
    'toolbar1' => 'bold,italic,bullist,link,unlink',
   )
);
wp_editor( $editor_content, $editor_id, $args );

Error:

PHP Fatal error: Uncaught TypeError: call_user_func_array(): Argument #1 ($callback) must be a valid callback, function "tinymce" not found or invalid function name in /nas/content/live/dev/wp-includes/class-wp-hook.php:307

Stack trace:\n#0 /nas/content/live/dev/wp-includes/plugin.php(189): WP_Hook->apply_filters('html', Array)\n#1 /nas/content/live/dev/wp-includes/general-template.php(3519): apply_filters('wp_default_edit...', 'html')\n#2 /nas/content/live/dev/wp-includes/class-wp-editor.php(183): wp_default_editor()\n#3 /nas/content/live/dev/wp-includes/general-template.php(3547): _WP_Editors::editor('Abstract and bi...', 'content', Array)\n#4 /nas/content/live/dev/wp-admin/edit-form-advanced.php(604): wp_editor('Abstract and bi...', 'content', Array)\n#5 /nas/content/live/dev/wp-admin/post.php(206): require('/nas/content/li...')\n#6 {main}\n thrown in /nas/content/live/dev/wp-includes/class-wp-hook.php on line 307

I don't think this is the same as the error I have filed this ticket for, this sounds like you are seeing some kind of fatal PHP error where presumably the page isn't loading at all? That's not the error that this ticket is related to if so, I think you may have some other issue happening with your use of wp_editor.

[burnside]

I'll open up a new bug in this case. Thanks for your suggestion.

[sanderteirlynck]

We are also running into this issue using WordPress 6.0.2 and the wp_editor function inside classic metaboxes on post-types using the Block Editor.

When the page loads with the Visual mode active, I'm unable to use the Visual mode. When the issue occurs, the iFrame inside the editor has an empty header and body. As @rickcurran describes, switching to Text mode, reloading the page and switching back to Visual mode works consistently, as does Text mode. In my case, opening the developer tools to log the network traffic prevents the issue from occurring, for some reason.

It looks like the issue only occurs on Firefox. Not sure which browser @rickcurran uses, but I cannot reproduce the behavior on Chrome. I've been looking at the network traffic to see if the order in which scripts are loaded are to blame, but that doesn't seem to be the case (I've had sporadic times where opening the developer tools did not prevent the issue from occurring, letting me compare the network traffic).

I'm hoping @rickcurran can shed some light on which browser he uses, in hopes of pinpointing the cause of this issue and getting it fixed.

[rickcurran]

Hi @sanderteirlynck, my main browser is Safari on Mac OS, however, I've just checked the site where I was experiencing this issue and I can confirm that it still occurs in WP6.02 using Safari 15.6.1 on MacOS 12.5. I also experience the issue in Chrome 105 and also in Firefox 104.

Thanks,

Rick

Replying to sanderteirlynck:

We are also running into this issue using WordPress 6.0.2 and the wp_editor function inside classic metaboxes on post-types using the Block Editor.

When the page loads with the Visual mode active, I'm unable to use the Visual mode. When the issue occurs, the iFrame inside the editor has an empty header and body. As @rickcurran describes, switching to Text mode, reloading the page and switching back to Visual mode works consistently, as does Text mode. In my case, opening the developer tools to log the network traffic prevents the issue from occurring, for some reason.

It looks like the issue only occurs on Firefox. Not sure which browser @rickcurran uses, but I cannot reproduce the behavior on Chrome. I've been looking at the network traffic to see if the order in which scripts are loaded are to blame, but that doesn't seem to be the case (I've had sporadic times where opening the developer tools did not prevent the issue from occurring, letting me compare the network traffic).

I'm hoping @rickcurran can shed some light on which browser he uses, in hopes of pinpointing the cause of this issue and getting it fixed.

[osynligstefan]

We're also having this issue in conjunction with ACF. Happens only after upgrading WordPress to a version >= 5.9 and in different browsers.

Quote from ACF support:

"Thanks for the report here. This is likely a WordPress bug, and it's a tricky one to reproduce. Even on your site for me in Safari it's not reliable, and sometimes will render correctly, which points to it being a race condition in the loading chain somewhere.

We think it's likely to be an instance of this bug: https://core.trac.wordpress.org/ticket/55012 which can occur in any browser, and it seems likely to be specific to the other elements on the page, and the time they take to render."

[azaozz]

I am also unable to reproduce this bug consistently

the iFrame inside the editor has an empty header and body

This sounds like the same (old) problem: the browsers do not allow iframe nodes to be moved in the DOM. They get reset, even if the iframe "source" is local. I'm afraid there's nothing we can do to prevent this as it is a security feature/enhancement in the browsers.

The only possible fix is to delay initializing the editor until after any "DOM moves" on page load are complete. This was also the fix for some of the previous tickets. Another possibility would be to "lock" the postboxes and make them non-draggable. Was looking at doing this as an UI enhancement (make them draggable only when Screen Options tab is open) but it was blocked because of some very vocal opposition. I don't see a problem if a plugin does it though :)

Going to close this as worksforme because it seems to work in most cases/is pretty hard to reproduce. Feel free to reopen with a patch or new info on how to fix.