Bug #71878
closedEmpty <p>-Tags after Content Rendering
0%
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.
Files
Updated by Mathias Brodala about 9 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?
Updated by Andreas Steiger about 9 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?
Updated by Mathias Brodala about 9 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.
Updated by Mathias Brodala about 9 years ago
Can we assume this is fixed for you?
Updated by Riccardo De Contardi about 9 years ago
I don't think that the problem can be considered fixed; But I would close this as duplicate of #65234
Updated by Mathias Brodala about 9 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. ;-)
Updated by Riccardo De Contardi about 9 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.
Updated by Mathias Brodala about 9 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.
Updated by Riccardo De Contardi almost 9 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> </p> <p> </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.
Updated by Riccardo De Contardi almost 9 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> </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>
Updated by Paul Klimek about 8 years ago
Is there any solution or work around?
Have the same problem with p-tags on 7.6.10 :(
Updated by martin zarth about 8 years ago
In 6.2 <f:format.html parseFuncTSPath="">
did the trick for me.
Updated by Riccardo De Contardi over 7 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)
Updated by Susanne Moog over 7 years ago
- Category changed from Content Rendering to Frontend
Updated by Alexander Opitz almost 7 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.
Updated by Markus Mächler almost 5 years 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.
Updated by Markus Mächler almost 5 years ago
- Related to Bug #89429: Empty p tags added in RTE when changing type "passthrough" to "text" via "columnsOverrides" added