Skip Navigation

[Gelöst] WYSIWYG fields revert to Visual tab upon updates

Dieser Thread wurde gelöst. Hier ist eine Beschreibung des Problems und der Lösung.

Problem:

WYSIWYG fields revert to Visual tab upon updates

Solution:

Update Toolset Types to version 3.4.17 or above.

Relevant Documentation:

https://toolset.com/errata/wysiwyg-fields-revert-to-visual-tab-upon-updates/

https://toolset.com/faq/how-to-install-and-register-toolset/

This support ticket is created vor 2 Jahren, 4 Monaten. There's a good chance that you are reading advice that it now obsolete.

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.

Heute stehen keine Supporter zur Arbeit im Werkzeugsatz-Forum zur Verfügung. Sie können gern Tickets erstellen, die wir bearbeiten werden, sobald wir online sind. Vielen Dank für Ihr Verständnis.

Dieses Thema enthält 11 Antworten, hat 3 Stimmen.

Zuletzt aktualisiert von Stephen Vaughan vor 2 Jahren.

Assistiert von: Christopher Amirian.

Author
Artikel
#2423047

Hi,

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

#2423115

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.

#2423129

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

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

#2423167

Nigel
Supporter

Sprachen: Englisch (English ) Spanisch (Español )

Zeitzone: 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:

https://toolset.com/errata/wysiwyg-fields-revert-to-visual-tab-upon-updates/

#2423173

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.

#2423719

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.

#2483087

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

#2485903

Christopher Amirian
Supporter

Sprachen: Englisch (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.

#2485951

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: https://toolset.com/2022/06/whats-next-for-toolset/
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.

#2485953

Christopher Amirian
Supporter

Sprachen: Englisch (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.

#2486899

Nigel
Supporter

Sprachen: Englisch (English ) Spanisch (Español )

Zeitzone: 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: https://toolset.com/account/downloads

#2487697

Thanks Nigel,

Just reading the post on all the new updates.