Icons are dead, long live broken icons!

| 5 minutes

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.

tl;dr: This blog post is a mix of "how good things went wrong" in terms of TYPO3 icons and personal drama based on recent observations. You're still with me? Great, please read further.

As always when patches for open source projects are written, everybody does it with best intentions to scratch own itches and those of other people, the same happens for TYPO3. Some changes have a little impact, others include major refactorings. This patch introduces SVG icon sprites for an improved overall backend performance:

  • Instead of hundreds of icons, only a few sprite files needs to be loaded
  • Icons are rendered in shadow DOM which lowers the initial document size

As written above each change has an impact, but sometimes the expected impact turns out to be wrong. The same thing happened with this very change. With an upgrade of the @typo3/icons package to version 2.0, some important restructurings were done which applies to the TYPO3 CMS as well, of course.

We have APIs

Previously, icons were stored in sysext/core/Resources/Public/T3Icons, which is considered being private API. Yes, private, albeit the icons are stored in the Public/ directory, simply because those icons are publicly callable assets.

This is not a bad thing, as with TYPO3 7.5 an Icon API was introduced, which is in place for five years already at the time of writing this blog post.


An attentive reader noticed the word "previously" in the upper paragraph. With switching to version 2 of the icon repository, the location of these icons changed, which isn't a big deal as there is a stable API in place, right? Wrong. It turned out extension authors out there rely on the absolute icon paths, either because of lack of knowledge, "it's there" or mistrust in the APIs.

Altough some people allege it, this change was not meant to break existing extensions, otherwise it would have been marked as "breaking" and it would not have been backported to v10. On the other hand, relying on a specific, non-documented behavior makes every bugfix a breaking change.

Some honest words here: under regular circumstances I'd say "well yeah, you're out of luck". Unfortunately, I noticed that the general tone became pretty harsh lately especially on social media. People sometimes demand things in free software (please read the GPL, especially the "NO WARRANTY" part, thanks!), or, in even worse cases, attacking the whole team who works hard on making TYPO3 better step-by-step.

Whatever the reason is, such cases make decisions even harder as everything must be considered being "breaking" in one way or another. Be assured that nobody "hides" a breaking change somewhere as a drive-by change willingly.

Header photo by Harpal Singh on Unsplash.

Previous Post Next Post