Project

General

Profile

Actions

Bug #17433

closed

Inserting a divider (<hr>) on the RTE breaks XHTML validation

Added by Jose Antonio Guerra almost 17 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Should have
Category:
Content Rendering
Target version:
-
Start date:
2007-07-04
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
7
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

If you insert an <hr> into the RTE it renders inside <p> tags, but that is not valid.

I've managed to configure it the right way using those TS Configuration:

(adding "hr" to "lib.parseFunc_RTE.externalBlocks")

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

This should be included in the extension configuration, isn't it?

(issue imported from #M5896)


Files


Related issues 4 (0 open4 closed)

Related to TYPO3 Core - Bug #24865: Standalone images in RTE-enabled field not rendered in frontendClosedStanislas Rolland2011-01-27

Actions
Has duplicate TYPO3 Core - Bug #20130: FE kills external links after a <hr /> in one CEClosedStanislas Rolland2009-03-05

Actions
Has duplicate TYPO3 Core - Bug #21823: Horizontal Rulers in Richtext Editor unusable because of destroying following html outputClosedStanislas Rolland2009-12-08

Actions
Has duplicate TYPO3 Core - Bug #21749: Inserting <hr /> using an RTE leads to validation errorClosedStanislas Rolland2009-11-30

Actions
Actions #1

Updated by Jose Antonio Guerra almost 17 years ago

I've discovered some drawbacks to my proposed solution.

It has been observed that after any <hr> in the RTE, all the links gets rendered like "<link ....>", breaking the whole validation and the HTML output.

This has been observed with "config.xhtml_cleaning = all". I don't know if disabling the cleaning makes any difference.

Actions #2

Updated by Administrator Admin over 16 years ago

I have the same problem, but found out, that if an other block-element is placed in the content, the parsing is ok after that block-element.

I added the bodytext-class to my p-tag so i can see, what happens:
< p class="bodytext">some text< /p>
< hr />
< p>after hr, the class is missing< /p>
< ul>
< li>listelement< /li>
< /ul>
< p class="bodytext">and here the class is back again< /p>

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

I added the hr-tag to:
lib.parseFunc_RTE.nonTypoTagStdWrap.encapsLines.encapsTagList
Links are parsed correctly with this - even directly after the hr-Tag.

Actions #3

Updated by Holger Gebhardt about 16 years ago

this TS works for correct inserting of the HR:
lib.parseFunc_RTE.externalBlocks := addToList(hr)
lib.parseFunc_RTE.externalBlocks.hr.stripNL = 1
lib.parseFunc_RTE.externalBlocks.hr.stdWrap.parseFunc < lib.parseFunc

Actions #4

Updated by Benni Mack almost 16 years ago

Hey all,

@Holger: Yes, this TS works as long as there is no table in the content afterwards...

Anyway, this HR tag is really confusing. I cannot even do a

lib_parseFunc_RTE.tags.hr = TEXT
lib_parseFunc_RTE.tags.hr.value = Here comes the line

The HR tag really messes up the parseFunc. I think we need to fix this bug soon, anyone willing to dive into to the mighty t3lib_parsehtml ?

Actions #5

Updated by Benni Mack almost 16 years ago

Alrighty,

I found the problem...

The RTE / DB sends the parseFunc this content for instance:

My bla<hr>bla2

So, if I consider <hr> an externalBlocks, the block starts there and never closes, so we need an exception for the empty tags to be considered only open.

For now I solved this by simply putting
$content = str_replace('<hr>', '<hr></hr>', $content);
in the first line of t3lib_class.t3lib_parsehtml.php:splitIntoBlock()

I know it will belong somewhere else. Basically, to get a clean solution, it should replace all "empty tags" (img, hr, br) <hr> => <hr/> and then we should modify the regular expression to detect them correctly.

Actions #6

Updated by Susanne Moog over 14 years ago

This one is related to #10609 (in fact they are the same only with different angles).

Actions #7

Updated by Nikolas Hagelstein almost 14 years ago

Still an issue 4.3.3 and 4.4.0

Actions #8

Updated by Daniel Ostmann over 13 years ago

Still exists in 4.4.2!

Actions #9

Updated by Administrator Admin over 13 years ago

I managed to make it work in 4.4.1

These are the lines I used...
lib.parseFunc_RTE.externalBlocks = hr,ul,ol,table
lib.parseFunc_RTE.externalBlocks.hr.stripNL = 1

Seems to work fine, and tables are rendered after a hr tag. HR tag is no more surrounded by the paragraphs.

The only problem so far is that the default "contenttable" class is removed from the table. If you don't want to have classes on your tables, I don't think this should be a problem, otherwise, you'll need to find a way to fix that issue too.

Actions #10

Updated by Peter Linzenkirchner over 13 years ago

Still exists in 4.4.4. Anchors are not parsed after <hr>

Actions #11

Updated by Stanislas Rolland over 13 years ago

The attached patch fixes this issue:
1. Fix the RTE tranformation (t3lib_parsehtml_proc):
1.1 Remove hr from $blockElementList;
1.2 Add hr to allowTagsOutside;
1.3 Wrap hr tags with LF on way to database
1.4 Avoid wrapping hr in paragraph on way to RTE.
2. Fix hr rendering (tslib_content):
2.1 Fix parseFunc handling of empty tags;
2.2 Fix encaps_lineSplit handling of empty tags (if on a single line) (from patch by Bernhard Kraft)
3.0 Add hr to lib.parseFunc_RTE.nonTypoTagStdWrap.encapsLines.encapsTagList (css_styled_content static template).

Actions #12

Updated by Henrik Ziegenhain over 13 years ago

Awesome work. Again and again!
Successfully testet your patch for 4.4

EDIT
Radu Mogos is using this configuration:
lib.parseFunc_RTE.externalBlocks = hr,ul,ol,table

After applying the patch I had to change this line (removed the hr-tag):
lib.parseFunc_RTE.externalBlocks = ul,ol,table

Actions #13

Updated by Stanislas Rolland over 13 years ago

@Henrik: The patch is pending in core list. Please give your +1 there.

Actions #14

Updated by Stanislas Rolland over 13 years ago

Committed to SVN TYPO3core trunk (revision 9883).

Actions #15

Updated by Stanislas Rolland over 13 years ago

Committed to branch TYPO3_4-4 (revision 10016).

Actions #16

Updated by Ernesto Baschny almost 11 years ago

  • Target version deleted (1088)
Actions #17

Updated by Frank no-lastname-given over 7 years ago

  • Description updated (diff)
  • TYPO3 Version set to 7
  • Is Regression set to No

Is it possible that this behaviour is back in Typo3 7.6.x?

Either with xhtml doctype (produces <hr /> or html5 (produces <hr>) i have alot of (but not all) links killed that come after the hr. Tried to apply some solutions from here and there without any luck.

I don't think it would make any sense to apply a patch from 6 years ago to typo3 7.6.x.
But the hr is an important element sometimes (eg a customer demands it ...).

I'm lost on this one.
Anyone?
Cheers, Frank

Actions #18

Updated by Benni Mack over 5 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF