Resolved
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.
The issue is no longer reproducible using the current version of Types (3.4.15).
If you encounter this issue, be sure to clear your browser cache and perform a hard reload, and if you still experience the problem, please open a support thread where your individual case can be evaluated.
I have this issue in Text tab to. Since update of this day
for me the content isn’t lost … it just doesn’t display when you include the field in a template.
disregard … it does lose the content.
this is happening for me as well. This could be a major issue if clients are editing their sites.
Are we getting updated in this thread when any solution is found?
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.
I hope, developers will find the solution! FYI it is happening with Block editors also. 🙁
same issue here, using block editor though, not classic
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.
3.4.12 working fine too
Same issue here
I’ve got the same issue. After publishing the Custom type, everything stored in WYSIWYG is getting lost.
I have the issue with both visual and text tabs in WYSIWYG fields. Looking forward to your fix!
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.
I have checked for updates – but it is only showing 3.4.14 as the most current release …
oops – sorry – I misunderstood what I was looking at – the update IS available. Sorry!
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.
We can confirm this is still an issue. We’ve rolled back to 3.4.12 (60+ site) until this is resolved.
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
Hi Nigel,
is there any update on this issue? It’s still quite bothering me in a lot of projects (where client runs updates themselves).
Thanks!
Marc
Hi Marc
I looked at the internal tickets, where the devs had had problems reproducing the issue but would continue to look into it.
So I just created a fresh test site (again) to double-check the exact circumstances required to demonstrate the problem—and I cannot reproduce it anymore either.
You are welcome to look at an online version of the test site at https://tuneful-cavaco.sandbox.otgs.work/wp-admin/ ( tssupp / tssupp_toolset )
The post type Thing has a WYSIWYG custom field. Edit an existing Thing post (or create new ones) and you will see that it is possible to make edits to the WYSIWYG field content in the Visual tab and those edits are saved without any issue (and also display correctly on the front end).
The Content editor for the Thing post type is disabled, and the post type is set to use the Classic editor.
This leads me to think that if you are experiencing problems on your sites it must be a browser cache issue, and performing a hard reload with clear of the cache should resolve the problem.
Hi Nigel,
Sorry, but I can easily reproduce the error in the test environment. I created and saved a new Thing article, not published – and after saving, the wysiwyg-editor is emptied again. Browser: Chrome.
Can you say something about this?
Regards,
Florian
I tried again just now with Chrome and edited the post you created and was able to save text in the WYSIWYG field without a problem. (I repeated it in Firefox and Safari for good measure.)
That again points to a browser caching issue, and clearing your cache should resolve the problem.
The fact that you experience the issue on a different site than your own suggests that the problem file isn’t a Toolset file itself but a file from a 3rd party library served from some CDN (so that the file URL is the same on different sites), which makes it difficult for us to bust the cache as we would with our own assets by raising the version number.
Really quite unattractive behavior, but I can understand it. After deleting all cookies, the editor obviously works again. I will try this in our productive stems as well. However, I would hope that you try to find a solution to the problem here? Difficult to get our staff to permanently understand that they need to clear the cache in order to use the back office.
I have been experiencing this issue too, first noticed in late September. I’m running version 3.4.14. I have tried clearing all cache, browser cache and cookies; still, content is only saved when using the Text view.
As per Nigel’s Oct. 15 reply and the other noted workaround, I enabled the Editor for the post type (even though I don’t need it), and now the custom field again saves in Visual tab. Just have to tell my client to ignore the new block editor that now appears when adding posts! But, I think that is better for him than having to use the Text tab.
Anyway, just wanted to add my experience in case anyone hasn’t tried this workaround.
I’m still having issues with this. You can see a video recording I made here: https://drive.google.com/file/d/11KwvLbW8Y8VWtYEU03Nu-KHNB_UL0cxQ/view?usp=sharing
I did notice that when switching to “text” mode before saving, it does in fact save, but when trying to display in a view, the data is empty.
Hello any status updates?
One of our WordPress Network Sites that is used for creating job vacancies is still having issues.
We use the classic backend, so we can output everything in strict template and connect it to Google Jobs snippets etc.
On the vacancies we do not use the Post Body.
when I activate the body, it indeed is saving, but this creates a very unclear backend for our customers.
Any idea when / how to solve this?
Custom FIX, not ideal but it works for me at this moment.
Hopefully Toolset will come with a normal solution soon.
My fix:
I’ve added a custom function using the Toolset Custom Code option using the following code and only running it at the admin side:
add_action(‘admin_head’, ‘my_custom_css’);
function my_custom_css() {
echo ‘
.post-type-vacature .postarea {display:none!important;}
‘;
}
vacature is the name of the post type . .post-type-vacature is a class loaded in the body of the post edit page and .postarea is the div that loads the post editor and its buttons. By hiding it, the look and feel for our customers hasn’t changed but die the post body field being active the other WYSIWYG fields are saving again.
Best regards,
Herre aka HaV
I’m still having this issue! I tried everything: i deleted my cache and cookies a millions of times, i enabled the Editor option, installed the “Enable jQuery Migrate Helper” Plugin and so on…. Nothing works at all!
My clients cant use the “Text” Tab.
Can someone help me please? This problem need to be solved before christmas… thanks in advance!
We have a Types release due any moment (just waiting on our systems team to push the release). Please re-test after updating when that is available, and if it does not help in your case, please open a new support thread. We will likely need a copy of your site to determine what specifically about your site prevents it from working.
As the issue can no longer be reproduced we are closing this erratum. If you experience this problem please open a new support thread and provide access to your site for testing purposes.