Bug #32225: meta-tag for charset is rendered multiple times - TYPO3 Core - TYPO3 Forge

Custom queries

Accessibility
Easy tasks
Forge Triage
JavaScript issues
JavaScript Issues (w/o Epics/Stories)
My open issues
No feedback within 90 days
Open Bugs
Open issues of 10
Recently modified
Regressions
Stabilization Issues
Usability or UX

Actions

Copy link

Bug #32225

closed

meta-tag for charset is rendered multiple times

Added by Christoph Grafenauer almost 13 years ago. Updated almost 13 years ago.

Status:

Closed

Priority:

Must have

Assignee:

Category:

Frontend

Target version:

Start date:

2011-11-30

Due date:

% Done:

100%

Estimated time:

TYPO3 Version:

4.5

PHP Version:

5.3

Tags:

Complexity:

Is Regression:

Sprint Focus:

Description

In the <head> section of my rendered HTML5 document (frontend) i found three identical entries:

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

In the Install-Tool, BE[forceCharset] is set to utf-8.
In Typoscript, i have set config.renderCharset = utf-8

So why does Typo3 try to render the frontend as iso-8859-1 encoded ?
Typo3 should never output this meta-tag three times.

W3C Validator outputs errors because of this issue.

History
Notes
Property changes

Actions

Copy link

Updated by Markus Klein almost 13 years ago

Hello Christoph!

This is indeed weird.
Are you setting config.metaCharset somewhere?
Are you using any extensions manipulating the frontend output?

Thanks for reporting.

Actions

Copy link

Updated by Christoph Grafenauer almost 13 years ago

Hi Markus,

config.metaCharset is not set.
There are no extensions installed that manipulate the frontend output, just "usual" extensions like templavoila, tt_news, perfectlightbox, wec_map, cooluri.

I have searched through the Typoscript Object Browser (find properties like "headerData" or "additionalHeader") but there are no strange entries which would lead to such a behaviour.

I discovered this issue after updating from typo3 4.5.6 to 4.5.8.

Today i made some full text searches (search for "meta", "Content-Type") over the typo3 core to find the right place(s) where typo3 is going to output the header-data.
I found out, that when i remove the ###HEADERDATA### line in sysext/cms/tslib/templates/tslib_page_frontend.html, all three entries are gone.
Maybe this hint could help you identifying the problem.

If you have any further questions please let me know.

Thank you for your effort.

Actions

Copy link

Updated by Chris topher almost 13 years ago

Christoph Grafenauer wrote:

In the <head> section of my rendered HTML5 document (frontend) i found three identical entries:

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

W3C Validator outputs errors because of this issue.

Your charset meta tag does not look like you are using HTML5.
TYPO3 sets the meta tag depending on what you set as config.doctype.
If config.doctype = html5 you should get an html5 valid doctype at least (which you don't have currently). (Or you are still using an outdated version of TYPO3, e.g. 4.5.1, which btw. has known security holes.)
If I remember correctly config.renderCharset is only needed if you want to create an output, which is different from which you set in $TYPO3_CONF_VARS['BE']['forceCharset']. So you could safely leave it out. But check TSref again!

If you can change the tag that way, it would be interesting to see, how your three tags are connected. E.g. does setting the correct doctype change all three (or only some)?

Another idea: Depending on how you configured the TEMPLATE cObject in your TypoScript template, TYPO3 might be using the content of the head tag from the HTML template instead of creating an own one. Maybe you have such a mess in your HTML template.

Actions

Copy link

Updated by Christoph Grafenauer almost 13 years ago

I have checked my TSConfig:

config.doctype is correctly set to html5 (config.doctype = html5)
config.renderCharset is not set
config.xmlprologue = none
config.htmlTag_setParams = none
$TYPO3_CONF_VARS['BE']['forceCharset'] is set to utf-8

My (simplified) document structure (without additional header data like css) looks like this:

<!DOCTYPE html>
<html>
<head>

<meta charset="utf-8">

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

Then i tried the following:

Setting config.doctype = xhtml_trans resulted in (again a simplified version) :

<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

In summary, the last three entries does not change regardless of the doctype or charset...

I have also checked the templavoila template object and no <meta> tag will be mapped.
When i map in templavoila the meta-tag, the frontend renders 4 meta-tag with charset :(

Really strange issue...

Actions

Copy link

Updated by Christoph Grafenauer almost 13 years ago

Good news guys,

you were totally right: the meta-tag for charset was not mappend in the main template of templa voila but in the flexible content elements.
Therefore a 33%-33%-33% FCE-Element (three columns) was writing the meta-tag three times in the <head> section :/

Sorry for that boner :(

Actions

Copy link

Updated by Chris topher almost 13 years ago

Status changed from New to Closed
% Done changed from 0 to 100

Actions

Copy link

Also available in: Atom PDF

Project

General

Profile

TYPO3 Core

Custom queries

Bug #32225

meta-tag for charset is rendered multiple times

Updated by Markus Klein almost 13 years ago

Updated by Christoph Grafenauer almost 13 years ago

Updated by Chris topher almost 13 years ago

Updated by Christoph Grafenauer almost 13 years ago

Updated by Christoph Grafenauer almost 13 years ago

Updated by Chris topher almost 13 years ago