Bug #20130
closedFE kills external links after a <hr /> in one CE
Added by Henrik Ziegenhain over 15 years ago. Updated over 13 years ago.
0%
Description
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)
Files
fix_hr_tags_RTE.diff (16.3 KB) fix_hr_tags_RTE.diff | Administrator Admin, 2009-11-09 19:40 |
Updated by Stanislas Rolland over 15 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.
Updated by Henrik Ziegenhain over 15 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.
Updated by Stanislas Rolland over 15 years ago
I see no reason for having hr among externalBlocks.
Updated by Florian no-lastname-given over 15 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.
Updated by Daniel Ostmann over 15 years ago
Florian, your code results in:
<p><hr /></p>
that is wrong XHTML.
Updated by Daniel Ostmann over 15 years ago
Oh, sorry, my p-tags are removed....
thats the resulting html code
<p><hr /></p>
Updated by Daniel Ostmann over 15 years ago
i give up..... :-)
the hr tag is wrapped with p-tags.
Updated by Timm Rebitzki over 15 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:
<par>par1</par>
<hr />
<par>par2</par>
<ulist><litem>item1</litem><litem>item2</litem></ulist>
<par>par4</par>
is rendered as:
<par class="bodytext">par1</par>
<par class="bodytext">
<hr />
<par>par2</par>
</par>
<ulist>
<litem>item1</litem>
<litem>item2</litem>
</ulist>
<par class="bodytext">par4</par>
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...
Updated by Bernhard Kraft about 15 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
Updated by Gabe Blair almost 15 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.
Updated by Myroslav Holyak over 14 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
Updated by Henrik Ziegenhain almost 14 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.
Updated by Stanislas Rolland almost 14 years ago
Patch is attached to issue #0005896.
Updated by Stanislas Rolland almost 14 years ago
Fixed in SVN TYPO3core trunk (revision 9883).
Updated by Robert Neumcke over 13 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.