You too can become a hero and support this Blog at GitHub Sponsors or Patreon.

More about support

This collection of small topics can be read as the completion of the sentence "Did you know that you could ...". I will update this list whenever I remember a little thing that I use in my projects or somebody gives me an example that I did not come up with myself. Hopefully you'll find something useful on this page for your TYPO3 projects.

Generate web optimized Images when rescaling

TYPO3 uses imagemagick or graphicsmagick for image manipulation such as rescaling, combining and converting of images. Out of the box the generated images are not always optimized for websites because the metadata is not stripped and the image was not compressed good enough. If you see a big difference between the generated images on your page and the output of the same image on a service like you probably can improve the situation a lot with very little effort.

After a short search you will come across solutions like this one on stack overflow: Image Magick: Image optimization for websites. So the most important options you want to add to every command are -strip and the image quality (-quality). There are two settings in TYPO3 for this and both can be found in the GFX part of the configuration in the install tool, which means they are written to the LocalConfiguration.php and can be set in $GLOBALS['TYPO3_CONF_VARS']['GFX']. Let's have a look:

$GLOBALS['TYPO3_CONF_VARS']['GFX']['jpg_quality'] = 80;
$GLOBALS['TYPO3_CONF_VARS']['GFX']['processor_stripColorProfileCommand'] = '-strip';

The first setting is for the -quality option in the image processing command and the second setting can be expanded to your needs. It will also be added to every image processing command. You should see a much better result after cleaning the processed images. Note that this does not affect images that are used in the uploaded size as those images are not processed by TYPO3 at all. To optimize those images there are extensions which optimize images upon upload.

Note that $GLOBALS['TYPO3_CONF_VARS']['GFX']['processor_stripColorProfileByDefault'] needs to be true (which is the default configuration) or else the 'processor_stripColorProfileCommand' won't be respected at all.


Turn off Exception Handling for content objects

With TYPO3 7.0 a feature was added that introduced dedicated exception handling for the rendering of Content Objects (Documentation, Patch on Gerrit). In case of an Exception during the rendering of any Content Object only the output of the single Content Object is replaced by an error code rather than the whole site being down and showing an error or the exception (depending on your displayError configuration). Here is an example of such an error message embedded in the site:

While this is a nice feature in production is is also important to know how to turn this off in development to actually see the exception again. This can simply be done in TypoScript:

config.contentObjectExceptionHandler = 0

You are welcome. What's next?


Include TypoScript without a sys_template record

Since TYPO3 8.6 it is possible to add TypoScript templates (known as sys_templates in the database) through a hook (Documentation, Patch on Gerrit). This means that no sys_template record is needed at all and you complete TypoScript inclusion can be done via PHP and therefore is deployable.

This example shows how to add a root TypoScript template to a website (such as this Blog) without any sys_template record (the database table is empty). 1st we register the hook in our ext_localconf.php:

$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['Core/TypoScript/TemplateService']['runThroughTemplatesPostProcessing'][1] =
    \DanielGoerz\MyExt\Hook\TypoScriptHook::class . '->addCustomTypoScriptTemplate';

In our hook we add sys_template record in the form of an array:

public function addCustomTypoScriptTemplate($parameters, $parentObject)
  // No template was found in rootline so far, so a custom sys_template record is added
  if ($parentObject->outermostRootlineIndexWithTemplate === 0) {
    $row = [
      'uid' => 'basis',
      'config' => '<INCLUDE_TYPOSCRIPT: source="DIR:EXT:my_ext/Configuration/TypoScript/Setup/">',
      'constants' => '<INCLUDE_TYPOSCRIPT: source="DIR:EXT:my_ext/Configuration/TypoScript/Constants/">',
      'include_static_file' => 'EXT:fluid_styled_content/Configuration/TypoScript/',
      'root' => 1,
      'pid' => 1,
      'clear' => 3
    $parentObject->processTemplate($row, '', 1, 'sys_' . $row['uid']);
    $parentObject->rootLine[] = $parentObject->absoluteRootLine[1];

The $parentObject is an instance of \TYPO3\CMS\Core\TypoScript\TemplateService and thus we can call processTemplate() directly. Because we do not have any sys_templates in our system that have been processed before the hook was executed we have to set the rootline to only contain our "template".

Our $row contains the same information as a sys_template record would. E.g. config holds the TypoScript setup and constants the constants. Every array key is named after the database field of the sys_template table.


Uninstall EXT:rsaauth if you already got SSL

There is not much to add to the headline here. EXT:rsaauth provides a password encryption for e.g. the backend login where the password is encrypted by the client and decrypted on the server side so that the password is never submitted in plain text. Obviously this is always the case with SSL and therefore there is no need to use EXT:rsaauth where SSL is enabled.

Source for Bennis Tweet:

Also, see the Documentation about the Deprecation of EXT:rsaauth in TYPO3 9.1.

Note: Remember to set the $GLOBALS['TYPO3_CONF_VARS']['FE']['loginSecurityLevel'] and ['BE']['loginSecurityLevel'] to 'normal' after uninstalling EXT:rsaauth.


Disable Caches in Development

Every TYPO3 developer knows exactly how to clear the caches of a TYPO3 system. This is because every TYPO3 developer has cleared the caches of every major TYPO3 version a million times. There is, however, a better solution for this. Caches can be deactivated in TYPO3s configuration completely wich is a great idea for development but obviously terrible for production. So make sure the following configuration is only applied in a development context (Read more about the Application Context in TYPO3):

$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['cache_core']['backend'] = \TYPO3\CMS\Core\Cache\Backend\NullBackend::class;
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['cache_hash']['backend'] = \TYPO3\CMS\Core\Cache\Backend\NullBackend::class;
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['cache_pages']['backend'] = \TYPO3\CMS\Core\Cache\Backend\NullBackend::class;
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['cache_pagesection']['backend'] = \TYPO3\CMS\Core\Cache\Backend\NullBackend::class;
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['cache_phpcode']['backend'] = \TYPO3\CMS\Core\Cache\Backend\NullBackend::class;
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['cache_runtime']['backend'] = \TYPO3\CMS\Core\Cache\Backend\TransientMemoryBackend::class;
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['cache_rootline']['backend'] = \TYPO3\CMS\Core\Cache\Backend\NullBackend::class;
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['cache_imagesizes']['backend'] = \TYPO3\CMS\Core\Cache\Backend\NullBackend::class;
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['l10n']['backend'] = \TYPO3\CMS\Core\Cache\Backend\NullBackend::class;
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['extbase_object']['backend'] = \TYPO3\CMS\Core\Cache\Backend\NullBackend::class;
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['extbase_reflection']['backend'] = \TYPO3\CMS\Core\Cache\Backend\NullBackend::class;
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['extbase_datamapfactory_datamap']['backend'] = \TYPO3\CMS\Core\Cache\Backend\NullBackend::class;

This sets everything but the RuntimeCache to a NullBackend which translate to "there is no caching". Note that before TYPO3 8LTS there are more caches involved like e.g. extbase_typo3dbbackend_tablecolumns that was removed with TYPO3 8.3. This configuration was inspired by a former version of Helmut Hummels TYPO3 Distribution on Github.


Change the order of tables in list module

Make your editors happy by putting heavily edited tables on the very top of the list module. This can be achieved with PageTSConfig and is possible since TYPO3 7.4 (Documentation, Patch on Gerrit):

mod.web_list.tableDisplayOrder {
  tx_myext_domain_model_mainmodel.before = *

This does not look like much but displaying the most important tables always at the top of the page can be a huge improvement.