TYPO3 Core

Of course my "fix" is bad, as it causes much more trouble.
Any help is appreciated!

I inserted the following debug code:

--- t3lib/class.t3lib_tstemplate.php.orig 2007-07-16 01:31:20.000000000 0200
++ t3lib/class.t3lib_tstemplate.php 2007-07-21 23:21:04.000000000 +0200
@ -344,6 +344,8 @

// This stores the data.
                 t3lib_pageSelect::storeHash($hash, serialize($this->setup), 'TS TEMPLATE');
+                $setupData = t3lib_pageSelect::getHash($hash, 0);
+                if ($setupData != serialize($this->setup)) t3lib_div::devlog("hash not properly serialized: ".$hash.'The wrong: '.$setupData.'The right: '.serialize($this->setup), "tstemplate", 1);

if ($this->tt_track)    $GLOBALS['TT']->setTSlogMessage('TS template size, serialized: '.strlen(serialize($this->setup)).' bytes');

So I could see that the serialized array is scrumbled when storing into the database (see the diff I attached)

.... s:5:"rss2.";a:4:{ .... is transformed to
 .... s:5:"rs";s:12:"page .....

very strange!

And yes: cache_hash.content ist a blob field, as I am using version 4.1.2

try to change fieldtyp from blob to text

i had this strange error also some time ago.
(maybe related to charset)

Hi!

I'm just getting started with typo3. My setup: I currently edit the pages and templates at home and then copy them via mysqldump and phpmyadmin to my website. Everything runs fine at home, but I experience the caching problem on my provider's server, probably allowing you to do some "cross-diagnosis" (yes, I am working close to doctors... <g>).

• Kubuntu 7.04 (kernel 2.6.20-16-generic i686 GNU/Linux)
• Apache 2.2.3
• MySQL 14.12 Distrib 5.0.38
• PHP 5.2.1 (Zend engine 2.2.0) with default charset "none"

• something Linux... ;)
• Apache (I guess version 2)
• MySQL 4.1.9
• PHP 5.1.1 (Zend 2.1.0) with default charset "iso-8859-1"

• typo3 4.1.2 ("cache_hash.content" is a mediumblob field)
• MySQL charset: utf8 (utf8_general_ci)
• MySQL "show variables": * character_set_client utf8 * character_set_connection utf8 * character_set_database utf8 * character_set_filesystem binary (only at home, unknown for provider) * character_set_results utf8 * character_set_server latin1 * character_set_system utf8 * collation_connection utf8_general_ci * collation_database utf8_general_ci * collation_server latin1_swedish_ci (home) / latin1_german1_ci (provider)

The problem: I had to press clear the "FE cache" for a webpage to display. If I tried to view another page on the same site, I received the "No template found" error, until I cleared the "FE cache" again. Going back to the page displayed before and hitting "reload" in the browser gave me another "No template found" error.

The temporary solution: I had a look at bug #0005088, and removing all "special" characters like German umlauts from my templates solved the problem so far. But I need those umlauts! :)

Thanks for listening, and have a nice week-end!

Martin

The backslash seems to be the problem in my case as it seems to be expanded as control character. Changing contentfield to text does not change anything, only base64_encoding helps (like proposed in bugreport 5088)

Is this a php or mysql issue? I can reproduce it on two servers.

Steps to reproduce:

$serialized='a:1:{s:3:"foo";s:4:"\bar";}';

$sql="DELETE FROM `cache_hash` WHERE `hash`='1234' LIMIT 1;";
$result1= mysql_query($sql, $db) or die(mysql_error());
$sql="INSERT INTO `cache_hash`(hash,content) VALUES;";
$result1= mysql_query($sql, $db) or die(mysql_error());

$sql="SELECT `content` FROM `cache_hash` WHERE `hash`='1234'";
$result2= mysql_query($sql, $db) or die(mysql_error());
$row=mysql_fetch_array($result2);
$serialized_db=$row["content"];

echo $serialized;
echo $serialized_db;

Hi!

Same for me: the change from blob to text does not make any difference. It only causes trouble with my utf8 encodings.

The PHP-code snippet from Helmut reproduces the problem both on my home server and on my provider's server.

All the best,

Martin

My problem vanished using base64 encoding, contacting our provider and complaining of db problems. The provider had a wrong DB setup causing most of my problems (data stored in db was not valid)

Nevertheless I can still reproduce the backslash thing, but perhaps I am missing something.

within the next days I will try removing the base64 encoding again and I will report if it still works then.

@Martin: Did you test the patch for bas64 encoding the cache?

Hi Helmut!

