[Resolved] Custom WYSIWYG fields save Visual tab view only

[Author]

Posts

[Suzanne Wenger]

After the last update (Types Version 3.4.16, Views Version 3.6.3, Blocks Version 1.6.3) all of my custom WYSIWYG fields are saving only as the Visual Tab, which is creating a lot of problems for me. I have some fields with custom code and do not want the field to automatically load in Visual mode. All of the fields were previously loading in Text mode before, but now, even if I switch to Text mode and save the page it reloads in Visual mode and corrupts my code again.

[Minesh Supporter Languages: English (English ) Timezone: Asia/Kolkata (GMT+05:30)]

Hello. Thank you for contacting the Toolset support.

I just checked with my test site with both Visual and Text mode for WYSIWYG custom fields and I do not able to reproduce the issue.

You can login to the site using the following auto-login link:
hidden link

Here is the post I run a test with:
- hidden link
- Are you able to reproduce the issue with the test site I shared? If yes, please share the step information to follow that should help us to reproduce the issue.

Based on the debug information you shared with us, I can see you are using outdated WordPress version. Could you please update that to latest version: WordPress 6.0
- https://wordpress.org/download/

I also see that you are using PHP 7.3.x:
- Toolset plugins are compatible with PHP 8, you may like to update the PHP version to PHP 8.x.x
=> https://toolset.com/2022/05/toolset-1-6-3-full-compatibility-with-php-8/

I see you are using Classic Editor plugin, in order to minimize the cause of the issue:
*** Please make a FULL BACKUP of your database and website.***
Could you please try to resolve your issue by deactivating all third-party plugins as well as with the default theme to check for any possible conflicts with any of the plugins or themes?
- Do you see any difference?

[Suzanne Wenger]

Hey Minesh,
Thanks for the quick reply. I tried using your test site to reproduce the issue as well, but unfortunately this won't work because your test site is using Blocks, and my site is still using the classic Views plugin only. I have not migrated the site to Blocks.

I think the issue is only happening in the older classic Views plugin (Views Version 3.6.3) when it is being used in classic WordPress editor mode (without Gutenburg.) We are not using Gutenberg in WordPress.

This may be the last straw that forces me onto the Gutenberg system, but at this point it would be difficult to switch the site over.

~ Suzanne

[Minesh Supporter Languages: English (English ) Timezone: Asia/Kolkata (GMT+05:30)]

I've deactivated the Toolset Blocks plugin and installed and activated the latest Toolset Views plugin.

I again run a test and tried to add some text in text mode for WYSIWYG fields and save the post and its working.

As you can see classic views plugin is active:
- hidden link

Can you please check again if you can reproduce the issue, if yes, please share the steps to follow that should help to reproduce the issue.

[Suzanne Wenger]

Hey Minesh,
Actually we are still not to the same setup...you still have WordPress running in Gutenberg (Blocks). You have to switch WordPress back to Classic to replicate the problem. You can do this with the "Classic Editor" plugin, or under Network Settings for Multi-site WordPress installs (which it looks to me like this site is on.) If you are on a multi-site setup the plugin works good to switch between Classic and Blocks view to check how things operate in either environment without ruining all your mini-sites that are running on blocks.

The Classic Editor plugin is this one: https://wordpress.org/plugins/classic-editor/

~ Suzanne

P.S. I have uploaded a snapshot of what the Classic vs Block editor setting looks like under settings (Network Settings on multi-site WordPress).

[Minesh Supporter Languages: English (English ) Timezone: Asia/Kolkata (GMT+05:30)]

As you can see the following post is set to use the classic editor:
=> hidden link

You can chose what editor you want to select with your custom post type edit screen:
- hidden link

For now, I've set per post so we can switch to both (classic and block), you can even try to set the post type editor to classic and check.

That is why classic editor plugin is not required.

[Suzanne Wenger]

Perfect Minesh,
Thanks! I was able to replicate the problem with the link you sent me. With the following link:
hidden link

If you go down to the custom "gym-description" WYSIWYG field, switch this to Text tab make some changes and then update the page you will see that this custom field will then switch itself back to Visual tab automatically. And this is the problem I am getting with the latest update. It's like the Visual tab is set to default somehow. It is an issue for some custom HTML code because WordPress automatically creates it's <p> tags and throws some of my code off and things then look funny every time I go to edit the pages.

~ Suzanne

[Minesh Supporter Languages: English (English ) Timezone: Asia/Kolkata (GMT+05:30)]

Yes, I can see the issue and I've escalated it to our next level support. Please hold on for further updates.

[Nigel Supporter Languages: English (English ) Spanish (Español ) Timezone: Europe/London (GMT+01: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