TYPO3 provides a comprehensive caching implementation. Built into all parts of TYPO3. By default TYPO3 tries hard to provide a working caching solution for Websites. This way all generated content is cached whenever possible and delivered right from cache without rendering. This leads to some issues if dynamic content is added. Some bypass this issue by deactivating caching partly or for whole pages.
This post explains how to configure TYPO3 to make caching work without deactivating it. One place where caching does not work out of the box is changing files via Filelist module, changes there will not be reflected in content elements using a file reference. This example is used to explain how caching works in TYPO3 and how to adjust caching.
TYPO3 uses pages to organise the structure of a website. This leads to situations where you have a specific page for a feature, e.g. a page “Search” containing the plugin to display search results. Or a page containing the profile of the currently logged in user. Typically links to these pages are scattered all over the website, e.g. within some content elements, inside the page layout like header and within some plugins.
This Blog post explains how to provide the page uid for a specific page, to all three kinds of “content”, where you typically need this information, with three lines of TypoScript.
From time to time you need to test some email within your TYPO3 installation. Whether it might be that you are a developer sending some mail via a CommandController or Plugin, or you are an integrator configuring EXT:powermail or EXT:form to deliver some mail.
In all cases you need to make sure this mail is not send to external addresses like your customer during development and testing. Also you need to be able to check the content of the mail. In this blog post you will learn what mbox is and how to use it.
As an TYPO3 integrator or developer you will login into the same TYPO3 installations multiple times during the same day. There are different ways to prevent the need to login over and over again. One is to add a bit of PHP to the installation, e.g. inside AdditionalConfiguration.php to prevent any login. This should save a lot of time during development.
In this blog post this solution will be shown and explained. You will never ever have to login on your local installation anymore.
During development for TYPO3 you often run into Exceptions. They do not look very nice. A much nicer alternative might be whoops which @dk2kde told me about. It will not only handle exceptions, but also PHP Errors like syntax errors.
In this small blog post I will show you how to use whoops as exception handler for TYPO3 projects during local development.
TYPO3s new form framework allows to write custom form elements. This way you are able to define a new select element, based on the existing one, but filled with options fetched from database.
E.g. you want your user to select from sys_category or some other custom records. In this blog post I will show how to provide the necessary logic in a custom PHP class, how to register a new element extending the existing one and how to use this new element in your forms.
Since TYPO3 CMS Version 8 there is a new Form framework heavily inspired by Neos Form Framework. As most parts of Neos / Flow it’s a great heavy dynamic component with great power.
In this post I will show how easy it is to write a custom finisher to crypt submitted values using the SaltedPasswords extension. This enables you to write fe_user registration forms without the need of 3rd party extensions.
TYPO3 provides a way of dependency injection. This way you do not need to resolve dependencies inside of your code, but the framework will resolve and provide the dependencies for you. This is provided by the framework Extbase, back ported of Flow.
The main benefit is the flexibility. Using Interfaces to define dependencies, instead of concrete classes, it’s possible to exchange injected dependencies just by configuring the framework. This way you can exchange classes in 3rd party code and receive a huge flexibility. Same goes for testing your code. In this Post I will show you the different ways to make use of dependency injection inside of TYPO3 and provide help for edge cases.
TYPO3 CMS allows you to build a language menu to enable the frontend user to switch the current language. This menu is generated via TypoScript using optionSplit. Just start a query and take a look at the snippets. This way has one big drawback. In a multi domain setup you have to change the config
We have overcame this issue with one language menu working for all setup on all domains without the need to adjust anything. Read here how to achieve this.
TYPO3 ships with a debugging process called DevLog. It’s a function provided by the core and used by many extensions. The main purpose is to log information for debugging. Beside the new Core feature Logging Framework, it’s older and therefore used in more extensions. TYPO3 doesn’t ship with a handler for this function, it’s possible to provide handler via TYPO3’s Events, Signals and Hooks mechanism and the popular devlog extension is installed on many TYPO3 installations to have a handler which logs everything to the database and provide a backend module to see the entries. But that’s not necessary, you can register your own, very small handler in your AdditionalConfiguration.php or your distribution.
Sometimes you need settings like TypoScript in a class which is not your controller. Inside a controller, the Extbase framework already injects the settings for you, so you are able to access them under $this->settings.
In all other classes it’s easy to let Extbase inject the settings for you. Just include the following code, and make sure you instantiate the class via \TYPO3\CMS\Extbase\Object\ObjectManager instead of \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance().