I thought it is fine to use older no longer supported PHP versions as long as they are supported by the OS (e.g. Debian, Ubuntu, etc.). I've changed my mind after reading blog posts and noticing a change within PHP ecosystem.
Let me explain why I changed my mind and why you should prefer official supported versions instead. This not only is true for PHP but any software.
Functional tests won't mock single implementations. But code often interacts with external systems by sending requests, e.g. via Guzzle. Guzzle is the default library used within TYPO3, so you might need to mock the requests within functional tests.
This blog post explains our solution which is based on Guzzle Docs and Susis Blog post on how to mock Guzzle Client implementation within Unit Tests.
I know many editors and people complaining about TYPO3 for various reasons. In this video I'll show an actual customer project. I demonstrate how performant a website build with TYPO3 and EXT:solr can be. And I demonstrate how pleasant the TYPO3 backend can be.
TypoScript by concept is meant for frontend context only. There is TSconfig for backend as well. Extbase introduced a way to also configure backend modules via TypoScript. Nowadays TypoScript is also used in other context, e.g. scheduler tasks or commands.
I'll explain how the actual TypoScript is loaded, so you understand that part and can use it.
Some of you, like one of our customers, are still on TYPO3 v8 or 9. We all dream of a bright future where we get shiny new features like new event handling by PSR-14, and dependency injection by PSR-11. Still we can write code that actually follows the new features and provides benefits today. Updates will become very smooth thanks to rector which could auto migrate everything necessary.
Read the following sections to get concrete examples on how we write code in 8.7 that will be auto migrated to 10.4 (11.x) via rector and how we profit today.
Since TYPO3 10.0 it is possible, actually necessary, to use FQCN (=Fully Qualified Class Names) for controllers when configuring plugins and modules. This provides a new benefit in terms of reusing and sharing code between different extensions.
This blog post will explain the benefit and provide an outlook in a possible future of TYPO3 Extbase extensions.
TYPO3 has hidden gems. One of them is the system extension feedit which adds frontend editing to TYPO3. It adds some options to the admin panel in TYPO3 frontend, and allows integrators to add more fine grained edit experience right into the content.
This post will cover most of the provided features, with screenshots and how to configure the extension. I'll also explain why I prefer the approach of EXT:feedit over extensions like EXT:frontend_editing.
With TYPO3 version 10 around the corner, it is time to have a deeper look at new features. I often hear something like "those features are only targeting developers". Therefore I try to promote opportunities for agencies and users, provided by the new more technical features.
Expect a round up of ext:dashboard, new notification API, PSR-14 Events, and some more.
When using mysqldump, the tool has to be compatible with mysql server version. Some hosters might not provide such an environment. That's one reason when you wanna use mysqldump on your local system to create an mysql dump from a foreign database.
Most environments prevent remote access to the database server, which is a good thing. But this would prevent you from using mysqldump on your local environment. To overcome this issue, you can use ssh to create a temporary tunnel to the database server through another server, e.g. the production system.
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.
As more and more people like to lint their files, it’s obvious that we also should lint our Typoscript files in TYPO3 projects. Therefore Martin Helmich has created a Typoscript parser and Typoscript linter.
In this blog post you will learn how to integrate this linter into vim and neovim by using syntastic as a plugin.
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.
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.
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 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.
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.
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().