Bug #20130

FE kills external links after a <hr /> in one CE

Added by Henrik Ziegenhain over 10 years ago. Updated over 8 years ago.

Should have
Target version:
Start date:
Due date:
% Done:


TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


The HtmlArea generates correct Links and the entry in the DB looks good.

The first external link in a CE works fine, but if there is a <hr /> between first and second link the following links are killed and look like this:

<link http:wwwzur-birkecom="" _blank="" external-link-new-window="" />Zur Birke</link>

Steps to Reproduce
- Create a new CE, type in Text and a HR.
- Make a link before and after the HR
- Save

Reproducable in TYPO3 4.2.x with Firefox, IE and Opera
(issue imported from #M10609)

fix_hr_tags_RTE.diff View (16.3 KB) Administrator Admin, 2009-11-09 19:40

Related issues

Related to TYPO3 Core - Bug #21749: Inserting <hr /> using an RTE leads to validation error Closed 2009-11-30
Duplicates TYPO3 Core - Bug #17433: Inserting a divider (<hr>) on the RTE breaks XHTML validation Closed 2007-07-04
Duplicated by TYPO3 Core - Bug #21823: Horizontal Rulers in Richtext Editor unusable because of destroying following html output Closed 2009-12-08


#1 Updated by Stanislas Rolland over 10 years ago

I am unable to reproduce this issue. I tried in the RTE and in a CE with disabled RTE without any success.

It is probably a configuration issue in your TS template setup. Make sure that hr is listed in lib.parseFunc.allowTags and in lib.parseFunc_RTE.allowTags

Since the content is correct in the RTE and in the DB, it would have to be a content rendering issue. I am moving the issue to that project entry.

#2 Updated by Henrik Ziegenhain over 10 years ago

I am using this config, the additon of allowTags doesn`t bring the correct results.

lib.parseFunc_RTE.externalBlocks = hr,ul,ol,table
lib.parseFunc_RTE.externalBlocks.hr.stripNL = 1
lib.parseFunc.allowTags := addToList(hr)
lib.parseFunc_RTE.allowTags := addToList(hr)

If I disable externalBlocks the links are rendered correct, but the XHTML markup is wrong.

#3 Updated by Stanislas Rolland over 10 years ago

I see no reason for having hr among externalBlocks.

#4 Updated by Florian no-lastname-given over 10 years ago

I am having exactly the same behaviour. Putting a <hr/> directly before any link kills the link.

I resolved this problem by removing the <hr/> tag from the list

lib.parseFunc_RTE.externalBlocks = hr,ul,ol,table
changed to
lib.parseFunc_RTE.externalBlocks = ul,ol,table

Afterwards, the line is being generated and the link is correctly rendered too.

#5 Updated by Daniel Ostmann over 10 years ago

Florian, your code results in:

<p><hr /></p>

that is wrong XHTML.

#6 Updated by Daniel Ostmann over 10 years ago

Oh, sorry, my p-tags are removed....

thats the resulting html code
<p><hr /></p>

#7 Updated by Daniel Ostmann over 10 years ago

i give up..... :-)

the hr tag is wrapped with p-tags.

#8 Updated by Timm Rebitzki over 10 years ago

I have the same issue and TS as Henrik:

lib.parseFunc_RTE.externalBlocks = table,hr,ul,ol,blockquote
lib.parseFunc_RTE.externalBlocks.hr.stripNL = 1

This prevents the <hr /> being wrapped with a <par>. The side effect is mangled links.

If I disable the above two lines, the <hr> is rendered invalid xhtml.

Note: I changed tag names so the system won't remove them.

This rte code:
<hr />

is rendered as:
<!-- Text: [begin] -->
<par class="bodytext">par1</par>
<par class="bodytext">
<hr />
<par class="bodytext">par4</par>
<!-- Text: [end] -->

The <hr> and the next paragraph are wrapped with a <par>. Also the p class is stripped. After the block-level <ulist> tag, everything is back to normal.

Searching for "hr tag" in the bugs shows 3 issues with <hr> rendering. Apparently not fixed yet.

Currently it's a toss up between broken links and invalid code...

#9 Updated by Bernhard Kraft about 10 years ago

Hello !

I guess you problems are FE related. If you have a "<hr />" in the RTE code, and let it get rendered into the FE using "parseFunc_RTE" the <hr /> tag gets wrapped by "P" tags.

I attached a patch which should solve this problem. I investigated this issue, cause the resulting code: hr tag wrapped in "p" tag is no valid XHTML. The problem is in tslib_content method "encaps_lineSplit". It does not properly recognize so called "singleTags". There are paired tags like <tag>content</tag> and single tags like <tag />. The later ones are not recognized by "encaps_lineSplit" and so setting "hr" tags in the list:

lib.parseFunc_RTE.nonTypoTagStdWrap.encapsLines.encapsTagList = cite, div, p, pre, hr, h1, h2, h3, h4, h5, h6, table

Like it is currently the case using "css_styled_content" will have not effect. As the <hr /> tag simply doesn't get recognized it will still get wrapped by the tag set as wrapping tag.

Try to apply the attached patch. It should solve the problem and also includes a unit-test. The patch was made against latest trunk, but should be applicable to 4.3beta3

#10 Updated by Gabe Blair almost 10 years ago

I can reproduce this issue in 4.3. Thanks very much for the patch, Bernhard - that seems to be working as advertised in 4.3 for us. Do you think your patch will be added to the core for future releases and updates? We don't want to rely on it for production sites until we know that will be the case.

Just a note that, at least in the 4.3 installation where I'm currently working, while the patch provides a workaround for this issue, the original bug as reported in this thread is not resolved by the patch. In other words, adding "hr" to your parseFunc.externalBlocks will cause links appearing after hr tags in the frontend to break.

#11 Updated by Myroslav Holyak over 9 years ago

Stable reproducing in 4.3.2

New text content element. Set some div and external link after it. Set "hr" inside div. Save.
Screenshot of that structure here: http://dl.dropbox.com/u/585045/hr-inside-div.png

#12 Updated by Henrik Ziegenhain almost 9 years ago

Hi, this issue is still reproducable in 4.4.4

Are there any news about this?
Its a very annoying bug for editors when in Backend everything seem to be ok and they don`t get a link in FE.

#13 Updated by Stanislas Rolland almost 9 years ago

Patch is attached to issue #0005896.

#14 Updated by Stanislas Rolland almost 9 years ago

Fixed in SVN TYPO3core trunk (revision 9883).

#15 Updated by Susanne Moog over 8 years ago

  • Target version deleted (4.5.0)

#16 Updated by Robert Neumcke over 8 years ago

TYPO3 4.5.2:
Bug seems to be reproducable again:
After the first hr-Tag links do not get parsed and are shown as <link...> in the HTML-Text.

Also available in: Atom PDF