#53644 closed defect (bug) (worksforme)
WPeditor not fully initialized in a classic metabox
Reported by: | dway | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 5.6 |
Component: | TinyMCE | Keywords: | needs-testing |
Focuses: | javascript | Cc: |
Description
Since WordPress 5.6, a call to wpeditor() in a classic metabox loads partially TinyMCE : the buttons seems to work, Text tab too, but visual edition stay white, without cursor or content (that you can add in the Text tab).
It's really close to #53632 but the only way to get the visual tab working is :
- edit a post
- click Text tab of tinyMCE
- reload page (CTRL-R)
- and then click on Visual tab
If the visual tab is the one showing first, it stays white.
I've also tried with the Changeset [51407], but the bug remains the same.
You can test it by adding the attached code to your theme or plugin, on a fresh install of WP.
Attachments (3)
Change History (14)
#2
@
3 years ago
Thx @azaozz for your reply.
I think I've found a clue. Weird one. I was testing locally, on macOS Big Sur with my classic dev stack (apache, php 7.4 and mysql from brew) which works perfectly for tons of other projects I developped, and then, just to be sure, I've tested on my production server (Debian 10), and the wp_editor loads normally...
I was thinking about something about loading time and file loading order, more slower on the online server than locally. But I've also tested with the bandwith limiter of Firefox dev tools, set on 3G, but, still, the bug is only showing up on local (wordpress-last.localdev).
Not really aware of the initialization process of tinyMCE, but if you can point me to some tests I should do, please let me know (like showing the real order of things to load).
#4
@
3 years ago
Is there a solution to this problem yet? We are experiencing the same problem. I made a simple setup: https://pastebin.com/W29gW6d8
The editor is visible. However, the content area remains white. It's also not possible to select the content area to start typing, etc.
I run the above on macOS Big Sur, with MAMP PRO version 6.3.2 (Apache/2.4.46, PHP 7.4.12).
#5
follow-ups:
↓ 6
↓ 7
@
3 years ago
Hello @peterverbrugge.
I've migrated my dev setup from Brew to Docker, and have no more problem of TinyMCE initialization.
There is something somewhere in the macOS config that breaks the correct loading of files (particularly CSS and JS). I've dug sometimes but without finding anything really noticeable.
SO I can only encourage you to change your dev setup and test !
@azaozz : I think this ticket should be closed, that's a really edge case, only occuring on dev env. What do you think ?
#6
in reply to:
↑ 5
@
3 years ago
Replying to dway:
Hello @peterverbrugge.
I've migrated my dev setup from Brew to Docker, and have no more problem of TinyMCE initialization.
There is something somewhere in the macOS config that breaks the correct loading of files (particularly CSS and JS). I've dug sometimes but without finding anything really noticeable.
SO I can only encourage you to change your dev setup and test !
@azaozz : I think this ticket should be closed, that's a really edge case, only occuring on dev env. What do you think ?
Ok, i see. I will see if I can find something else to test on then. Thanks for the support.
#7
in reply to:
↑ 5
;
follow-up:
↓ 8
@
3 years ago
- Milestone Awaiting Review deleted
- Resolution set to worksforme
- Status changed from new to closed
Replying to dway:
I think this ticket should be closed, that's a really edge case...
Yep, think so too. Thanks for clearing it out.
@peterverbrugge please feel free to reopen if you get to the bottom of it/find what can be fixed here.
#9
@
3 years ago
Ok, did a test this morning. I installed Virtualbox with a Windows 10 image. I tested the same custom posttype that is in rest mode with an extra editor and used Windows Edge. Still have the same problem.
The test was done an other laptop then my normal developer laptop.
Problem is still: after a record is opened to edit. De extra editor (wp_editor()) is blank. I can not use my mouse pointer to select the editor and start typing. When I switch to the "Text" tab in the editor, I can actually see the content that was save before when the posttype was not in Rest mode.
Edit: did an extra test with the twenty twenty-one. Same issue.
This ticket was mentioned in Slack in #core by rickcurran. View the logs.
3 years ago
#11
@
2 years ago
I believe this is not fixed at all. It definitely isn't for me.
After a very long time, I have a working solution. This function needs to be called after the Gutenberg editor has been fully loaded (which is a task in itself).
Sharing here in the hopes it will help someone. Or that someone finds an actual fix to this.
Original idea: https://stackoverflow.com/a/34764607
// An alternative (but awful) workaround is forcing TinyMCE to the HTML mode on every load: // add_filter( 'wp_default_editor', function() { return 'html'; } ); const reinitializeAllWysiwygFields = () => { tinymce.EditorManager.editors.forEach( function( editor ) { // Apparently, TinyMCE does some parts of the reinitialization asynchronously. // // When there is more than one instance, this creates a race condition on its own. Incorrect // settings are loaded for the second and following editors, and the reinitialization breaks. // // That forces us to make an arbitrary pause between reinitialization so that TinyMCE can // execute all its hooks and asynchronous calls in the meantime. setTimeout( () => { const oldGlobalSettings = tinymce.settings; tinymce.settings = editor.settings; tinymce.EditorManager.execCommand( 'mceRemoveEditor', false, editor.id ); tinymce.EditorManager.execCommand( 'mceAddEditor', false, editor.id ); tinymce.settings = oldGlobalSettings; }, 1000 ); } ); };
Testing with test-wpeditor-metabox.php in trunk and the 5.8 branch (no plugins or only Classic Editor, Twenty Twenty-One theme). Initialization of TinyMCE in the metabox seems to work properly on both the old Edit Post screen (with Classic Editor), and in the block editor.
@dway can you think of anything else that may be affecting this? Possible causes might be that the postbox node is moved in the DOM during or after initialization, or perhaps there is some code that tries to "hold" or repeat the initialization.