WYSIWYG field – Visual part not working

So, I’ve found out several things…
Installing the classic editor plugin, solves the problem, because it apparently disables Gutenberg, however, I wish to use Gutenberg.
I also found that installing ACF custom fields plugin ( I didn’t do anything with it whatsoever, just installed and activated, nothing else) solves the problem. So something about ACF installation is changing a setting somewhere that resolves the problem.

Any idea what the problem could be? I see this question pop up occasionally, I’ve searched extensively for it, but none of the answers given fitted to my situation. It seems a bit odd, to have to have the ACF plugin installed to fix this

Apart from this one problem, I’m really impressed with pods.

• This reply was modified 7 months, 2 weeks ago by acp693.

Well that’s actually good news! That gives us some helpful info to maybe limit the scope of where we should be looking by comparing implementations with ACF there.

Glad it’s helpful ?? I just posted on Slack because I wasn’t sure if this forum was alive or not, so sorry for the double post.

I deleted ACF and added the plugin “Advanced Editor Tools” this also solves the problem.

Sounds like the scripts for the TinyMCE editor are not loading. Given that two other plugins turn it back on, here are some things to check:

• Besides Pods and the two mentioned plugins, are you running any plugins or a theme that attempt to configure the editor to be either block or classic, rather than allowing both? This can most easily be tested by switching to a default theme and disabling all other plugins temporarily.
• Are there any errors in the browser JavaScript console?
• After these, does clearing server cache, browser cache, or saving permalinks resolve the issue?

Hi, Thanks for the response.

This is a brand new install of WordPress to test this problem.

There are no other themes installed, it’s the standard 2024 theme that comes with WordPress 6.5.

There is only one Pods wysiwyg field added to the standard page type.
Besides the two plugins mentioned (Advanced Editor Tools, ACF), no other plugins are installed. Each of the additional plugins ‘fixes’ the problem whether they’re both activated or just one is activated.

Clearing Caches didn’t help, nor does Saving Permalinks.

I noticed these errors (shown in attached image) when inspecting the rendered page, but I get almost exactly the same errors if I disable Pods and set up the same kind of wysiwyg field using ACF (which works – I can type in the visual part), so can these errors be contributing to the problem?

Just wanted to drop a thank you to the OP for posting your solutions. Was facing the same issue this morning and this worked for me too as a solution.

Having this issue as well. Can’t use the custom WYSIWYG field combined with the block editor without a secondary plugin. Can’t even click on the visual part, and even if you put the text in the plain side, it appears blank when it loads the visual side.

Nothing showing in browser console or PHP error_log.

While the solutions are appreciated, it would be nice if this could be fixed within Pods so we can do it without adding more plugins.

Discovered this problem seems to be limited to Safari. It works normally on Chrome – at least for me.

Hello!
I have the same problem. I use Floorp (Firefox fork) and the visual part of the WYSIWYG editor isn’t working. I can use the text editor of course and got no problems with that but would be nice to have the visual editor as well.

It’s a new WordPress installation with 6.6.1

I came looking for an answer to this issue as I’m also experiencing it. I’ve tested in Safari, Chrome and Firefox and the problem persists on all browsers for me. Installing ACF did not fix it, but installing Advanced Editor Tools does.
It’s now 6 months since OP first posted this issue, is there any word at all from the Devs about what the issue is and when/if they are going to patch it?

Testing on Safari 18.1 and Chrome latest, Pods 3.2.7, WordPress 6.5 and 6.6.2, and TwentyTwentyFour theme, multiple TinyMCE editors loaded below the Block editor, were able to be typed into, saved, reloaded, and edited again.

For anyone encountering this issue, here are some things to try:

• Verify browser versions. Update if possible.
• Verify other plugins, noting that some plugins may override TinyMCE’s behavior or replace it entirely. Which version of TinyMCE is being loaded from which plugins can be found in the Network tab of the browser Web Inspector.
• Verify there are not any layout elements blocking the editor. Does changing the window width to desktop or mobile size resolve it? Is the field accessible by pressing tab to focus it from the previous field, rather than a click?
• Verify the page is loading correctly. Did all resources load in the Network tab of the Web Inspector? Or did some resources return 404 headers or errors in the content, such as PHP errors in responses that should only contain responses from the REST API or JavaScript code.
• Try toggling WP_DEBUG mode off or on. If PHP errors are being displayed on a site, unexpected output may cause layout or scripting errors.
• Check the PHP error log and JavaScript error log. Errors tend to be more relevant than warnings. Each should name a specific script, line number, and nature of the error. If the location of the PHP error log is unknown in your hosting or development environment, Debug Log Monitor will usually display its contents as a widget on the Dashboard screen.
• If the issue is still unresolved, consider using one of the other two rich text editors available in Pods WYSIWYG field options, or split TinyMCE from the block editor with a relationship field, which will display the TinyMCE editors in a modal window isolated from the Block Editor.
• Make sure core stable version of the Block Editor is being used, rather than development version, which would be the case if the Gutenberg plugin is installed.