Blog

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 blog post.

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.

Back then, when each browser had its own set and understanding of "supporting" JavaScript features, one knight in shiny armor saved us maiden developers and allowed us to focus on our tasks: jQuery. There was no necessity to remember every browser quirk or buggy implementation, jQuery was there and covered us.

In TYPO3's history there have been a lot of ups and downs, in any regard. This blog post tells you something about JavaScript in TYPO3: how was it back then, what's happening now and what will maybe happen.

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 t3editor.

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 $GLOBALS['TBE_MODULES_EXT']['xMOD_db_new_content_el']['addElClasses'].

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.