WordPress.org
Get WordPress

Make WordPress Core

Opened 5 weeks ago

Closed 4 weeks ago

#63541 closed defect (bug) (worksforme)

TinyMCE scripts not loaded when WYSIWYG fields are present in metaboxes with Gutenberg enabled

Reported by: webhamster23's profile webhamster23 Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 6.8
Component: Editor Keywords: has-test-info
Focuses: Cc:

Description

Summary:
When using custom metabox WYSIWYG fields (e.g. via Advanced Custom Fields or other meta box frameworks), TinyMCE often fails to initialize properly when Gutenberg is enabled, and post_type_supports('editor') is false. This results in broken or empty editors (e.g. iframe with empty <body></body>) and uninitialized editor instances.

Steps to reproduce:
Use a custom post type (or page) with 'editor' => false in supports

Add a WYSIWYG field via ACF (or another plugin using wp_editor() in a metabox)

Enable Gutenberg (Block Editor)

Visit the edit screen and inspect the rendered WYSIWYG field

Expected:
TinyMCE should initialize correctly and load the expected editor interface

Actual:
Editor iframe appears blank or fails to load content. No errors in the console other than n is null in tinymce.min.js. The WYSIWYG appears unusable.

Notes:
This works without issue when:

Classic Editor is enabled (with block editor disabled via use_block_editor_for_post_type)

Gutenberg is manually disabled for the post type

wp_enqueue_editor() is forced AND post_type_supports('editor') is set to true

Affected plugin examples:

Advanced Custom Fields (WYSIWYG field inside Flexible Content or Metabox)

Proposed Improvement:
WordPress should not assume that post_type_supports('editor') === false means TinyMCE is unnecessary

If wp_editor() is called in the request (or known WYSIWYG metaboxes exist), load the editor stack

Alternatively, provide a filter to force editor script loading when Gutenberg is enabled

Suggested Workaround:

<?php

add_filter('use_block_editor_for_post_type', function ($use_block, $post_type) {
    return in_array($post_type, ['page', 'custom_post_type']) ? false : $use_block; }, 10, 2);

Environment:
WordPress 6.8+ and 6.7.2

Tested with ACF Pro 6.2.4 and 6.4.2

Happens across multiple installs, themes, plugins

Kind regards

Attachments (1)

Bildschirmaufnahme 2025-06-11 112047.mp4​ (8.7 MB) - added by webhamster23 4 weeks ago.
Screenrecording of the issue

Change History (8)

#1 @ravigadhiyawp
5 weeks ago

  • Keywords has-test-info added

Reproduction Report

Description

This report validates whether the issue can be reproduced.

Environment

  • WordPress: 6.8.1
  • PHP: 8.2.23
  • Server: nginx/1.26.1
  • Database: mysqli (Server: 8.0.35 / Client: mysqlnd 8.2.23)
  • Browser: Chrome 137.0.0.0
  • OS: Windows 10/11
  • Theme: Twenty Twenty-Five 1.2
  • MU Plugins: None activated
  • Plugins:
    • Advanced Custom Fields 6.4.2
    • Test Reports 1.2.0

Actual Results

  1. ❌ Error condition not occurs (not reproduced).

Additional Notes

Steps which I have follow:

  • Add custom post type with code and remove 'editor' support from that post
  • Create one WYSIWYG editor field and show in on create custom post type using ACF (Free version)
  • Add filter hook in theme to enable the Gutenberg editor for created custom post type
  • I can see the WYSIWYG editor in custom meta fields is still properly loading without any fail.

Supplemental Artifacts

Screenshot: ​https://prnt.sc/epoioWzxLxvD

#2 @ravigadhiyawp
4 weeks ago

  • Keywords reporter-feedback added

@webhamster23
4 weeks ago

Screenrecording of the issue

#3 @webhamster23
4 weeks ago

Dear @ravigadhiyawp ,

thank you for your effort. It might be worth to mention that we are using ACF Pro and in repeater and flexible content fields if that matters. It also doesn't seem to occur on all websites with similar website or sometimes it works 1 out of 10 cases. It also seems that it works better in Chrome than Firefox. I have uploaded a Screen recording in the attachement where the error is reproduced in Mozilla Firefox 139.0.1 (64-Bit). If you wonder why the browser is reloaded - that is because I would like all fields as WYSIWYG editor and don't save "mixed" field contents.

Kindly let me know if there are any questions.

#4 @ravigadhiyawp
4 weeks ago

  • Keywords needs-testing added; reporter-feedback removed

#5 @SirLouen
4 weeks ago

  • Keywords needs-testing removed

@ravigadhiyawp I can see no patch here. Needs a patch for needs-testing
And first, maybe, it needs some triaging.
Perhaps you can comment about this, this evening in the triaging session?

#6 @webhamster23
4 weeks ago

Hello @SirLouen,

thanks for your contribution.

The triaging request is for @ravigadhiyawp or me ?

I am happy to provide more details if needed. Just let me know.

#7 @SirLouen
4 weeks ago

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

@webhamster23 no I'm just saying that first someone needs to do a Bug Reproduction report, for this report to be triaged, then it needs a patch, and once we got all these, the needs-testing workflow keyword can be place here.

From you, reading overall the info you provided, the fact that you want us to reproduce this with a paid plugin like ACF Pro is something not ideal. First you must follow some simple ​troubleshooting steps to make sure there is no plugin conflict.

I recommend you, first of all, ​to go here and try to reproduce it there. If you can find a way to reproduce this consistently, bring it here with detailed instructions.

Judging by your screencast, I can see errors in shortpixel processor Javascript.

There could be a million causes but this is not a support forum. As I say, go into WordPress Playground, and try to make it happen, come back when you achieve it. For now, I will close this as worksforme for not being reproducible.

Note: See TracTickets for help on using tickets.