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.
TYPO3 CMS is an open source content management system with lots of contributions. The system has a huge code base which is partially very old and therefore contains a lot of legacy code. Therefore it’s very important to cover existing features with tests, to not break anything if you improve the system.
TYPO3 CMS was improved with a lot of unit and functional tests in the past. Since some time, there are also acceptance tests available, which will test functionality of the backend. All of these tests are executed by the TYPO3 CMS own Bamboo to make sure no merge will break anything. If you want to execute the existing acceptance tests, you already might be a developer and luckily, the repository contains all necessary information to get started.
In this Blog post I will show how to get the necessary information out of the source files and to execute these tests. This should also help in the future, as the way to get there is described, not only how to execute the tests now.
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.
PHP_CodeSniffer is a command line tool allowing to check php, js and css. The main use case is to check code styles like the popular PSR-2. Beside checking coding styles, some communities are already using this tool for further checks like direct access to global variables like $_POST instead of using the provided API, e.g. take a look at Magento PHP_CodeSniffer Coding Standard. Also there is a standard to check compatibility of the code with PHP versions.
Beside this use cases and huge benefits, there is another use case: automated code migrations that can be achieved using PHP_CodeSniffer. In this blog post I will provide the necessary basics and an example how to auto migrate your PHP code using PHP_CodeSniffer.
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().
TYPO3 provides some record types like pages, content, files and categories. With this basic set of record types you can build full blown websites containing products, projects, Blog posts, news and many more different content types without the need of any plugins, it’s just configuration in TYPO3.
To provide a search with filter to the visitor you can use solr as an extension. With these combination there is no need for further custom record types like news or products and plugins or database tables with custom search and filter implementations for all of them.
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.
Documentation was never easier, with a Framework like Sphinx and a hoster like Read the docs. All you need is a repository containing your Documentation written with Sphinx and an account at Read the docs. Plantuml can be used in addition to generate UML-Diagrams using plain text. The result can be SVG files in the same color as your Documentation. The whole setup and workflow for that will be explained in this Blog post. After reading the post, you are able to kickstart a new documentation and host it at Read the docs. You then can dig deeper and adjust it to your needs.
All instructions are tested on OS X, I’ll not document for Windows. Unix systems should be the same as OS X and you probably already know how to do it yourself.
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.