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;
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 ….
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
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.
Needs to be said: you do not necessarily need to clear ALL CACHES after editing or adding a news – but it’s for sure the simplest solution
1. In the TSRef-Section of the Sysfolder/Page containing the news add:
TCEMAIN.clearCacheCmd = all
2. In the TSRef-Section(Options-Tab) of the User add:
options.clearCache.all = 1
And it works – tested on typo3 4.2.8
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.