Typo3 obstacles

Almost done with finishing the typo3 projects I was working on lately; I had to move the instances from my testing server to the production server and experienced a series of obstacles that were new for me and that might be helpful for somebody someday:

The two servers are almost identical; windows machines, running apache 2 as webserver and mysql 5 as database engine. So far when I had to move whatever webapplication I ‘just’ created a database dump, zipped/rared the folder with the webapplication in it and unzipped it on the new server, imported the database dump. Sometimes some changes had to be done in whatever config file (url, admin email, …) or permissions in the file system – but mainly the whole process should not take more than half an hour.

1.) First obstacle (that took me a while to figure out) was the fact that McAfee AV Enterprise 8.x was running on the new server. And – for whatever reason – this antivirus software prevents mysql databases to create temp-files bigger then a certain amount of space. So the small queries went through without problem, as soon as they exceeded a certain complexity they failed with throwing a mysql error. Eay (and long googled for) fix: Add the mysql temp folder to the exception list of the on-access-scanner of McAfee.

2.) phpmydamin (version < 2.11.7) + FF3 = bad sql dumps:
If you use any version of phpmyadmin prior to 2.11.7 and Firefox 3 together to export Mysql database dumps, if they are g-zipped the resulting dumps are corrupt. Really great since I used the gzip option a lot, i lost quite some time re-doing work I already had done.

3.) The 2 servers were running identical Mysql versions. I could successfully import sql dumps but however I could not logon at the typo3 backend anymore. Tried to reset password, checked permissions, re-imported the dumps, checked encoding, … same (bad) result. Fresh install of typo3 worked, could login easily. So I checked every single extension, did LOTS of dump ex- and imports, … did not find the reason. After quite some time I found an interesting posting about some be_user problems similar to mine; changed the line in the mysql configuration file, restarted – and voilá everything worked like a breeze. Wohoow! Following there are the two lines, before and after. Maybe someone can make use of that some day, mysql man-pages linked here ;)

before:

sql-mode=”STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION”

after:

sql-mode=”ANSI,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION”

Well. Glad it works now, not so glad it took me that long to find out.


About this entry