Yes, the patch for base64-encoding (from bug #0005088) solved the issue. Now both databases (at home and at my provider) run fine. Maybe you can attach the patch to this bug report as well?

BTW, this patch should definitely be added to the next release of TYPO3.

Thanks for your help,

Martin

I removed base64_en/decoding and everything is still fine in my TYPO3 installation. So it had nothing to do with TYPO3 but with problems storing large data into the database using a unix-socket to TCP redirection. After changing the dbhost entry from localhost to the real mysql database server address, no problems occured.

Nevertheless others seem to have problems with special encoding setups, so it would be nice to know why it happens there.

I suspect that in these cases special chars are counted as one, when saving into the db and as two, when fetching again (or the other way around) so unserializing fails due to wrong string length.

@Martin: Can you provide a snippet of the serialized template with special chars in it?

Hello Helmut,

of course I can provide the snippet. Here you are:
---
config {
htmlTag_langKey = de
language = de
renderCharset = utf-8
}

page {
config {
metaCharset = utf-8
additionalHeaders = Content-Type:text/html;charset=utf-8
}

meta.description = Über mich (here's the bugger...)
}

page = PAGE
page.typeNum = 0
page.config.doctype = xhtml_trans

page.10 < temp.mainTemplate
page.headerData.10 < temp.headTemplate
---
Another snippet is this one:
---
temp.mainTemplate = TEMPLATE

temp.mainTemplate {
template =< plugin.tx_automaketemplate_pi1
workOnSubpart = DOCUMENT_BODY

subparts.footer = HTML
   subparts.footer.value = <a href="index.php?id=3" class="internal-link">Kontakt</a> · <a href="index.php?id=2" class="internal-link">Copyrights</a>
}
---
Good luck,

Martin

What I can say is: If you use UTF-8 on your site, avoid using metaCharset and renderCharset because these won't affect the backend.

If you want to make sure everything is stored and read in UTF-8, open the install tool and set forceCharset=utf-8 instead.

Hi Michael!

On both sites, [BE][forceCharset] is set to "utf-8". Should I still remove "metaCharset" and "renderCharset" from my configuration?

All the best,

Martin

I noticed this problem when using
----
SET NAMES utf8
SET CHARACTER SET utf8
----
in the
setDBinit field (Install Tool >> All Configuration)

When I changed it to only
----
SET NAMES utf8
----
the problem disappeared

TYPO3 4.1.2
MySQL 4.1.15

So I think it's a database issue

Hi Wolfgang,
yes, that may be. See here for an explanation of their difference: http://dev.mysql.com/doc/refman/5.1/en/charset-connection.html

"SET CHARACTER SET is similar to SET NAMES but sets character_set_connection and collation_connection to character_set_database and collation_database."

SET NAMES 'x' is equivalent to these three statements:
SET character_set_client = x;
SET character_set_results = x;
SET character_set_connection = x;

SET CHARACTER SET x is equivalent to these three statements:
SET character_set_client = x;
SET character_set_results = x;
SET collation_connection = @@collation_database;

So it may be that the output is distorted because the database uses a different character set than its content. However, this still is a configuration issue, and I think the only right solution is to switch over to UTF8 completely. See #17503 for details.

@Martin: | On both sites, [BE][forceCharset] is set to "utf-8". Should I still remove "metaCharset" | and "renderCharset" from my configuration?

If these values are equal with the forceCharset setting, you can remove them because TYPO3 will use this as the default automatically.

Hello, I am using ALPHA 4.2.
I had the problem referenced.
I convert MySQL database to UTF8 using the script I upload db2utf8.php
I patch my install using the patch for base64-encoding (from bug 0005088)

Results:
1. "No Temlpate found!" is fixed but quotes are cached and rendered two times(which conflits with scripts).
2 Backoficce is acting strange there are some descriptions missing like list, template (please see screenshotBE)

Hello - just a new idea, cause we had this problem again.
- It appears when importing database from a diffrent TYPO3 installation.
- Maybe it is related to specialchars in the template record and the content in common. In this case a recode of the dump and playing around with database charset setup should help.

For me it helps again by just changing fieldtype from blob to text - since the only diffrence beetween this two fields is that in textfields mysql makes charset conversions.

Hello - we had the same problem on a new server. We migrated Sites from an other server.

The problem disappeared after deleting the SET CHARACTER SET utf8 as described by Wolfgang Klinger.

I can also confirm this. Just lots almost 7 hours on this issue. I was stupid enough to forget that I wrote about it in mailing lists too...

I solved this recently for myself by using the "--default-character-set=utf8" parameter on mysqldump and the mysql commandline client.

The error occurs when there are non-ASCII characters in the TV template-record and the encoding was messed up during export/import because the database engines had different default encodings.

I can also confirm that removing the option "SET CHARACTER SET utf8" solves the problem. We used also --default-character-set=utf8 after a mysql-dump to reload the database.