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.
We need to update software regularly. E.g. because our framework released a new major version containing breaking changes to APIs. It is a cumber stone and hard and boring task, not meant to be done by humans. Luckily we have computers and software we can use to automate boring tasks.
Our example is about TYPO3 and Aimeos updates. TYPO3 is an open source CMS while Aimeos is an open source shop framework. I'll share my experience how to automate the boring tasks during one update and how to use the automation while upgrading further installations.
We will check out rector and show how you can use existing rules with custom configuration to auto mate your code migrations.
Sometimes a headline needs to use line breaks or formatting like italic words. Some integrators define placeholders like [BR] which get substituted. We use TYPO3 native RTE functionality with stripped down configuration. This small post describes how we set it up. The goal is to have a small field and features like limited number of characters and reduced formatting possibilities.
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.
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.
I prerecorded a talk for the t3oce 2020. The talk should introduce beginners into the concepts of TYPO3. It should explain how to add and edit content, as well as what content in Context of TYPO3 actually is. Once one knows these basic concepts, I explain how to render content with TYPO3.
The talk should work as an basic introduction into TYPO3 for integrators as well as developers.
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.
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.
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.