Project

General

Profile

Actions

Bug #17437

closed

When accessing pages form cache "No Temlpate found!" appears

Added by Helmut Hummel over 17 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Should have
Category:
Communication
Target version:
-
Start date:
2007-07-21
Due date:
% Done:

0%

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

Description

This seems to be related to 0005088, but this bureport is closed, so I open a new one.

After our provider udated the MySQL Database to MySQL 5.0.32-Debian_7etch1 our TYPO3 installation beaks in Frontend from time to time with the "No Temlpate found!" message. After clearing the FE-cache erverything works for a while, but it will brake again randomly.

I tracked the problem down to class.t3lib_tstemplate.php line 325-333 where the cached template setup is fetched from the database and userialized.

Unserializing fails in such case, so $this->config stays empty causing the failure.

I changed line 333:
-- } else {
++ } if (!$this->setup) {

in order to parse the template again, when serializing fails, but of course this is not like it is ment to be.

The TYPO3 installation has 3 domains, 3 languages and several configured pagetypes.

PHP Version: 4.4.6-2
MySQL Version: 5.0.32-Debian_7etch1

MySQL "show variables"
character_set_client utf8
character_set_connection utf8
character_set_database utf8
character_set_filesystem binary
character_set_results utf8
character_set_server latin1
character_set_system utf8

The collation of the DB tables is latin
(issue imported from #M6006)


Files

scrumbled-cache.diff (106 KB) scrumbled-cache.diff Administrator Admin, 2007-07-22 00:29
db2utf8.php (1.87 KB) db2utf8.php Administrator Admin, 2007-10-18 14:23
screenshotmissingtranscription.bmp (1.1 MB) screenshotmissingtranscription.bmp Administrator Admin, 2007-10-18 14:24

Related issues 5 (0 open5 closed)

Related to TYPO3 Core - Bug #17053: cache is not saved properlyClosedMichael Stucki2007-02-28

Actions
Related to TYPO3 Core - Bug #17091: "No template found" after update from 4.0.4 to 4.1ClosedSteffen Kamper2007-03-07

Actions
Related to TYPO3 Core - Feature #17503: BE should check Mysql charset settingsClosedMichael Stucki2007-08-07

Actions
Related to TYPO3 Core - Bug #21569: Wrong character encoding in cache tables breaks frontend renderingClosedOliver Hader2009-11-16

Actions
Related to TYPO3 Core - Feature #21525: No typoscript template found - AddonClosed2009-11-10

Actions
Actions #1

Updated by Helmut Hummel over 17 years ago

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

Actions #2

Updated by Helmut Hummel over 17 years ago

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

Actions #3

Updated by Daniel Poetzinger over 17 years ago

try to change fieldtyp from blob to text

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

Actions #4

Updated by Martin Zuther over 17 years ago

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>).

Home system:
  • 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"
Provider:
  • 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"
On both setups:
  • 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

Actions #5

Updated by Helmut Hummel over 17 years ago

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;

Actions #6

Updated by Martin Zuther over 17 years ago

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

Actions #7

Updated by Helmut Hummel over 17 years ago

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?

Actions #8

Updated by Martin Zuther over 17 years ago

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

Actions #9

Updated by Helmut Hummel over 17 years ago

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?

Actions #10

Updated by Martin Zuther over 17 years ago

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 = &lt;a href=&quot;index.php?id=3&quot; class=&quot;internal-link&quot;&gt;Kontakt&lt;/a&gt; · &lt;a href=&quot;index.php?id=2&quot; class=&quot;internal-link&quot;&gt;Copyrights&lt;/a&gt;
}
---
Good luck,

Martin

Actions #11

Updated by Michael Stucki over 17 years ago

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.

Actions #12

Updated by Martin Zuther over 17 years ago

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

Actions #13

Updated by Wolfgang Klinger about 17 years ago

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

Actions #14

Updated by Michael Stucki about 17 years ago

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.

Actions #15

Updated by Michael Stucki about 17 years ago

@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.

Actions #16

Updated by Philip Almeida about 17 years ago

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)

Actions #17

Updated by Daniel Poetzinger about 17 years ago

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.

Actions #18

Updated by Simplicity GmbH over 16 years ago

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.

Actions #19

Updated by Dmitry Dulepov almost 16 years ago

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...

Actions #20

Updated by Roland Behme over 15 years ago

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.

Actions #21

Updated by Thomas Schröder over 15 years ago

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.

Actions #22

Updated by Benni Mack about 6 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF