[Resolved] Empty Paragraphs missing after saving Content Layout
This thread is resolved. Here is a description of the problem and solution.
Problem:
After saving a content layout, my empty paragrpah tags in the editors, are not seen anymore on the front end.
Solution:
This issue is related to P tags being added in the front end if saving the post in the native WordPress Editor AND having a Content Layout assigned.
For this there are functions of Layouts that remove them, those are the same functions that remove the empty tags you add intentionally.
Note, it's not a good practice to add empty prargraphs to add space or lines.
We will work on improvements related to this, however we also suggest not using empty HTML P tags…
This support ticket is created 6 years, 9 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.
I was using layouts on single pages. I removed them and I prepared one common layout for all pages. When I now try to put some text the page doesn't display paragraphs. The whole text is in a single row. Try: hidden link (the two words are in separate paragraphs in the editor) hidden link (here should be a few paragraphs)
The common layout for pages contains just two rows, one for title, one for page content. The page title has Disable automatic paragraphs option on (well changing this option here doesn't help though).
I removed common layout for pages, as it was conflicting with my layouts for archives (where archive is displayed within a page). The paragraphs are visible only when I apply some layout with visual editor to a single page. When I remove the layout and want only use WP editor, the paragraphs are gone (only on a front page).
I'm having trouble reproducing the problem you are describing, there are no settings for the post content cell relating to auto-p's.
Can you run a no-conflict test to see if there is any interference from other plugins or custom code?
Disable all non-Toolset plugins and switch to twentyseventeen theme.
Does the issue persist?
I'm not sure what you mean when you say "I removed common layout for pages, as it was conflicting with my layouts for archives (where archive is displayed within a page)".
If this is an actual archive, you would add an archive cell to a Layout and assign that Layout to the archive in question.
Layouts that are assigned as templates for pages or some post type shouldn't affect a Layout assigned to an archive, and you cannot display and archive cell on a Layout assigned to a page, you would need to add a View instead.
You are not using a Layout or Content Template for those pages, they are just plain old WordPress pages without any input from Toolset.
Pages have auto paragraphs enabled (the wpautop function is added to the_content filter), and removing auto paragraphs is done by code, either custom code that has been added to the site, code from a plugin, or code from the theme (maybe the theme adds an option to disable auto-p's).
I suggest you disable all plugins (you don't even need Toolset for this) and check those pages again. If you still see the issue switch to twentyseventeen and check again.
If it still happens I'm not sure what could be responsible, but please check those first.
I did it, with default WP theme enabled. And the Layout plugin seems to be a problem, because the paragraphs are back when I turn it off, and only when this plugin is off, with the rest on there is no issue, even with default WP theme on.
I only added some code to the functions.php, but it doesn't seem to cause any issue as when I removed it the problem with paragraphs remains.
I confirmed the issue, even after disabling all plugins except Layouts and switching to twentyseventeen, and so I'm passing it on to my colleagues to investigate further.
(They will use your link to retrieve the duplicate, so please leave in place for a few days.)
I noticed this behavior when I removed layout attached earlier to individual page because I wanted to move back to default WP editor (I no longed needed any layout for that page).
I checked the internal tickets. Second tier confirmed that it is not a generally replicable issue, but did identify a regular expression that could be responsible for the problem, and have passed this info on to the developers.
It is being handled in the same queue as other outstanding bugs that will be fixed in time for the next main Layouts release (alongside Types 3.0 and the other plugin updates) that will occur later this month. It is not fixed yet, but the intention is it will be in that release.
My colleague was doing a sweep of older tickets and sees that this was never completed.
And the link to the duplicate no longer works to be able to re-test to check if the issue persists, given that there have been many updates to Layouts and WordPress itself in the meantime. (I routinely delete my copies of client sites.)
Could you please confirm whether you still see the problem with current plugin versions and WordPress?
PS, I am the mentioned colleague who did the sweep of older tickets as elaborated by Nigel.
I wanted to let you know that I tested the reported issue as well before I bounced this back at support.
The issue as reported did not happen for me anymore in any way I tried to replicate it.
That is why I then wanted to try on your personal Duplicate, which turned out to be not possible as Nigel explains above (due to mentioned reasons)
I just wanted to let you know this - again - that I tested carefully before I rolled this back at support. The issue should be resolved, according to my tests, remains to confirm this on your end
OK, I made sure to be 100% through this time, and I can confirm that unfortunately there is an issue persisting, however, this issue would not pop up in case of not using empty P - and empty P is something that is not suggested to be used by HTML 4 and 5, however, their specs are not a mandatory statement, it's a recommendation, and most browsers do not respect it anyway.
Hence, I have informed the Developer again about the issue and asked to look at our functions that make sure no empty P tags are added to your content (which ensures full HTML 4 and 5 compliance)
It's, of course, the webmaster's decision, in this case, you, to use or not use empty tags, as long HTML leaves the choice open, and Toolset should probably respect this decision.
I can however not state yet when, and how, we will adjust this behaviour.
It might be that there are deeper reasons to perform those checks, which may be required. In that case, we would of course carefully document this in future.
I apologise the unnecessary pings you received from us about this issue.
