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.
I am trying to: create line-breaks on front end using the content layout editor on the backend of a page
Link to a page where the issue can be seen: hidden link
I expected to see: line-breaks ( <p> </p> ) on the front end
Instead, I got: The line breaks were completely stripped
I've done some more testing on another site, where the normal paragraph functionality also appeared to be completely broken. Entering a linebreak in the middle of a paragraph in the visual editor of a normal WordPress page running on theme Twentyseventeen resulted on the front end in the linebreak just not showing.
Then I disabled all the Toolset plugins on this site and the normal functionality was back. I reactivated the Toolset plugins one by one, testing the page after every reactivation. It appeared that the Toolset Layouts plugin was causing the trouble.
Some more testing, also on a brand new fresh WordPress install with Twentyseventeen and Toolset Types, Views, Forms, Access, Maps and Layouts activated, revealed the following behaviour:
1. A page filled with the normal editor performs the normal behaviour regarding paragraphs.
2. When on this page (back end) the Content Layout Editor is activated, and nothing is edited, after saving the page, everything is still the same on the front end.
3. When editing text in a visual editor inside the Content Layout Editor and after clicking Save & Close in the Content Layout Editor, the backend is displayed with the yellow pane over the normal editor. If you click on Visit Page from here, the paragraphs are shown as expected, below eachother.
4. However, if - after using and save&closing the Content layout Editor - you click on the save button in the normal WordPress editor and then visit the page, the paragraphs are shown beside eachother on one line.
5. When the button Stop using the Content Layout Editor is clicked and the page is returned to the situation before using the Content Layout Editor (first option), the <p> tags are replaced by <br/> tags. So the page IS NOT returned to The last version before using Layouts.
6. After saving this page, and visiting the page on the front end, the paragraphs are shown below eachother.
7. After editing this page, removing all the text and adding new paragraphs, all in the normal WP editor, saving and visiting this page, the new paragraphs are displayed on the front end beside eachother on one line.
see the various screenshots
So it seems using the Content Layout Editor, saving inside or outside the Content Layout Editor, having used and stopped using the Content Layout Editor, even if after stopping using the Content Layout Editor end completely removing the content on the page and starting to type new content, this all has some quite strange and for normal users unpredictable effects on the behaviour of the paragraphs.
One theory would be this is due to programming faults in the wp_autop behaviour of the Visual Editor cel. Since the last update introduced a new checkbox on the Visual Editor cel (Disable the_content filter) this would be my first suspect to examine.
Then there is also another issue with the content editor, possible related. That is the difference between looking at the front end of the page from the preview button in the Content Layout Editor, and looking normally at the page at the front end. Here you see differences in the behaviour of the paragraphs between the preview and the normal view.
Thank you for contacting us and we apologize for the delay.
It is not considered a good practice to use empty paragraph (or other) tags in WordPress content, as the default visual editor strips any empty or incorrectly balanced/nested HTML tags from the content.
Here is a small test to confirm this:
1. On a website with default Twenty Seventeen theme and all plugins disabled, please add the following code in page/post's content, in "Text" tab (HTML mode):
<p>Paragraph 1</p> <p>Paragraph 2</p> <p>Paragraph 3</p>
2. Save the content and check the front and it will show the 3 paragraphs as expected.
3. Next, remove all the text from the second paragraph, turning it empty and save the page again.
<p>Paragraph 1</p> <p></p> <p>Paragraph 3</p>
You'll note that the empty tag will appear in the page's markup, on the front-end.
4. Now, switch to the "Visual" tab on the page/post's edit screen and save the content again. This time, the empty paragraph will no longer be the part of the front-end markup.
5. If you'll switch back to the "Text" tab on the edit screen, you'll also see that the empty paragraph tag won't be included in the saved content.
This is why it is generally recommended to avoid switching between text and visual tabs when the content includes some complex or detailed HTML.
Tip: I personally use hr tags for situations where empty p tags may be needed to control the vertical spacing between the content elements.
<hr class="sep-small" /> <hr class="sep-medium" /> <hr class="sep-large" />
With help of custom CSS classes, the appearance and spacing of these separators can be adjusted as needed.
The same is also true for picking the workflow between switching from one visual content editor to another. As each visual editor will add its own processing to the content while saving it, editing the same pages/posts through multiple visual editors can bring in unexpected results to its design or layout.
I hope this explanation helps! Please let us know if you need any further assistance.
Thank you for your reply. I am not at all satisfied with it though. In my post above I have described in detail a few scenarios where a client of mine encountered strange behaviour of Visual Editors in Toolset layouts. You come back and give me a general answer about the behaviour of editors and a workaround. Maybe I have been too elaborate and you concluded that the problem was caused by switching between html and visual editors.
Let me give you just another simple example. On a fresh site with twentyseventeen enabled and Toolset plugins loaded and activated, when I start editing a new page, in the visual tab type line 1, press Enter 5 times and type line 2, save the post and visit it on the front end, the result is as expected: I see a page with two lines of text, seperated by 5 line breaks. Examining the html in the browser shows there are 6 paragraphs:
<p>Regel 1</p> <p> </p> <p> </p> <p> </p> <p> </p> <p>Regel 2</p>
When I open a new page, type in a title, save it and click Content Layout editor, put a Visual Editor cell of 12 columns width in the layout, in the Visual tab type line 1, press Enter 5 times and type line 2, save and close the editor and visit the site on the front end, the result is two lines of text, seperated by 'some' vertical space. Examining the html in the browser shows:
<p>Regel 1<br> </p> <p>Regel 2</p>
You see, there was no switching between html and visual editors involved. This is a plain, simple editing operation performed in the normal WordPress Editor and in the Toolset Visual Editor cell, giving two very different results.
You say: "As each visual editor will add its own processing to the content while saving it (...)"
That is exactly the point. And it shouldn't. All Visual Editors should process their content the same way. In fact the normal WordPress editor behaves as expected, but the Toolset Visual Editor does not. That is my whole point. I call that a bug.
My client, who is not very WordPress or html savvy (as is the case with most normal users), does not understand what is happening here and why the editors give such different results. Moreover, she is rather experienced in working with the normal WordPress editor and now encounters problems working in the Toolset Visual Editor, where it seems impossible to do something simple like adding a line break in a text. You add the line break, save and close the Content Layout Editor, visit the page and the line break is gone. That is not ok.
There are more anomalities between the behaviours of both editors. I will not elaborate on those now, just to keep it simple and plain for now.
You say you advise to use hr tags. Perhaps you mean br tags. Nevertheless, this is not at all intuitive to not very savvy users as most clients are. Especially since they are used to wordprocessors and the normal WordPress editor where hitting the Enter key gives the expected result: a line break.
Thanks for writing back and I'm sorry to learn that my last message didn't prove very useful.
I'm currently performing a few tests, based on the points you've shared and will be happy to share my findings and the best way forward (ideally within the next 16 hours).
Thank you for your patience and we're committed to improve the overall user experience, based on the feedback and suggestions we receive.
Thank you for waiting, while I performed some more research and testing based on your report.
I was able to reproduce this issue of missing empty p tags ( <p> </p> ), when the Toolset Layout plugin is active. Please accept my apology for missing this out earlier.
Your observation is correct that those paragraphs tags are shown on the content editing screen, as well as when the preview feature is used. But on the actual published pages, they're not shown as part of the content.
This has been reported to the concerned team already. Unfortunately, I don't have a time estimate to share at this time, but I'll share an update with you once it has been fixed.
Not ideal, but until that is fixed, for those empty spaces, you'll need to use some workaround HTML code, using either div or hr tag with CSS code, as suggested earlier.
If I can be of any further assistance, please let me know.
I hope you're well and I have an update to share on this matter.
Since the Toolset Layouts plugin has been put in the "maintenance mode", it is very less likely that it will get any new features or interface/editor improvements. The newer updates for this plugin will be limited strictly to the critical bugs/fixes only.
Our development focus at the moment is on the newer Blocks editor and we recommend our customers to use it for the newer projects while keeping the Layouts plugin only on the already completed ones.
For any website where the Layouts plugin is being used, the workarounds discussed above can be used.