Reputation: 12882
I'm using Typo3 v6.1 to create a standard page of the type “text”. In the view, Typo3 adds four empty paragraphs before and after the content created on the Rich Text Editor.
<p class="bodytext"> </p>
<p class="bodytext"> <!-- CONTENT ELEMENT, uid:17/text [begin] --></p>
<p class="bodytext"> <a id="c17"></a></p>
<p class="bodytext"> <!-- Text: [begin] --></p>
<p class="bodytext">The actual text added using the Rich Text Editor</p>
<p class="bodytext"> <!-- Text: [end] --></p>
<p class="bodytext"> </p>
<p class="bodytext"> <!-- CONTENT ELEMENT, uid:17/text [end] --></p>
<p class="bodytext"> </p>
It goes without saying, that I'd like to get rid off this clutter, especially since the
are breaking the layout.
Upvotes: 6
Views: 9719
Reputation: 11
I had this issue too, sometimes it helped to use this setup:
lib.parseFunc_RTE.nonTypoTagStdWrap.encapsLines>
But it cased that I wasn't able to use
in the tables. So I jump a little bit inside and found this possibility:
lib.parseFunc_RTE.nonTypoTagStdWrap.encapsLines.innerStdWrap_all.ifBlank =
Upvotes: 0
Reputation: 21
Can be corrected by removing linebreaks/spaces inside format.html tag
Incorrect:
<f:format.html>{data_item.tx_mask_content_rte}
</f:format.html>
Correct
<f:format.html>{data_item.tx_mask_content_rte}</f:format.html>
Same applies to <f:format.date>
, where having linebreaks/spaces can lead to fatal errors.
Again poorly handled by fluid imho.
Hope it helps
Upvotes: 0
Reputation: 11
This is a solution to a variant of the problem described in the post.
<f:format.html>
{field.copyrightText}
</f:format.html>
gives you one paragraph before and after the expected paragraph
<f:format.html>{field.copyrightText}</f:format.html>
gives you no additional paragraphs. So the breaks in a template seem to be parsed by the format viewHelper.
hope this helps someone; have a good day
Upvotes: 1
Reputation: 9693
add following lines in template script of root
In Constants :
content.RTE_compliant = 0
In Setup :
tt_content.stdWrap.dataWrap >
lib.parseFunc_RTE.nonTypoTagStdWrap.encapsLines>
Upvotes: 6
Reputation: 3631
There is a parseFunc < lib.parseFunc_RTE at the wrong place.
Looks like you have something like
page.10 = CONTENT
page.10.stdWrap.parseFunc < lib.parseFunc_RTE
Which would mean: render the content, and after that parse this content with lib.parseFunc_RTE. The code which activates the wrapping is
lib.parseFunc_RTE.nonTypoTagStdWrap.encapsLines.wrapNonWrappedLines = <p>|</p>
Removing would not solve the issue here, because the cause is, that lib.parseFunc_RTE is processed on the whole content element and not only on bodytext where it should be defined.
Have a look in your TypoScript or add it to your question.
for testing purpose:
Create a new Site on top level, and add only basic TypoScript (add css_styled_content template; Check clear setup and constants)
page = PAGE
page.10 < styles.content.get
Check that output, the content should not wrapped into p class="bodytext" anymore.
Update:
Using {content} where {content} is filled via styles.content.get f.e. the parseFunc is executed twice. styles.content.get executeds the parseFunc, so it can be outputted to the browser. But f:format.html executed lib.parseFunc too. So, that is, why your content is parsed twice.
# in this case, f:format.html does not need to execute the parseFunc again
<f:format.html parseFuncTSPath="">{content}</f:format.html>
Use lib.parseFunc_RTE if you have an RTE field, use lib.parseFunc if you do not expect HTML-Code in the field (f.e. header).
Upvotes: 8
Reputation: 12882
I did some more research and stumbled across people running into the same problem. The div
tags and the comments are the result of so-called "CSS Styled Content". This content is passed to the frontend using content < styles.content.get
, which is—according to my Fluid templating tutorial–the common way to pass content from the RTE to the template.
One website described these as solution (or workaround):
# standard enclosure for header
lib.stdheader.10.1.fontTag = <h1>|</h1>
# remove .csc-header
lib.stdheader.stdWrap.dataWrap >
# plain headings
lib.stdheader.2.headerStyle >
lib.stdheader.3.headerClass >
# (unknown, german version read "remove other stuff"
tt_content.stdWrap.dataWrap =
# disable .bodytext in RTE paragraphs
lib.parseFunc_RTE.nonTypoTagStdWrap.encapsLines.addAttributes.P.class >
# disable paragraph-enclosure for these tags
lib.parseFunc_RTE.nonTypoTagStdWrap.encapsLines.encapsTagList = cite, div, p, pre, hr, h1, h2, h3, h4, h5, h6,table,tr,td
# remove paragraphs in tables
#lib.parseFunc_RTE.externalBlocks.table.stdWrap.HTMLparser.removeTags = p
# allow classes in tables
lib.parseFunc_RTE.externalBlocks.table.stdWrap.HTMLparser.tags.table.fixAttrib.class.list >
Warning: I can not speak for the quality of this workaround. It did solve most problems (divs, comments and classes were removed), but the p
tags remained.
Upvotes: 0
Reputation: 12882
Here is what did the job for me, I added the following line to my setup.
config.disablePrefixComment = 1
Upvotes: -1
Reputation: 47
Please add this code above the end of body tag,
<script> var elems = document.getElementsByTagName('p'); var elemsLenght = elems.length; for (var i = 0; i < elemsLenght; ++i) { if (elems[i].innerHTML == '' || elems[i].innerHTML == ' ' || >elems[i].innerHTML == ' ') { elems[i].innerHTML=""; elems[i].className=""; } } </script>
Upvotes: -5