[TYPO3-english] No template found after conversion to UTF8...

[Andrew Plank]

Dmitry Dulepov wrote:
> Hi!
> 
> Andrew Plank wrote:
>> Then, using phpMyAdmin, I exported the "old" database, used the linux
>> "iconv" tool to convert the exported SQL script from iso-8859-1 to UTF8.
>> I then appended "DEFAULT CHARSET=utf8" to each "CREATE TABLE" statement,
>> and imported this modified SQL script to the "new" site's database using
>> phpMyAdmin.
> 
> This operation destroys all _serialized_ data in the database.
> 
> I remember that the bug tracker had a correct procedure for such conversion.
> 

Hi Dmitry,

I've spent the last several hours playing with this whole UTF8
conversion... I've got a working solution. Almost. Which is:

1. Duplicate the filesystem of the site to be cloned to the new server.
2. Using phpMyAdmin, export the database. Convert the sql script to UTF8
from iso-8859-1 using iconv.
3. Edit localconf.php on the new server and update the database details
and then add the following lines before the closing brace, and then
delete the temp_CACHED* files in typo3conf:

$TYPO3_CONF_VARS['BE']['forceCharset'] = 'utf-8';
$TYPO3_CONF_VARS['SYS']['setDBinit'] = "SET NAMES utf8;\nSET SESSION
character_set_server=utf8;";
$TYPO3_CONF_VARS['SYS']['UTF8filesystem'] = '1';
$TYPO3_CONF_VARS['GFX']['TTFLocaleConv'] = 'UTF-8';

4. Having created the new DB on the new site (I used Plesk to create it
- by default it's UTF8) import the sql file from step 2.
5. For some reason, even though it's an exact clone, static_info_tables
needs to be updated to the latest version to get around php errors.
6. On the "old" site, export the entire pagetree as a t3d file.
7. On the new site, import that freshly made t3d file, making sure to
force UIDs. (This appears to get around the serialized data problem, as
all the DB updates are being done through T3, which is configured to use
UTF8 in DB transactions by the statements in step 3)
8. Run through the Install Tool's database analyzer and fix any
discrepencies until everything is working as it should.

Now the interesting part:

9. Modify localconf.php so that the setDBinit line looks like this:

$TYPO3_CONF_VARS['SYS']['setDBinit'] = "SET NAMES utf8;\nSET CHARACTER
SET utf8;\nSET SESSION character_set_server=utf8;";	

Notice the extra "SET CHARACTER SET utf8" statement.

10. Clear all caches, and re-map TV templates.
11. Change the setDBinit line back to how it was in step 3 and clear all
caches.
12. Hit the front end. Press F5 to refresh. Voilá. It works, and so does
the caching mechanism.

HOWEVER... If you try to map a TV template with that extra setDBinit
statement added in step 9, it won't save it. But if it's not there,
you'll get the dreaded "No template found!" error in the FE!

So this is a solution if you don't mind altering localconf.php before
and after each and every mapping change in TV.

Dmitry... Can you think of a reason why this should be the case? Is it
by design? Or just incidental to the way in which the T3 DB mechanism
works, or is it a bug? It would be great to get your input. If it is
possible to create a workaround for this - perhaps as a bugfix in the
next TV?

Kind regards,

Andrew Plank