Bug #71878

Empty <p>-Tags after Content Rendering

Added by Andreas Steiger over 4 years ago. Updated 2 months ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Frontend
Target version:
-
Start date:
2015-11-27
Due date:
% Done:

0%

TYPO3 Version:
7
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

css_styled_content generates empty <p>-tags in nested lists (screenshot). The empty tags are only set in the frontend but not in the rte in the backend. Therefore there is no way to remove these tags.

T3bug_nested_lists.PNG View (14.6 KB) Andreas Steiger, 2015-11-27 10:05


Related issues

Related to TYPO3 Core - Bug #65234: Unwanted p tag between UL and LI Closed 2015-02-23
Related to TYPO3 Core - Bug #89429: Empty p tags added in RTE when changing type "passthrough" to "text" via "columnsOverrides" New 2019-10-16

History

#1 Updated by Mathias Brodala over 4 years ago

Do you happen to pass the menu code through lib.parseFunc(_RTE), e.g. due to <f:format.html/> instead of <f:format.raw/> in your template?

#2 Updated by Riccardo De Contardi over 4 years ago

duplicate, I guess #65234

#3 Updated by Andreas Steiger over 4 years ago

Mathias Brodala wrote:

Do you happen to pass the menu code through lib.parseFunc(_RTE), e.g. due to <f:format.html/> instead of <f:format.raw/> in your template?

Indeed! the empty tags are not be rendered in <f:format:raw> - but why?

#4 Updated by Mathias Brodala over 4 years ago

Because <f:format.raw/> simply disables the HTML escaping applied by default in Fluid. OTOH <f:format.html/> by default passes its content through lib.parseFunc which by default puts paragraphs around empty lines by default since they are stored like this when editing via RTE.

#5 Updated by Mathias Brodala over 4 years ago

Can we assume this is fixed for you?

#6 Updated by Riccardo De Contardi over 4 years ago

I don't think that the problem can be considered fixed; But I would close this as duplicate of #65234

#7 Updated by Mathias Brodala over 4 years ago

Well, it is fixed if you use the correct viewhelper depending on the input. For user input possibly created via RTE use <f:format.html/>, for code generated e.g. by TypoScript use <f:format.raw/>. That's how it has always been and is not a bug. ;-)

#8 Updated by Riccardo De Contardi over 4 years ago

@mathias pardon me if I disagree, but I think that this issue is only about the output of the RTE, and the issue is about a wrong behavior of lib.parseFunc; this IMO, of course.

#9 Updated by Mathias Brodala over 4 years ago

The RTE must not be involved here at all, it's simply that <f:format.html/> uses its lib.parseFunc_RTE. And lib.parseFunc_RTE behaves correctly since paragraphs are not stored in the database thus must be wrapped on output.

It could be argued whether <f:format.html/> should use lib.parseFunc by default instead but that would mean a breaking change.

#10 Updated by Riccardo De Contardi about 4 years ago

Now that I tried to reproduce it using a Typoscript menu I understand what happens:
My test (latest 8.2-dev master):

1) create a TS menu:

lib.mainmenu=HMENU
lib.mainmenu{

 1=TMENU
 1.wrap = <ul>|</ul>
 1.NO = 1
 1.NO.wrapItemAndSub = <li>|</li>
 1.expAll =1
 2 < .1
 3 < .2
 4 < .3
}

2) in your Fluid Template, put:
<f:format.html>
<f:cObject typoscriptObjectPath="lib.mainmenu"/>    
</f:format.html>

3) Result: there are some empty

<p>&nbsp;</p>
<p>&nbsp;</p>

after the menu. these empty paragraphs are generated indipendently from the presence of the menu object: they would be there even if you write:
<f:format.html>

</f:format.html>

and disappear if you write
<f:format.html><f:cObject typoscriptObjectPath="lib.mainmenu"/></f:format.html>

I think it can be safely closed now.

#11 Updated by Riccardo De Contardi about 4 years ago

[update] on my previous comment I have not considered the case "fluid styled content".
Test with 7.6.6:

1) create a FSC "Text with media" and put in the text a nested list like:

<ul><li>Arrivederci<ul><li>ciao</li><li>ciao</li></ul></li><li>ciao</li></ul>
<p>&nbsp;</p>

(so hit enter a couple of time to obtain an empty p after building the list)

2) result on frontend: the empty p is duplicated because the Partial Textmedia.html has:

<f:format.html>{data.bodytext}</f:format.html>

#12 Updated by Paul Klimek over 3 years ago

Is there any solution or work around?
Have the same problem with p-tags on 7.6.10 :(

#13 Updated by martin zarth over 3 years ago

In 6.2 <f:format.html parseFuncTSPath=""> did the trick for me.

#14 Updated by Riccardo De Contardi over 2 years ago

  • Status changed from New to Needs Feedback

I performed a test with 8.7.7 and was not able to reproduce this issue

- using a standard Text element (see my comment n°11)
- with the setup I described in my comment n°10

Do you think that this can be closed? Or a different test should be done? Thank you!

[EDIT] I think that I was not able to reproduce it because of this https://forge.typo3.org/issues/65234#note-27 (I used fluid_styled_content)

#15 Updated by Susanne Moog over 2 years ago

  • Category changed from Content Rendering to Frontend

#16 Updated by Alexander Opitz about 2 years ago

  • Status changed from Needs Feedback to Closed

No feedback within the last 90 days => closing this issue.

If you think that this is the wrong decision or experience this issue again, then please write to the mailing list typo3.teams.bugs with issue number and an explanation or open a new ticket and add a relation to this ticket number.

#17 Updated by Markus Mächler 2 months ago

We faced a very similar issue where between all <p> tags with content there was some empty <p> tag added. E.g.

Text in RTE

Lorem

ipsum

Text in RTE (HTML view)

<p>Lorem</p>

<p>ipsum</p>

Frontend rendering

<p>Lorem</p>
<p>&npsp;</p>
<p>ipsum</p>

The problem was that we set RTE.default.proc.overruleMode = ts_css in our TS Config, setting it back to default resolved the issue (RTE.default.proc.overruleMode = default). In my opinion the dealing with line breaks in RteHtmlParser (e.g. streamlineLineBreaksForProcessing) is extremely error prone and should probably be simplified.

#18 Updated by Markus Mächler 2 months ago

  • Related to Bug #89429: Empty p tags added in RTE when changing type "passthrough" to "text" via "columnsOverrides" added

Also available in: Atom PDF