To check if this is the case:

• Use a browser developer tool such as chrome developer console (hit F12 in your browser), and check for an 500 internal error response for a url similar to …./alt_clickmenu.php?…
• Next, check your templavoila version. If this is 1.8.0: there you go

There is already a patch provided for this issue:
http://forge.typo3.org/attachments/23132/

To fix this manually, edit the file typo3conf/ext/templavoila/classes/class.tx_templavoila_file.php

In the method public static function is_xmlFile($filename), adapt the following lines:

public static function is_xmlFile($filename) {
  if (!self::includesFal()) {
    // fix file list context menu according to http://forge.typo3.org/attachments/23132/43554.patch
    // return self::is_xmlFile($filename);
    return self::is_xmlFile_finfo($filename);
}

However, many internet providers started to switch IP addresses for their customers to serve more customers with smaller IP pools. Especially if you use a mobile or a hotels or conferences internet connection, you get a new client-side IP address quite often.

Typo3 provides a configuration to let you slightly reduce this security check and to enable such users to still access your system.
If you log into your install tool and browse to “all configurations” you will find a configuration named lockIP.

This configuration allows for a value between 0 and 4. This integer specifies the number of IP positions to be checked by this security feature. Typically, your internet provides switches only the last or the two last positions of your IP adresse (0.0.0.0). By default, all 4 positions are checked. If you modify this configuration, you should reduce it only step-wise (4-3-2-1-0) to keep the highest number your users are happy with.

SQL error: 'Incorrect integer value: '' for column 'backend_layout' at row 1' (pages:NEW12345)

You should check your MySQL configuration. More specific the sql-mode you have configured.
Typo3 is not compatible with the MySQL strict model. Check the example below to see how the configuration must be adapted (based on the default my.ini settings)

# Set the SQL mode to strict
# disable strict mode for typo3
#sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
sql-mode="NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION" 

Trying to open a content element with a rich text editor field, presented only the message “editor is being loaded” without any further information or progress.
When logging into the backend as an admin user, everything worked fine.

Checking with the firefox javacript console, the following error was provided:

ReferenceError: invalid assignment left-hand side
Line: 414, Row: 60
3);return('#'+hex(r)+hexHTMLArea.Editor.prototype.isEditable=function(){return(this._doc.designMode==="on");};HTMLArea.E


Finally, the solution I found was to disable the javascript compression for the richt text editor scripts in the extensions overall configuration using the Extension Manager:

However, this was the first time I saw this problem and I was not able to reproduce it on any other of our typo3 installations.

The documentation recommends to activate the “This field contains the Email of the sender” checkbox for the form field the user should put his email adress in. With the powermail version 2.0.6, this setting seems to have no effect and the user does not receive any confirmation mail.

According to the document, another way to configure the field to be used as the form sender’s email adress is to put in the according form field variable in the configuration field of the form:
http://typo3.org/extension-manuals/powermail/2.0.6/view/1/48/
Trying to put in the variable referencing the email field (e.g. {e_mail}):

ends up with an error message (“errorinemail@tryagain.com”) because of an invalid e-mail format:

The only way I figured out to fix the configuration was to overwrite the sender’s email and name in an extension template for the page setting them to the fluid variable referencing the according form fields:

plugin.tx_powermail.settings.sender.overwrite.senderEmail={e_mail}
plugin.tx_powermail.settings.sender.overwrite.senderName={name}


Internally, cooluri reads the requested domain from the php server array by asking for the server name: $domain = $_SERVER['SERVER_NAME'];.
Often, this does not return the request domain but an internal server name.

To fix this issue you have to edit the cooluri extension file typo3/conf/ext/cooluri/class.tx_cooluri.php
Replace all occurences of $_SERVER['SERVER_NAME'] with $_SERVER['HTTP_HOST'], refresh your typo3 caches and fore cooluri to update all cached urls.

As an alternative, you can use t3lib_div::getIndpEnv('HTTP_HOST') instead of $_SERVER['HTTP_HOST']. In the according cooluri bug report (http://forge.typo3.org/issues/35799) someone recommended this to also support setups with a proxy configured in front of typo3. However, I never tested this up to now.

Next, I checked the CoolURI cache without any entry in there. But no error messages. Only if I tried to manually create a new uri in the cooluri cache, I received an error message that cooluri wasn’t able to create the cache entry (“Could not save the link.”).

Due to this, I checked the database and found … nothing. The cooluri caching tables were not present in the database.
I assume I have accepted to remove them from the system during the upgrade to Typo3 6.x. However, there seems to be no Typo3 6.x compatible database definition in cooluri, because neither the extension manager, nor the “compare” in the installation tool offer me the option to create these tables.

So finally, I was able to fix the problem by running the insert queries on the database (MySQL) on my own to create the tables manually.

The sql script to create the tables are presented below.

CREATE TABLE IF NOT EXISTS `link_cache` (
`id` int(10) unsigned NOT NULL auto_increment,
`params` blob,
`url` char(255) collate latin1_german2_ci default NULL,
`tstamp` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
`crdatetime` datetime default NULL,
`sticky` tinyint(1) unsigned default '0',
PRIMARY KEY (`id`),
KEY `url` (`url`(64)),
KEY `params` (`params`(64))
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_german2_ci AUTO_INCREMENT=27 ;

CREATE TABLE IF NOT EXISTS `link_oldlinks` (
`id` int(10) unsigned NOT NULL auto_increment,
`link_id` int(10) unsigned NOT NULL default '0',
`url` char(255) collate latin1_german2_ci default NULL,
`tstamp` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
UNIQUE KEY `id` (`id`),
KEY `url` (`url`(64))
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_german2_ci AUTO_INCREMENT=3 ;


It makes use of a system function which is not supported any longer. As a result, you might end up with the following error message when you try to create a new content element in the page module (the list module might still work):
Fatal error: Call to undefined method TYPO3\CMS\Core\Utility\GeneralUtility::readLLXMLfile() in /homepages/23/d183583809/htdocs/diana-nahm.de/typo3conf/ext/nivoslider/pi1/class.tx_nivoslider_pi1_wizicon.php on line 70

To fix this issue, you need to modify the code of your local extension installation or provide a xclass extension to replace the according method.

The code you need to fix is in the file typo3conf/ext/nivoslider/pi1/class.tx_nivoslider_pi1_wizicon.php

You need to replace the method
function includeLocalLang() {
$llFile = t3lib_extMgm::extPath('nivoslider').'locallang.xml';
$LOCAL_LANG = t3lib_div::readLLXMLfile($llFile, $GLOBALS['LANG']->lang);
return $LOCAL_LANG;
}


with this code

function includeLocalLang() {
$LOCAL_LANG = \TYPO3\CMS\Core\Utility\GeneralUtility::readLLfile(
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::extPath('nivoslider') . 'pi1/locallang.xml',
$GLOBALS['LANG']->lang);
return $LOCAL_LANG;
}


Powermail includes facilities to upload files through the website form. Various configuration parameters exist to customize the upload according to the individual needs.
However, the default values might not fit out-of-the-box. For example, the file upload allows many different file types – from image types up to pdfs – but the file upload size is limited to less than 1MB. This will result in an error message for any file exceeding this limit.

“Folgende Fehler sind aufgetreten:” / “Diese Datei ist zu groß:”

To solve this issue, you should add the following configuration to the setup of your page template:
plugin.tx_powermail_pi1.upload.filesize=4096

The assigned value is treated as kilobytes (kb) representing 4MB in the example. Make sure you refresh your site cache when changing this parameter. You can choose any other file size if you want to.

Meanwhile, I faced two installations on servers of two differen hosting providers (1und1 and Pluspunkthosting) serving a wrong encoding even with this configuration.

To solve the problem I stopped using this classical shortcut configuration to force the database connection charset.

Instead, I used the none-shortcut conifguration for the database connection charset:

SET character_set_client = utf8
SET character_set_results = utf8
SET character_set_connection = utf8


The problem and configuration described above have been observed on Typo3 4.5.x installations.

If you face similar problems or have any questions about the solutions described, feel free to contact us.