Waqar, this is a follow-up to https://toolset.com/forums/topic/paragraph-line-breaks-missing-from-custom-fields/.
Our client is still having issues with the paragraph breaks not displaying in the backend with custom WYSIWYG editor fields. Then when they make an update, all of the text reverts to one paragraph since they aren't displaying.
For example, see the attached screenshots. The frontend is displaying correctly, with paragraphs, but the editor is displaying everything without any paragraph breaks.
Hi,
It is strange that the paragraphs are showing on the front end, but not on the back end.
Is this report about the same website as the last ticket?
( I still have its admin access details )
Can you please share the link to the page/post from which this screenshot was taken? I'll also need your permission to download a clone/snapshot of the website, in case it needs to be investigated on a different server.
regards,
Waqar
Waqar,
Yes, this is the same report about the website from the last ticket. The admin access we gave you will still work.
The link to the page from which the screenshot was taken is hidden link.
It's very odd because sometimes when you load one of the pages in the backend, you can briefly see all the paragraph breaks but then when the page fully loads, it lumps all the text together in the WYSIWYG field.
I have created a backup of the site and can give you the link to download it to set up on a different server if you need. Just setup a secure reply and I'll give you the link to download.
Thanks for the update.
Considering the example "Jonathan D. Shaffer" attorney post, the content in its "Bio Content" WYSIWYG field is actually saved without any paragraphs.
But, when that paragraph-less code is shown on the front end, the WordPress content filters are automatically applied to it, for better formatting.
For example, here is a quick test. This is the line of code that gets this field's content in your theme's "single-attorney.php" file:
$att_bio = types_render_field("att_bio", array());
If you'll temporarily change this, to show the raw value from the field, you'll see it will show without any paragraphs on the front end too.
( ref: https://toolset.com/documentation/customizing-sites-using-php/functions/#wysiwyg )
$att_bio = types_render_field("att_bio", array('output'=>'raw'));
Screenshot with normal content:
hidden link
Screenshot with the raw content:
hidden link
I hope this clarifies the difference in the formatting on the front end and the back end.
Thanks for taking a deeper look.
I guess my question is, did something change with the way Toolset is handling things because this isn't happening on the staging server where we have an older copy of this site nor is it happening on any of sites (and we have many) that we have developed in the same fashion as this site.
For example, look at Shaffer's bio on the staging site: hidden link (the login you have will work here too). The paragraphs are displaying in the backend here fine.
Yes, as I mentioned in your last ticket, some changes were introduced in the handling of the WYSIWYG field's content in the latest Types 3.4.16 release.
( ref: https://toolset.com/download/toolset-types/#changelog )
Your staging website is using the older 3.4.2 version of the Toolset Types, which is why you're not experiencing the same on that.
I've shared these findings about the lost formatting of the WYSIWYG field content (only in the admin area), with the concerned team and will keep you updated through this ticket.
Thanks again.
So, what would be your suggested solution that we can offer to our client right now to solve this problem? They aren't happy with the potential of having to edit all of their WYSIWYG fields in the backend.
Meanwhile, you can downgrade to Toolset Types 3.4.15.
The latest Toolset Types 3.4.16 mainly includes compatibility for PHP 8 and some changes for the WYSIWYG field. As your live website is not using PHP 8, downgrading to the older Types version should be safe.
Here are the steps:
1. From the admin area, deactivate and then delete the Types plugin.
( this won't delete the Toolset settings or data )
2. From the Toolset Types downloads page, download the Types 3.4.15:
https://toolset.com/download/toolset-types/#changelog
3. From the admin area, you can upload and activate the Types 3.4.15.
Waqar,
I just copied the entire site and created a new version, in a dev environment. This environment uses PHP 8 and the problem still occurs.
I completed your steps to remove the newer version of Types and installed Types 3.4.15 and the issue is resolved. I will apply this to the live site next to fix the issue but how do we move forward with keeping the plugin updated?
Thank you for confirming that.
As this issue is already under review, a fix for it will be included in the future releases of the Toolset Types.
Although I don't have a time estimate for it at the moment, I'll let you know through this ticket once the release with a fix is out.
Once you have the confirmation you can update the plugin to the latest version and meanwhile, keep using Types 3.4.15.
Thanks again, Waqar. Rolling back to 3.4.15 has solved the issue. Would you be able to alert me of when the newer version of the plugin is ready to be tested and updated?
Yes, that's correct and we'll notify you through this ticket.
Waqar,
Any update here? A few of our additional sites have automatically updated to 3.4.16 and it's causing the same problem. I'm going to roll them all back to 3.4.15 and look into how to keep the plugin from auto updating for the time being.
Thanks for checking in.
This and a couple of other related issues with the WYSIWYG field are still under review.
I'll update you through this ticket once the release with the fix is out, and for now, rolling back to Types 3.4.15 is the way to go.
Waqar,
Thanks for the update.
Rolling back to 3.4.15 has worked for the most part except for one site. We rolled it back yesterday and there are still several pages with the condensed text on both the frontend and backend of the site. Any ideas how to further troubleshoot and fix?
