TYPO3 developers are often faced with the same requirement: Import data into TYPO3. TYPO3 itself offers many ways to import data into the system. The DataHandler (TCE) or Extbase might come to your mind, as well as plain Doctrine DBAL queries.
This post will explain my views on each of the options and their pros and cons. I don't consider any of them the general solution, but the pros and cons might help you find the one suiting your current use case best.
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.
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.
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 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().