Project

General

Profile

Actions

Bug #17292

closed

Ajax collapse in pagetree destroys extended iso-codes -> euro sign

Added by Thomas Murphy about 17 years ago. Updated almost 14 years ago.

Status:
Closed
Priority:
Should have
Assignee:
Category:
-
Target version:
-
Start date:
2007-05-10
Due date:
% Done:

0%

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

Description

If I name a site "MON€Y MAKING MACHIN€" and click the collapse icon, the page will show as "MON?Y MAKING MACHIN?".
The Ajax script seems to return a different charset.

(issue imported from #M5600)


Files

20080124_ajax_charset.patch (915 Bytes) 20080124_ajax_charset.patch Administrator Admin, 2008-01-24 17:41
Actions #1

Updated by Martin Kutschker about 17 years ago

What do you mean with extended iso code? If you're using iso-8859-1 there is no Euro sign. You could try and use iso-8859-15 or windows-1252.

Actions #2

Updated by Benni Mack over 16 years ago

I tried this. I noticed the same problem that the encoding did not work while using no "forceCharset" option because then it used "iso-8859-1" where there is no EUR sign. If you set "forceCharset" to "utf-8" it should work as expected.

Once utf-8 is on by default in 4.2, I will close this bug.

Actions #4

Updated by Martin Kutschker over 16 years ago

Benjamin, the code may not work only in utf-8 being default or not. It has to work with every character set TYPO3 supports.

Actions #5

Updated by Benni Mack over 16 years ago

Hey Masi,

you are right. I found the problem and fixed it.
This problem will be resolved with the changes of the AJAX interface.

Actions #7

Updated by Benni Mack over 16 years ago

Hey,

please see if the problem still occurs in the latest trunk version (or in alpha3 once released). It works for me in iso8859-15 and utf-8.

Actions #8

Updated by Martin Kutschker over 16 years ago

But what happens in eg iso88591-1? Both iso8859-15 and utf8 have a euro symbol. In other charsets it should be represented as an entity (so the browser will probably display it anyway).

Actions #9

Updated by Andreas Wolf over 16 years ago

This still occurs in latest trunk. I have following configuration here: A site created with an older trunk version (before utf-8 became default) and German umlauts and the euro sign are displayed correctly after loading the pagetree, but after expanding/collapsing the leafs, they are screwed up.

I suppose we have to set forceCharset to iso8859-1 when upgrading if it is not set. At least I don't see another way to move around this problem - not everybody wants to convert their old site to utf-8...

Actions #10

Updated by Nikolas Hagelstein over 16 years ago

Hi,

ajax.php converts the ajaxresponse to utf8 by default unless you set
[BE][forceCharset] = whatever (e.g. iso-8859-1) explictily. Since 4.2 will default to utf8 this is quite ok.

Actions #11

Updated by Martin Kutschker over 16 years ago

Nikolas, this is not ok. The BE encoding is defined by $GLOBALS['LANG']->charset and must be observed. It is incorrect for any BE code to check the value of forceCharset to determine the BE encoding.

Actions #12

Updated by Benni Mack over 16 years ago

Hey masi,

totally, I'm gonna fix this ASAP in ajax.php with another RFC. Hopefully we're clean then...

Actions #13

Updated by Benni Mack over 16 years ago

Hey guys,

hope the attached patch fixes the problem.

Actions #14

Updated by Benni Mack over 16 years ago

Can i close this issue now?

Actions #15

Updated by Benni Mack about 16 years ago

Seems fixed to me. Just tried it out.

Actions

Also available in: Atom PDF