Project

General

Profile

Actions

Bug #22062

closed

Include BE:forceCharset config option

Added by Sebastian Roth almost 15 years ago. Updated over 14 years ago.

Status:
Closed
Priority:
Should have
Category:
Database API (Doctrine DBAL)
Target version:
-
Start date:
2010-02-05
Due date:
% Done:

0%

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

Description

My setup is to connect to two mysql databases. Unluckily, the mysql client needs a setting for the charset. This can be provided by the my.cnf (?) which is not easy to handle sometimes or better, it should be handled by the DBAL.

Point is, the default connection for tables like "pages" etc.. works, the client charset is set, but not for secondary "native" databases and their tables.

The patch looks like:
// respect forceCharset option
if(($fc = $GLOBALS['TYPO3_CONF_VARS']['BE']['forceCharset']) != '') {
mysql_set_charset(str_replace('-', '', $fc) ,$link);
}

and must be added in class.ux_t3lib_db.php at line 2236, sorry for the non-standard format.

(issue imported from #M13431)


Files

class.tx_t3lib_db.php.patch (663 Bytes) class.tx_t3lib_db.php.patch Administrator Admin, 2010-02-28 04:23
13431.diff (570 Bytes) 13431.diff Administrator Admin, 2010-06-12 14:07
Actions #1

Updated by Xavier Perseguers almost 15 years ago

Hi,

Line 2234-2238 for me are

/************************************ *
  • Handler management
    *
    ******************************/

This does not make sense to put something at line 2236 as you say. If you cannot provide a real patch (which is not that complicated BTW), please at least provide some context of where your code should go, in addition to the line number. Otherwise I have no chance reviewing this change.

Do not forget to use latest version from SVN when you provide a patch or a pseudo-patch, this helps minimizing the risk your code does not fit anymore into current code...

Actions #2

Updated by Xavier Perseguers almost 15 years ago

BTW, I personally have a similar problem with a native DB in MySQL, utf-8 and a MSSQL database for external data that is using latin1/iso-8859-1 encoding.

You're right, there should be a way to define the source character set and the "to" conversion should take $GLOBALS['TYPO3_CONF_VARS']['BE']['forceCharset'] into account.

Actions #3

Updated by Xavier Perseguers almost 15 years ago

After digging a bit into this issue, it seems that any MySQL connection should be properly initialized if you properly define $GLOBALS['TYPO3_CONF_VARS']['SYS']['setDBinit'] in Install Tool with

SET NAMES utf8

as stated in tutorials on using UTF8 systems. Problem exists for other databases, but for MySQL, I guess this should be OK. Of course, if you are using a DB in utf8 and another in latin1 or whatever, this won't work...

Actions #4

Updated by Sebastian Roth over 14 years ago

Patch attached.

My problem was exactly as you mentioned. One DB in latin1, another one in UTF8, and the mysql client config got confused about it.

thx

Actions #5

Updated by Armin Guenther over 14 years ago

Hi Xavier,
I disagree with vour note #0034986: Unfortunatly

$GLOBALS['TYPO3_CONF_VARS']['SYS']['setDBinit'] = SET NAMES utf8

does not(!) initialize an alternative MySQL connection via DBAL properly. The reason is, that "SET NAMES utf8" actually is not sent to an alternative connection but only to the _DEFAULT connection.

In class ux_t3lib_DB, function handler_init($handlerKey) there is

$link = mysql_connect(...)

Later in same function only for the _DEFAULT connection $this->link is set to $link:

if ($handlerKey == '_DEFAULT') { $this->link = $link; }

Now in the following statements the TYPO3_CONF_VARS are passed only to the _DEFAULT ($this->link) connection:

$setDBinit = t3lib_div::trimExplode(chr(10), $GLOBALS['TYPO3_CONF_VARS']['SYS']['setDBinit'], 1);
foreach ($setDBinit as $v) { if (mysql_query($v, $this->link) === FALSE) {...}

Change $this->link to $link and it works like expected:

$setDBinit = t3lib_div::trimExplode(chr(10), $GLOBALS['TYPO3_CONF_VARS']['SYS']['setDBinit'], 1);
foreach ($setDBinit as $v) { if (mysql_query($v, $link) === FALSE) {...}

I hit on this problem when I tried to access from a typo3 installation X a table in a second typo3 installation Y with own MySQL databases each. Both installations were proper configured for utf-8. But accessing the Y-table in X via DBAL did not result in UTF8 although Y-Table in Y where correctly read as UTF8

To make a long story short: I think that in class ux_t3lib_DB, function handler_init($handlerKey) the following statments

$setDBinit = t3lib_div::trimExplode(chr(10), $GLOBALS['TYPO3_CONF_VARS']['SYS']['setDBinit'], 1);
foreach ($setDBinit as $v) { if (mysql_query($v, $this->link) === FALSE) {...}

should be changed to

$setDBinit = t3lib_div::trimExplode(chr(10), $GLOBALS['TYPO3_CONF_VARS']['SYS']['setDBinit'], 1);
foreach ($setDBinit as $v) { if (mysql_query($v, $link) === FALSE) {...}

(Sorry, you would prefer a real patch, I know but...)

Actions #6

Updated by Xavier Perseguers over 14 years ago

I'd had preferred a real patch but thanks for having found the real bug.

Committed to:

- trunk (rev. 34219)
- DBAL_1-1 (rev. 34220)
- DBAL_1-0 (rev. 34221)

Actions

Also available in: Atom PDF