Skip Navigation

[Resolved] Potential tiny bug when outputting date fields

This support ticket is created 5 years, 11 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
- - 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00
- - - - - - -

Supporter timezone: Asia/Ho_Chi_Minh (GMT+07:00)

Tagged: 

This topic contains 2 replies, has 2 voices.

Last updated by Jackie 5 years, 11 months ago.

Assisted by: Beda.

Author
Posts
#1204706
layout screenshot.png
html result.png

Hi there,

This is potentially a tiny bug that doesn't really inconvenience me, but it might bother other people.

I've created a layout that outputs information about a college course. Here's the code:

<div class="row section_page_section_details section_page_section_details_row_2">
	<div class="col-sm-2"><p class="section_detail_subhead">End Date</p></div>
	<div class="col-sm-2"><p>[types field='course-end-date' style='text' format='m/d'][/types]</p></div>
	<div class="col-sm-2"><p class="section_detail_subhead">Meeting Day</div>
	<div class="col-sm-2"><p>[types field='course-start-date' style='text' format='l'][/types]</p></div>
	<div class="col-sm-2"><p class="section_detail_subhead">Credits</p></div>
	<div class="col-sm-2"><p>[types field='credits'][/types]</p></div>
</div>

The resulting HTML looks fine except for one thing: the <p> tags get removed from the date-based fields ("course-end-date" and "course-start-date" and, I just noticed, the "credits" field, which is not a date). See below:

 
<div class="row section_page_section_details section_page_section_details_row_2">
	<div class="col-sm-2"><p class="section_detail_subhead">End Date</p></div>
	<div class="col-sm-2">02/27</div>*****
	<div class="col-sm-2"><p class="section_detail_subhead">Meeting Day</div>
	<div class="col-sm-2">Wednesday</div>*****
	<div class="col-sm-2"><p class="section_detail_subhead">Credits</p></div>
	<div class="col-sm-2">0</div>******
</div></div><div class="col-sm-3">

Screenshots are also attached for your reference.

This is a low priority, but can someone look into it when you get a chance?

Thank you!

Saul

#1204952

If I understand this right, every P tag rendered thru the Layout Visual Editor Cell is simply stripped (removed), if it holds a Types ShortCode?
And, this happens only when using Toolset Layouts, specifically, the Visual Editor Cell.

If this is correct you have some options which are:
- enable automatic paragraphs in the visual editor cell and see if that helps
- do not use Visual Editor Cells but Content Template in the Layout

Note, we do have some BUGs relate to this, where you will see P tags stripped from Layouts or even added.

See the details:
Issue #1
- Create a CPT and add the same kind of content (some empty P separating 2 filled P's)
- Edit this with Content Layouts, add even more P's to the Visual Editor that it generates, save and close
- Make sure the Front end is still featuring the P's in the HTML
- Now update the post, as in click "update" in the backend.
- Everything now is on one line (P's and other empty tags stripped)

Issue #2
- When you switch back to what was used before the CL, then instead of P's you see BR's in the editor, but front end will put it all inline.
- Once you did this, no matter what you insert in the Visual Edit mode of the TinyMCE of WP, the front end will strip all tags.
- The Text Edit mode will feature nbsp instead of br or p after updating.
- As soon you will disable Layouts, that's solved, even though, the Text mode still will show nbsp and in fact, should not generate p or br in the HTML.
- If you were to switch back to what layout generated, nbsp is used as a line break in the editor, but even if nbsp is non-breaking space, the front end actually will break the lines.

BTW, WordPress (WP) native behaviour, means if you add empty "p's" in visual mode, and switch to text, you see no br or p tag added, but nsbp, which is likely not expected either, because nbsp is non-breaking, it cannot render as line break but it does!
(hence this is a WP bug as well)

Issue #3
Toolset Layouts features a CL (Content Layout) editor which (when you press "save" while this editor is open) runs some functions to strip the front end from unwanted (and empty) p tags. However, if you save the post in the native WordPress Edit mode, then those filters do not run and the front end features an empty tag at the end of the CL HTML.
This empty tag will be removed as soon you press save in CL edit mode of the post. As soon as you re-save in native mode, it appears again.

As you see this is a little "mess" (it is only by what I know with P tags in Visual Cells mainly)

So as a workaround, you should be able to use Content Templates if you want to add P tags around the fields.
I think the issue as you see it will happen generally, not just when you wrap Toolset ShortCodes in the P tags, correct?

If any of this is not making sense, please let me know so we could analyse it on your site, however, I believe, as I can replicate all above points I mentioned, that these are the causes for the bug you report.

Definitely, the issue should be solved as soon you use Content Templates instead of visual editor cells, as I could confirm both the issue and solution as well locally.

Please let me know if the same is the case for you.

#1207012

Thanks, Beda!

I'm going to mark this issue as resolved, but as a point of clarification, the issue isn't that every <p> tag is stripped if it holds a Types shortcodes. The issue is that *some* <p> tags appear to be stripped if it holds a Types shortcode, and it's not predictable which ones will be removed. As I mentioned, this is minor, and I've created appropriate CSS to handle the issue. Another workaround is to remove all <p> tags so that the markup is always consistent.