Skip Navigation

[Resolved] CPT WYSIWYG editor sometimes drops the paragraph tags

This thread is resolved. Here is a description of the problem and solution.

Problem:

I have created a CPT Index with multiple fields (WYSIWYG, Number, Single Line, ...). All WYSIWYG fields output the content perfectly, including the paragraphs, except for this "index-description" field, where the paragraphs are missing.

Solution:

It is a known issue, please try the workaround here:

https://toolset.com/errata/paragraph-tag-is-stripped-in-wysiwyg-loop-items-and-page-builders-generated-content/

Relevant Documentation:

This support ticket is created 6 years, 2 months ago. 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.

Sun Mon Tue Wed Thu Fri Sat
- 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9: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/Hong_Kong (GMT+08:00)

This topic contains 11 replies, has 2 voices.

Last updated by Luo Yang 4 years, 7 months ago.

Assisted by: Luo Yang.

Author
Posts
#1094870
Screenshot_17.png
Screenshot_15.png
Screenshot_13.png
Screenshot_12.png

I have created a CPT Index with multiple fields (WYSIWYG, Number, Single Line, ...). All WYSIWYG fields output the content perfectly, including the paragraphs, except for this "index-description" field, where the paragraphs are missing.

Both fields use the same Field Type and are programmed the same way in the Template.
url: hidden link

#1095703

Hello,

It seems there are other plugins in your website changing the content of WYSIWYG field, I suggest you try to modify the WYSIWYG shortcode, add attribute suppress_filters="true", for example:
[types field="my-wysiwyg" suppress_filters="true"][/types]

And test again.

See our document:
https://toolset.com/documentation/customizing-sites-using-php/functions/#wysiwyg
suppress_filters:
'true' | 'false' (default)
If suppress_filters=’true’, all third party (non WordPress) filters hooked into the_content filter will be removed,

#1095722

Hi,
I have modified the shortcode but it did not fix the problem. But honestly I did not think it would, as the problem is not visible in all WYSIWYG post fields.
The post type of the "Belgium" field is exactly the same as the "What" field and yet one displays the paragraphs and the other doesn't.
Which other plugins are you talking about? Also, why would another plugin only target one of my WYSIWYG fields and not the others?

#1095723

Please try this:

1) make sure you are using the latest version of Toolset plugins, you can download them here:
https://toolset.com/account/downloads/

2) deactivate other plugins, and switch to wordpress default theme 2017, and test again

3) If the problem still persists, please provide database dump file(ZIP file) of your website, also point out the problem page URL and view URL, I need to test and debug it in my localhost, thanks
https://toolset.com/faq/provide-supporters-copy-site/

#1096692

Thanks for the details, I am downloading the file, will update here if there is anything found

#1096813

Thanks for the details, I can duplicate the same problem, it occurs only in the first custom WYSIWYG field shortcode, and I have escalated it.
Currently, you can wrap the first WYSIWYG within a P tag, for example:

<p>
[types field='index-description' suppress_filters="true"][/types]
</p>
#1096822

Here is feedback from our 2nd tier supporters, it is a known issue, please try the workaround here:
https://toolset.com/errata/paragraph-tag-is-stripped-in-wysiwyg-loop-items-and-page-builders-generated-content/

You just need to modify the codes as below:

[wpv-autop][types field='index-description' suppress_filters="true"][/types][/wpv-autop]
#1096837

Thank you for the workaround, but the errata page says it was resolved in Views 2.5.2., we are using 2.6.3. and the problem is still present.

#1096838

Yes, it still persists in the latest version of Views plugin 2.6.3, and it is still in our to-do list, and is marked as a bug.

#1096844

thanks for the update, have a nice day.

#1098359

You are welcome.

#1576709

This will not be fixed, and please use the workaround of above erratum.