Project

General

Profile

Actions

Bug #21058

closed

<img > embedded in RTE not XHTML if "config.xhtml_cleaning = all" not set

Added by Netresearch DTT GmbH over 14 years ago. Updated about 13 years ago.

Status:
Closed
Priority:
Should have
Category:
-
Target version:
-
Start date:
2009-09-15
Due date:
% Done:

0%

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

Description

I have a RTE Textelement with an DAM image included. But in FE View the output won't be XHTML conform due the missing slash.

<img src="abc" width="100" height="100">

Using Typo3 4.2.8

from config:

  1. XHTML ON ###
    page.config.doctype = xhtml_trans

With some research I found, that while processing the html is correct but the slash is later removed.
(issue imported from #M11959)


Related issues 1 (0 open1 closed)

Is duplicate of TYPO3 Core - Bug #22209: Image output in frontend is not xhtml valideClosedStanislas Rolland2010-03-01

Actions
Actions #1

Updated by Michiel Roos over 14 years ago

I am unable to reproduce this behavior. Are you using plain DAM? Or mixed with other extensions like dam_ttcontent?

Actions #2

Updated by almost 14 years ago

Reminder. Please give any feedback if the problem still exists.

Actions #3

Updated by Dmitry Dulepov almost 14 years ago

Need also config settings (like config.doktype). May be it just wrong TYPO3 config?

Actions #4

Updated by Caspar Stuebs almost 14 years ago

I can confim this issue.

I am using T3 V4.3.2, DAM with DAM_ttcontent and TinyMCE_RTE, but I have found it also with rtehtmlarea.

Within the BE the source of the RTE shows the appending slash, it is also saved in the DB, but it is removed at the FE.

I am using config.doctype = xhtml_trans and tried it with and without config.xhtml_cleaning = all

Within the page TSconfig I tried the following settings, without effect:

RTE.default.proc.entryHTMLparser_db.xhtml_cleaning = 1
RTE.default.proc.HTMLparser_db.xhtml_cleaning = 1
RTE.default.proc.exitHTMLparser_db.xhtml_cleaning = 1
RTE.default.FE.proc < RTE.default.proc

Actions #5

Updated by Caspar Stuebs almost 14 years ago

I have checked this issue with 4.4.0 Introduction Package and it looks like the problem is fixed.
But now there is a attribut added to the image (txdam="2") which is not xhtml-conform...

Actions #6

Updated by almost 14 years ago

The attribute txdam="2" point to the uid of the DAM media item. If your rendering of the media tag works properly, this should only be visible in the RTE source but not in the frontend.

See http://typo3.org/documentation/document-library/extension-manuals/dam/1.1.5/view/1/3/ (media tag), check your configuration and report. Thanks!

Actions #7

Updated by Caspar Stuebs almost 14 years ago

ok, I just forgot to clear the cache.

After checking again, the attribut txdam="2" is gone, but the appending slash also.

So, the xhtml problem is still there in T3 4.4.0

Actions #8

Updated by almost 14 years ago

Could you let me know if you're embedding the image on the media tab in a "text w. image" or "images" CE (with or without dam_ttcontent?) or directly into RTE?

Actions #9

Updated by Caspar Stuebs almost 14 years ago

I have added the image directly into the RTE.

$TYPO3_CONF_VARS['EXT']['extConf']['rtehtmlarea']['enableImages'] = 1

$TYPO3_CONF_VARS['EXT']['extConf']['dam']['mediatag'] = 1
$TYPO3_CONF_VARS['EXT']['extConf']['dam']['htmlAreaBrowser'] = 1

Afaik, the error only occurs, if the image is embedded into the RTE with DAM enabled.
DAM_ttcontent does not have any effect to this.
If DAM is disabled, the image (embedded in RTE) is xhtml conform in the FE.

Actions #10

Updated by almost 14 years ago

I'm still unable to reproduce this. I inserted the image directly into RTE. Have you set

config.doctype = xhtml_trans
config.xhtml_cleaning = all

?

Actions #11

Updated by Alexander Opitz almost 14 years ago

With config.xhtml_cleaning = all the img tag will be xhtml conform.

But:
1.) It leads to http://bugs.typo3.org/view.php?id=1477
2.) Without DAM you don't need this option.
3.) Why don't output it cleanly and add an parser afterwards to fix output? (As I've understand this option).

Actions #12

Updated by Caspar Stuebs almost 14 years ago

I had set config.doctype = xhtml_trans,
but I had NOT set config.xhtml_cleaning = all

I checked the problem with config.xhtml_cleaning = all and on cached elements the setting will clean the ouput. But if you use something uncached, it won't be cleaned at all.
That's why I thought, that this config has no effect to the problem...

To use this config will avoid the problem, but it does not solve it.
As I mentioned above, within the DB the bodytext field has a XHTML-conform img-tag, but the appending slash is removed during the output.

-> 3.) Why don't output it cleanly and add an parser afterwards to fix output? (As I've understand this option).

I don't understand why you like to produce incorrect XHTML and parse it again to correct it?? Or do I misunderstand your comment?

Actions #13

Updated by Alexander Opitz almost 14 years ago

Oh excuse I meant like:

3.) Why should it be parsed afterwards to clean the output instead of outputing it correctly. (As I've understand the option "config.xhtml_cleaning").

Actions #14

Updated by Stanislas Rolland about 13 years ago

This was fixed with issue #0013695.

Fixed in released TYPO 4.5.0.

Actions

Also available in: Atom PDF