Skip Navigation

Content of WYSIWYG field lost when updating posts

Open

Symptoms

Initial reports that saving posts which contained a WYSIWYG custom field resulted in the field value being lost led to a fix being released with Types 3.4.14.

Subsequently, we have had additional reports that the problem still occurs if the post type being edited has the post content editor disabled, and we are now working on a solution for that.

Workaround

The problem only occurs when using the Visual tab of the WYSIWYG editor, switching to the Text tab the issue does not occur.

Enabling the post content editor prevents the issue occurring.

30 thought on Content of WYSIWYG field lost when updating posts

  • We’ve identified what’s required to reproduce the issue (it happens with the Classic editor, rather than with the Block editor), and have escalated this to the developers, who will look into it urgently.

    We’ll keep you posted.

    • In testing we are seeing a similar but distinct issue when using the Block editor, but which isn’t reliably reproduced and depends on browser caching. That is, the tinyMCE editor for the WYSIWYG field may not be initialised correctly, so in the Visual tab it appears empty, but switching to the Text tab shows that the content is actually there.

      We are reporting that to the developers separately.

  • Thanks for the update Nigel. Appreciate that.

    I just downgraded to Types 3.4.11 and that seems to solve the problem (for at least one project) in the setup with Views 3.6.1 and WP 5.8.1. I will continue to test this in other projects as well.

  • Yep, just noticed I’m having this issue as well. When attempting to save content in the WYSIWYG editor, whether visual or text, after attempting to save the page – leaving the page and returning shows no content in the editor. Neither in the visual nor text editor. So it’s as if the content isnt’ *really* being saved when clicking “publish”.

  • Any updates? Is it best to switch back to older version for now? We can’t wait any longer editing our posts as we’ve hold off for 2 days now.

  • The developer proposed a fix but in testing it has an unintended side-effect, so we’re still working on it. You may want to downgrade to Types 3.4.12 while we continue working on the problem.

  • Types 3.4.14 has been released and is available from the downloads page.

    If you don’t see the update notice in your plugins page, click the registered link to go to the custom installer page and use the Check for Updates button.

  • Hi Nigel, thanks for replying to my topic earlier. I have updated to 3.4.14, it seems working fine now. Thanks. Good thing is that I’m still developing the site, haven’t yet delivered to client. So it’s good to know that developers solve the bug.

    CHUANGUANG

  • Morning all, I have another bug… I have two WYSIWYG fields, and add contents to both fields, after save and refresh, the content in the first WYSIWYG field is there, but the content in the second field is gone… really frustrated with this…

    Do i not allow to put two WYSIWYG fields in a custom post type?

    • I’m sorry to hear you are having this problem. This scenario—multiple WYSIWYG fields on the same post—was included in the testing before the release, and I have just now repeated the tests myself, adding content to two WYSIWYG fields while editing a post, and I didn’t experience any problems. The content of both fields was saved correctly, and still present after refreshing the page.

      I suggest you try clearing your browser cache, and if you still experience problems please open a support thread with details: we will probably need access to your site to try and identify the problem.

  • Hey, I know this thread is from last month, but I’m actually still seeing this issue on our site, which has already been updated to 3.4.14. I am unable to update any text while in Visual mode, although everything works just fine in Text. And while it is true that we can just make all our edits in Visual mode, but then switch to Text mode before updating the page, I’d kinda prefer that it work the way it was supposed to… 🙂

  • Hey, I know this thread is from last month, but I’m actually still seeing this issue on our site, which has already been updated to 3.4.14. I am unable to update any text while in Visual mode, although everything works just fine in Text. And while it is true that we can just make all our edits in Visual mode, but then switch to Text mode before updating the page, I’d kinda prefer that it work the way it was supposed to… 🙂

    • Chris, you don’t say if your post type has the post content editor enabled or not. If it is enabled, be sure to clear your browser cache and perform a hard reload. If you *still* see a problem, that’s unexpected: please report it in a support thread, we may need to do some testing on your site.

  • Hi Nigel-

    Sorry, we’re using the classic editor. Here’s a screenshot of that part of the admin:

    https://ibb.co/cX2YJCD

    Please let me know if you need anything else to help otroubleshoot. This has actually been going on for at least a month, with multiple users on multiple browsers after multiple shift+refreshes… Thanks!

    Chris

    • Sorry Chris, the question wasn’t about whether you are using the Classic editor, but whether your post types have the post content editor enabled. If you go to Toolset > Post types and edit an affected post type, under “Sections to display when editing” is the Editor option checked? The problem still occurs when the editor is disabled, that is known. If you have the problem even though the editor is enabled (which it normally is by default) then that is unexpected as it has been resolved already, and we’d need you to open a support thread to investigate further.

  • Hey Nigel-

    Okay, that actually did work, but now there are two content entry fields on the page: the standard WP one on top (which wasn’t there before and doesn’t add visible content to the page) and the editor within toolset (which was already there before, but now is working), which is a bit confusing. I took screenshots, but don’t really want to post them publicly, in case you wouldn’t mind emailing me directly to solve this? Thanks!

    Chris

Leave
a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>