Project

General

Profile

Actions

Feature #21525

closed

No typoscript template found - Addon

Added by Alexander Stehlik about 15 years ago. Updated over 13 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Communication
Target version:
-
Start date:
2009-11-10
Due date:
% Done:

0%

Estimated time:
PHP Version:
5.2
Tags:
Complexity:
Sprint Focus:

Description

I had the same issue that was described in bug #19657.

Im using the current trunk of TYPO3 4.3 (Revision 6398).
My Database is utf8 and I have forceCharset to utf-8. My setDBinit is set to "Set NAMES utf8". The umlauts are displayed correctly in phpmyadmin, TYPO3 Backend and Frontend.

This is a problem with umlauts in external template files that are encoded in ISO-8859-1. If the external files are encoded in utf-8 everythings working fine.

This is how you can reproduce it:

1. Create two new pages and a new template
2. Put the following Code into your temlate:
<INCLUDE_TYPOSCRIPT: source="FILE: fileadmin/path/to/external/setup.txt">
3. Create this file with an ISO-8859-1 encoding and put this in:
  1. Default PAGE object:
    page = PAGE
    page.10 = TEXT
    page.10.value = öäü
    3. Clear all cache
    4. Go to the first page you created (3 unreadable chars will be displayed)
    5. Go to the second new page by typing in the id as parameter
    => You get the "No TypoScript template found!" error

I did some research and found out, that the serialization of the cache content in the database (in table cache_hash) gets interrupted on those special chars. The text ends with something like: {s:5:"value";s:18:"
You notice the missing closing quote and bracket.

Hope this help ;)

Cheers,

Alex

(issue imported from #M12549)


Files

tstemplate_charset.diff (3.01 KB) tstemplate_charset.diff Administrator Admin, 2009-11-18 21:27

Related issues 6 (0 open6 closed)

Related to TYPO3 Core - Bug #19657: no typoscript template foundClosedChristian Kuhn2008-11-28

Actions
Related to TYPO3 Core - Bug #21421: slow t3lib_TSparser::parseSubClosedBernhard Kraft2009-11-01

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

Actions
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 - Bug #17437: When accessing pages form cache "No Temlpate found!" appearsClosedRupert Germann2007-07-21

Actions
Actions #1

Updated by Bernhard Kraft about 15 years ago

Hello again,

I just uploaded a file "tstemplate_charset.diff". Try to apply this to the latest version (RC1). In your case it should show an error message (yellow box) telling you that there was an error caching the templates, and you should check the charset of included TypoScript files:

------------
Error while caching TypoScript template!
Check charset of included TypoScript files!
------------

What you can do then is to change the file to utf-8, or set an attribute charset="" in your <INCLUDE_TYPOSCRIPT ...> tag like:

<INCLUDE_TYPOSCRIPT:source="FILE:EXT:tvt_nightshots/typoscript/setup.txt" charset="iso-8859-1">

Actions #2

Updated by Oliver Hader almost 15 years ago

Finally I could reproduce this issue.

Actions #3

Updated by Oliver Hader almost 15 years ago

Some remarks about the whole thing:
1) It could be great to have an automatic conversion of the include files
mb_checkencoding() and mb_convert_encoding() offer these functionalities, however mbstring is not shipped with als PHP distributions by default (e.g. Debain does not)
2) A PHP pendant to the UNIX file command would be great - I don't know of any, e.g
file template.txt --> template.txt: ISO-8859 text
3) What puzzled me is the fact that it works with the caching framework but not with the default caching
The difference is, that the caching framework serializes any data before storing.
Serializing data for cache_hash also would solve this issue.
4) Changing the content fields in the cache_* tables to BLOB also solved the problem

However, a real solution in a long term view would be to proper (auto-)convert included files.

Actions #4

Updated by Oliver Hader almost 15 years ago

The storing issues concerning the database are solved.
However, this issue will stay open for discussing a long term solution.

Actions #5

Updated by Ernesto Baschny about 14 years ago

This has been long fixed in #21569 when the cache storage fields were converted to BLOB again. The template files should be in the same charset as the database content, so if the TYPO3 installation is UTF8, the external templates have to he UTF8 also. No magic needed.

Actions #6

Updated by Susanne Moog over 13 years ago

  • Target version deleted (4.5.0)
Actions

Also available in: Atom PDF