Skip Navigation

[Resolved] WYSIWYG fields revert to Visual tab upon updates

This thread is resolved. Here is a description of the problem and solution.


WYSIWYG fields revert to Visual tab upon updates


Update Toolset Types to version 3.4.17 or above.

Relevant Documentation:

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.

This topic contains 11 replies, has 3 voices.

Last updated by Stephen Vaughan 1 year, 1 month ago.

Assisted by: Christopher Amirian.



Wysiwyg custom field in block editor post won't show html when text tab is clicked?


It looks like there is a visibility: hidden stying applied. I checked for this across a number of sites so it's not exclusive to one site.


I managed to add the following to the site theme as a temporary workaround:

.wp-editor-container textarea.wp-editor-area { visibility: visible !important; }



Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+00:00)

Hi Stephen

We already have reports of this and it is currently being looked into.

I suggest you subscribe to the comments in this erratum to keep up-to-date with progress:


Thanks Nigel. Though I was going mad. Ny bit of styling doesn't seem to stick, only occasionally, but I can work around by setting it each time in Chrome Inspector.


An update on my styling hack. I was adding this into the themes styling which of course has no input on the back end dashboards.

Adding .wp-editor-container textarea.wp-editor-area { visibility: visible !important; } to a styling function does so I will post this to the forum you suggested.


Any sign of an update to fix this? I note there haven't been any updates to TS plugins for quite a while?


Christopher Amirian

Languages: English (English )

Hi there,

We have a test package for the issue that we can try to install and see if it fixes the issue for you.

For that we will need the staging version of your website.

I'd appreciate it if you could give me the URL/User/Pass of your Staging WordPress dashboard after you make sure that you have a backup of your website.

Make sure you set the next reply as private.

Please do not provide the live website info as we need a website to be able to test stuff and that might break the website.

Thank you.


Hi Christopher,

With all due respect I am not going to spend time setting up a staging site and all the time that it takes to do this with temporary admin accounts for Toolset. The reason for this is because I already reported where the issue lies and how to fix it. For some reason when using the Wysiwyg editor with the block editor there seems to be some conflict whereby the visibility of the html text are is none. Using the following css in a function will force its visibility:

.wp-editor-container textarea.wp-editor-area { visibility: visible !important; }

It seems that this is a trivial enough issue for Toolset to fix. I find the tardiness in doing so irritating for a number of reasons.

For the last four or so year we are being told that we must start using the block editor. Fair enough but, while the block editor so far is fairly ok for inline content layout in many other areas it is sub-optimal and one of these areas is a consistency when it comes to responsive design. Before you say that Toolset has addressed this, yes it has and has made commendable efforts, along with other efforts from this parties such as Kadence to address something that should already be implemented in core.

Moving on, I refer you to the post published by Dario in June this year:
On reading, this does not inspire much confidence in the future of Toolset, which by the way is a very powerful piece of software. I recently re-subscribed for another year with Toolset but I note that there have been no plugin updates since May, even to address some of the small bugs like the one I mention above. This is really poor form.

While I appreciate that developing for the block editor has become a bit of a nightmare, that is no reason why ONTGS can't but focus on many other areas of the Toolset suite. Many of us still roll our own templates and views by hand with html, css and js. It's a bit condescending to direct those of us who have well honed skills in this area that we would be better off using blocks. Don't get me wrong block would be great if they really worked properly.

I would appreciate it if you would pass my feedback up the chain of command.

Yours sincerely,

Stephen Vaughan.


Christopher Amirian

Languages: English (English )

Hi there and thank you for your feedback.

I do understand that you are not willing to create a staging website for a test. So for now I will inform you that a test package is available and after some additional testing a new version with the fix will be there for you to download.

We do not recommend to install the test package on a live website at the time being, that is why I will not share the package.

I will inform management about the feedback that you have mentioned.

Thank you.



Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+00:00)

A quick update to let you know that we have published Types 3.4.17 that includes a fix for this issue.

If the updates do not show up on your plugin installer page (click the registered link beneath the plugin name to go to the custom installer page) click the the Check for Updates button to update the list.

Or you can download the latest versions from your accounts page:


Thanks Nigel,

Just reading the post on all the new updates.

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.