Bug #18451


<br /> and <link> tags not properly converted but instead escaped and displayed literally in (in conjunction with UTF-8, umlaut)

Added by David Frster over 16 years ago. Updated about 16 years ago.

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


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


The value of a content element stored in the database as
"Qualität<br />Sicherheit<br />Effizienz<br />Transparenz"
is converted to
"Qualität<br />Sicherheit<br />Effizienz<br />Transparenz" in the frontend, displaying one of the <br /> tags literally. Removing the umlaut fixes the problem. In some places typo tags like "<link fileadmin/pdf/Unternehmen/Technologien.pdf - pdf>" are displayed literally instead of being interpreted.

We're running the site on Typo 4.2 from Subversion with a complete UTF-8 setup. (Database, forceCharset, utfFilesystem, SET NAMES and SET CHARSET on dbInit.)

Any help is appreciated. I'm willing to help debugging this and try suggested fixes.

Regards, David

(issue imported from #M7869)

Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #18463: Cannot import previously exported t3d fileClosedOliver Hader2008-03-17

Actions #1

Updated by Oliver Hader over 16 years ago

Are you talking about the text of a content element (e.g. by using RTEhtmlarea) which contains those umlauts/links or is it a menu structure?

Actions #2

Updated by David Frster over 16 years ago

It's a content element.

Actions #3

Updated by Steffen Kamper over 16 years ago

I can't reproduce that. and i'm not sure if i understand it.
I made a CE with text, used words with umlauts and linked them, FE output works as expected.

Actions #4

Updated by David Frster over 16 years ago

I guess this has something to do with the unicode setup, (PHP, MySQL and Typo configuration).

Can you point me to the place where the decision is made whether to escape special characters from the database and create real links from typolinks? Then I can try to debug it myself.

Actions #5

Updated by David Frster over 16 years ago

I can reproduce this with, by inserted words with umlauts separated by linebreaks (<br /%gt;).

The original report may be confusing, because this bugtracker doesn't escape html properly. I try again:

The text in the database is
Qualität<br />Sicherheit<br />Effizienz<br />Transparenz
and ends up as
Qualität&lt;br /&gt;Sicherheit<br />Effizienz<br />Transparenz
in the source code of tho frontend.

Actions #6

Updated by David Frster over 16 years ago

The displaying of literal html tags is totally broken in this bugtracker.

Actions #8

Updated by David Frster over 16 years ago

Yes, I think the bug is very specific to my setup.

If anyone can tell me, which class is responsible for converting the content from the database for the frontend, I can debug it myself. But the Typo codebase is not exactly small or well structured.

Actions #9

Updated by David Frster over 16 years ago

Disabling the mbstring.overload php setting fixes the weird behaviour. However I would really appreciate if someone can point me to the place the conversion of the content from the database to the frontend output so I can figure out the problem and make it work with the overload setting as well as setting it really makes sense for UTF-8 setups.

Actions #11

Updated by David Frster about 16 years ago

As the use of the mbstring overload function is officially discouraged this bug can be closed.

Actions #12

Updated by Ernesto Baschny about 16 years ago

mbstring overload is not supported


Also available in: Atom PDF