Skip Navigation

[Resolved] First instance of WYSIWYG custom field in a content template not rendering css

This support ticket is created 4 years, 12 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 4 replies, has 2 voices.

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

Assisted by: Luo Yang.

Author
Posts
#1429509

I am trying to: have all the paragraphs on my page render using the correct CSS

Link to a page where the issue can be seen: I can provide privately

I expected to see: All paragraphs with correct line-height

Instead, I got: The first instance of a WYSIWYG custom field on my page doesn't have correct line-height

I am displaying a bunch of Custom Fields in a Content Template, and for some reason, the very first instance of any WYSIWYG field doesn't render with the correct CSS. In this instance it's a line-height setting in particular that's not being applied. I can provide a link in a private message if need be. All the other WYSIWYG Custom Fields render correctly (as do any of them it seems), so long as they are not the first on the page. Any ideas why this might be happening?

#1431079

Hello,

It seems to be a known issue, see our errata here:
https://toolset.com/errata/paragraph-tag-is-stripped-in-wysiwyg-loop-items-and-page-builders-generated-content/

Please try the workaround in above errata:
As a workaround, you can solve this problem by using {{wpv-autop}} shortcode intelligently around the fields you want to render.

#1431687

Oh wow. How strange. OK, thanks Luo, I'll check out the workaround.

#1431845

Hi Luo,

The workaround worked, but i needed to use a short code that looks like this:

[wpv-autop]

instead of the one suggested on that page which looked like this:

{{wpv-autop}}

What is the difference?

I have the Views 3.0.1 plugin installed, not 2.4.1 as the errata article mentioned - so the issue persists in later View versions.

Additionally, I have the Toolset Blocks Plugin installed and activated, and only now just noticed that my Toolset Views plugin is deactivated by default because I shouldn't have both running at the same time. However, I still have access to Views via the admin menu, and seemingly can create and use them. How is this possible? Shoudl I still be able to create Views even though the plugin is deactivated?

(I think I will return to the Views plugin eventually, since i really dislike the Blocks plugin.)

#1432147

Yes, you are right, it should be [wpv-autop], the {{wpv-autop}} is wrong.

The Toolset Blocks plugin is Continuation of Toolset Views plugin, see our blog post:
https://toolset.com/2019/11/toolset-views-becoming-toolset-blocks/
“Toolset Views” Becoming “Toolset Blocks”
So you can still use Views GUI by this:
Dashboard-> Toolset-> Settings-> General-> Editing experience, enable option "Show both the legacy and Blocks interface and let me choose which to use for each item I build".

It should have been enabled in your website already.