See the list of my latest blog posts.
With Guzzle v7, its class
GuzzleHttp\Client became annotated as
@final as it will be a real
final class in Guzzle
v8. Extending Guzzle clients to enrich them with custom functionality or to pass configuration (e.g. API credentials) is
now discouraged and static code analysis tools like PHPStan may report this as an error. Depending on how
GuzzleHttp\Client is extended, migration may be cumbersome. I got your back, and I'll cover some common cases in this
When implementing the fundamentals of my.typo3.org, an API based on Symfony was built to feed data to applications in the TYPO3 universe, e.g. the aforementioned my.typo3.org or the Certification Platform. This API must be rock-solid, thus it has a decent test coverage for each single piece gluing the application together. With development going further, the amount of tests increased, including API endpoints that get their data from a database. In out test scenarios, we use a sqlite database as this needs no additional setup.
In the recent release of TYPO3, namely 10.4.10 at the time of writing this blog post, a patch meant to improve the backend performance was merged: the introduction of SVG icon sprites. Unfortunately, this patch had unexpected consequences and lead to some new experiences.
Once upon a time, somewhere back in mid 2015 I dived into a big adventure that came to an end (for the time being) - the core extension
When you create a new content element by using the record wizard, you'll get a tab-based list of possible content elements to choose from. In the old days, those were PHP classes known as "wizicons" and automatically created by the kickstarter extension. You may guessed it already, it's about
Migrating an old extension can be a tough job, especially when the extension was developed before TYPO3 CMS 6.2 times and thus doesn't follow the current best practises. In this article I'll show you how to migrate the TCA placed in an
ext_tables.php file of a real extension that was originally developed for TYPO3 4.5.
As stated in the previous article, you may also use PSR-7 for AJAX requests. However, the implementation in the backend and the frontend is different. This article explains how you setup so-called "routes" for backend AJAX requests and how eIDs look like for the frontend.
Ah, you have a non-extbase extension whose content is cleanly structured into Classes, Configuration, Resources, etc. But then there are these pesky
modX/index.php files for your backend modules. That's not nice, but there is help: PSR-7. This tutorial shows how to setup your backend modules according to PSR-7.