Skip Navigation

[Resuelto] Updates to WYSIWYG fields are not being saved *in Chrome*

This support ticket is created hace 2 años, 5 meses. 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.

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.

Sun Mon Tue Wed Thu Fri Sat
- 10:00 – 13:00 10:00 – 13:00 10:00 – 13:00 10:00 – 13:00 10:00 – 13:00 -
- 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 -

Supporter timezone: Asia/Kolkata (GMT+05:30)

This topic contains 2 respuestas, has 2 mensajes.

Last updated by Simon hace 2 años, 5 meses.

Assisted by: Minesh.

Autor
Mensajes
#2203559

Re-opening this ticket: https://toolset.com/forums/topic/updates-to-wysiwyg-fields-are-not-being-saved/

The problem described continues to affect Chrome and is definitely NOT purely down to browser cache - I have tested on three different computers using Chrome, including my wife's PC, which had never been used to access the WordPress Dashboard for that site before. On all three sites, updates to WYSIWYG fields fail to save.

I can confirm that Firefox doesn't have a problem, so that's a workaround for now, but it's not unreasonable to try and resolve this issue in the world's most popular browser.

#2204885

Minesh
Supporter

Languages: Inglés (English )

Timezone: Asia/Kolkata (GMT+05:30)

Hello. Thank you for contacting the Toolset support.

What if you try to enable the post editor (post body) field from: Toolset => Post Types => Edit your post type => Enable the Editor and save the post type.

Do you see it working when your post have Editor or what if you disable the "Classic Editor" plugin?

#2205055

Enabling the Editor on the affected Custom Post Types fixes the problem. This is only a workaround though and I think we should have the ability to enable or disable the Editor without having to worry about its effect on other types of field and how they behave.

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