Category Archives: typo3

migrating old typo3 instances from (mysql 5.1 / php 5.3) => (mysql 5.5 / php 5.4)

in typo3conf/localconf.php append

$TYPO3_CONF_VARS['SYS']['exceptionalErrors'] = E_ALL ^ E_NOTICE ^ E_DEPRECATED ^ E_WARNING ^ E_USER_ERROR ^ E_USER_NOTICE ^ E_USER_WARNING ^ E_STRICT;
$TYPO3_CONF_VARS['BE']['forceCharset'] = 'utf-8';
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8';

convert tables containing content to utf-8


ALTER TABLE pages CONVERT TO CHARACTER SET utf8;
ALTER TABLE tt_content CONVERT TO CHARACTER SET utf8;
ALTER TABLE pages_language_overlay CONVERT TO CHARACTER SET utf8;

you might need to convert others too like tt_news, tt_products, etc…


ALTER TABLE tt_news CONVERT TO CHARACTER SET utf8;
ALTER TABLE tt_products CONVERT TO CHARACTER SET utf8;

do not forget to clear cache …

Do you encounter the follosing strange behavious after: page looks ok if loaded after cache clear but special chars are displayed wrong when loaded from the cache? This can help:


ALTER TABLE cache_pages CONVERT TO CHARACTER SET utf8;

typo3 layered menu bug update

Regarding http://bugs.typo3.org/view.php?id=16165 Torben Hansen said today:

“Since 0012376 got into the CORE (TYPO3 4.4.5), the TMENU_LAYERS of one of my TYPO3 sites don´t work anymore. I get exactly the same error (Too much recursion) as described in this bugreport. The menu-DIVs do not have unique IDs, which leads to this error.

The Bugfix in 0012376 works fine with menus having one sublevel. If you have 4 sublevels, it does not work correctly, since “substr(md5(‘gl’ . serialize($this->mconf)), 0, 6)” does not produce unique results.

The approach from this bugreport using PHP uniqid works great and every menu has its unique ID.

So maybe the “uniqid-solution” – suggested by us – will be taken into consideration for future releases ….

typo3: remove htmlspecialchars in header

If you have a content element in typo3 with a header value containing “special chars” like romanian “diacritics” the header will be rendered like sh… – because the “special chars” are transformed using the &#xxx;-syntax, after which the & is transformed into &. The result looks like: &#xxx;

To get rid of this write in the setup part of your template:
lib.stdheader.10.setCurrent.htmlSpecialChars = 0

truncate typo3 indexed search tables for multiple typo3 sites

On a shared host we have some typo3-based sites where we use indexed search.

The table index_rel grows very fast, having over 6.000.000 entries. Even a simple search takes over 30 seconds to complete.
I searched for an elegant solution with very little success.

Here is a brute force solution: a ruby-script that search for databases that have a index_rel-table, truncates the “indexed search tables” if they reach a given size. The table will be automatically refilled every time a page is accessed, even by bots….

The script truncates the “cache tables” also, the “indexed search tables” will not be rebuild if only the cache for a given page is returned by a request.

If you do not have a single user that has access to all the databases, you should configure usernames/passwords per database.

th_mailformplus voodoo with allowedReferers and email_redirect

We maintain a typo3-site which is available under several domains – since it’s not our server we do not 100% understand the network/domain forwarding, etc… arhitecture there. It seems relatively voodoo to me

However we installed the th_mailformplus for a real simple form.

If called from one domain – it worked perfectly and after successfully sending the email we were forwarded to the “thank you”-page we specified(email_redirect-pageID).

If called from the other domain – the mail was not sent and instead of being redirected correctly the TEMPLATE_SUBMITTED_OK-subpart of the template was rendered. I repeat: the TEMPLATE_SUBMITTED_OK-subpart. Once again TEMPLATE_SUBMITTED_OK contains SUBMITTED_OK … subitted ok – yeah right. Pretty stupid behaviour in my opinion…

The solution was simple, add both domains to the allowedReferers. Now it’s working.