idleberg
idleberg

Reputation: 12882

Typo3: How to remove empty paragraphs on page

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">&nbsp;</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">&nbsp;</p>
<p class="bodytext">    <!--  CONTENT ELEMENT, uid:17/text [end] --></p>
<p class="bodytext">&nbsp;</p>  

It goes without saying, that I'd like to get rid off this clutter, especially since the &nbsp; are breaking the layout.

Upvotes: 6

Views: 9719

Answers (8)

Martin Pibyl Marty
Martin Pibyl Marty

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

DomsaN
DomsaN

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

das oe
das oe

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

Hardik Satasiya
Hardik Satasiya

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

maholtz
maholtz

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

idleberg
idleberg

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

idleberg
idleberg

Reputation: 12882

Here is what did the job for me, I added the following line to my setup.

config.disablePrefixComment = 1

Upvotes: -1

Aung Thuya
Aung Thuya

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 == '&nbsp;')
      { 
          elems[i].innerHTML="";
          elems[i].className="";
      }
    }
 </script>

Upvotes: -5

Related Questions