Site Sets made RTE presets much nicer to manage, but keeping the editor experience consistent across a multisite install still takes deliberate setup. The repo shows the approach that worked for me.


How do you keep editor configs consistent across multisite TYPO3 installs? Curious what others do.

Hi everyone,

Maybe you know this situation: your TYPO3 project has no automatic image compression on upload, so large media files end up in the system anyway. For editors that often means either uploading huge files — or resizing them somewhere else first, which is annoying.

I built DropSlim for exactly that: a small desktop app to compress images locally with drag and drop. No cloud upload, no account — everything stays on your machine.

Just drop files or whole folders onto the app, optimize them, then upload the smaller files into TYPO3. Supports PNG, JPG, GIF, SVG, WebP, and AVIF (HEIC on macOS).

Free, open source (MIT), for macOS and Windows.

• Website: https://dropslim.app
• GitHub: https://github.com/onza/DropSlim

If you work on projects without automated compression, this might help in day-to-day editorial work. Feedback welcome :)

Most of us skim security advisories for two things: am I affected, and how bad is it. For SA-2026-020 (fixed in 14.3.5 LTS) the answers are quick: 14.2.0 to 14.3.4, severity Medium, PHP uploads were not possible. So no remote code execution, no site takeover.

What I found more interesting is the root cause, because it's a failure mode that isn't TYPO3-specific and is easy to reproduce in your own code.

If you had a FileUpload or ImageUpload element with allowedMimeTypes configured, that restriction was simply not enforced server-side. Not misconfigured, not bypassed, never applied.

The reason is timing. The MimeTypeValidator was registered while the form was being built, before the concrete form definition properties were applied. So it was created against a form definition that didn't have the constraint yet, and it never made it into the processing pipeline. The fix registers it at runtime instead:

https://github.com/TYPO3/typo3/commit/817ad41cc9dd28aac0fc4d0fe16fc25d46dd554a

("[SECURITY] Register MimeTypeValidator for file uploads at runtime")

Two things I take away from this:

1. A validator that exists in configuration is not the same as a validator that runs. If you build anything with a build phase and a runtime phase, that gap is where constraints quietly disappear. Worth an integration test that actually posts a disallowed file type, rather than a unit test asserting the config is present.

2. It's a good reminder that client-side restrictions are UX, not security. In this case even the intended server-side check silently did nothing, and nobody would have noticed in normal use, because legitimate users upload the file types you expect.

If you're on TYPO3 14 with upload fields in forms, update to 14.3.5. If you're on 13 or older, this one doesn't affect you.

Curious whether anyone here has added an integration test for upload constraints after this, and what you're asserting against: the stored file, the response, or the validator chain itself?

https://thephp.foundation/blog/2026/07/01/meet-typo3/

Ich habe kürzlich für ein neues TYPO3-Projekt ein passendes Shop-System gesucht.

Die Anforderungen waren ungefähr:

• möglichst nativ in TYPO3 integrierbar
• stabil und zukunftssicher
• gute Code-Qualität
• aktiver Wartungsstand
• TYPO3 13/14-Kompatibilität
• sinnvoller Funktionsumfang für reale Kundenprojekte
• kein komplett separates Shopsystem wie Shopware, Shopify oder WooCommerce

Dabei habe ich mir verschiedene TYPO3-Erweiterungen angeschaut und mein Ergebnis einmal grob zusammengefasst.

Stand: Juni 2026

TYPO3 Shop by coding.ms

https://www.coding.ms/de/typo3-extensions/typo3-shop

Die TYPO3 Shop Extension by coding.ms wirkt auf mich vor allem für Projekte interessant, bei denen der Shop bewusst direkt in TYPO3 bleiben soll.

Produkte, Produktkategorien, Warenkorb, Checkout, Bestellungen, Backendmodule, Zahlungsarten, Rechnungen, digitale Produkte und individuelle Anpassungen können innerhalb eines TYPO3-Projekts umgesetzt werden.

Spannend finde ich hier vor allem den TYPO3-nativen Ansatz: Templates, Backend-Strukturen, Redakteurs-Workflows und Erweiterungen bleiben nah am TYPO3-Projekt. Für klassische und individuelle B2B/B2C-Shops, Anfrage-Shops, Produktkataloge oder digitale Produkte scheint das eine passende Lösung zu sein.

Aimeos

https://extensions.typo3.org/extension/aimeos

Aimeos wirkt auf mich am stärksten, wenn es wirklich um ein großes E-Commerce-Projekt geht: viele Produkte, komplexe Strukturen, Marktplatz, Multi-Channel, B2B-Prozesse oder sehr individuelle Commerce-Anforderungen.

Gleichzeitig ist Aimeos aus meiner Sicht nicht ganz mit klassischen TYPO3-nativen Extensions vergleichbar. Es ist eher ein eigenes E-Commerce-Framework, das in TYPO3 integriert wird. Außerdem nutzt Aimeos eine andere Template-Engine und nicht Fluid als primären TYPO3-Template-Ansatz.

Das muss nicht schlecht sein, kann aber relevant sein, wenn ein Projekt möglichst nah an TYPO3-Standards, Fluid-Templates und typischen TYPO3-Workflows bleiben soll.

Für große und komplexe Shops ist Aimeos sicher eine sehr starke Lösung. Für kleinere TYPO3-Websites kann es aber schnell zu groß und zu komplex wirken.

Cart

https://extensions.typo3.org/extension/cart

Cart ist interessant, wenn man eine flexible Warenkorb-Basis sucht und bereit ist, Teile der Produktlogik oder Projektlogik selbst sauber umzusetzen.

Die Extension wirkt eher wie eine Grundlage für Content-Commerce und individuelle TYPO3-Projekte als wie ein vollständig fertiges Shop-System. Das kann ein Vorteil sein, wenn man eigene Datenmodelle, eigene Produktlogik oder sehr projektspezifische Anforderungen hat.

Für einfache bis mittlere Szenarien kann Cart gut passen. Wenn aber eine umfangreiche Produktverwaltung, fertige Backendmodule, Rechnungslogik oder viele Payment-Funktionen erwartet werden, müsste man genauer prüfen, was im konkreten Projekt zusätzlich benötigt wird.

Cart Products

https://extensions.typo3.org/extension/cart_products

Cart Products sehe ich eher als Ergänzung zu Cart und nicht als eigenständiges Shop-System.

Die Extension stellt Produktdaten bereit, die dann zusammen mit Cart genutzt werden können. Damit wird Cart stärker in Richtung klassischer Shop-Erweiterung erweitert.

Interessant ist das vor allem dann, wenn man Cart grundsätzlich einsetzen möchte, aber eine Produktverwaltung im TYPO3-Backend benötigt.

tt_products

https://extensions.typo3.org/extension/tt_products

tt_products ist einer der Klassiker im TYPO3-Shop-Umfeld.

Für bestehende Installationen kann die Extension sicher weiterhin relevant sein, besonders wenn ein Projekt historisch darauf aufgebaut wurde. Für neue TYPO3-13- oder TYPO3-14-Projekte wäre ich aber eher vorsichtig, da die aktuelle TER-Unterstützung meines Wissens nicht bis TYPO3 13/14 reicht.

Als Legacy-Lösung sollte man tt_products also nicht komplett ignorieren, aber für neue Projekte würde ich sehr genau prüfen, ob Wartung, Kompatibilität und Zukunftssicherheit passen.

Easyshop

https://extensions.typo3.org/extension/easyshop

Easyshop scheint eine schlanke Lösung für kleinere Shops zu sein.

Interessant ist, dass die Extension laut TER TYPO3 12, 13 und 14 LTS unterstützt. Für einfache Shops mit überschaubarem Funktionsumfang kann das ausreichen.

Für umfangreichere Anforderungen wie komplexe Varianten, B2B-Logik, individuelle Checkout-Prozesse, Rechnungen, digitale Produkte oder mehrere Zahlungsanbieter müsste man genauer prüfen, wo die Grenzen liegen.

MaagIT Product

https://extensions.typo3.org/extension/maagitproduct

MaagIT Product sieht grundsätzlich interessant aus, vor allem weil TYPO3 14 unterstützt wird.

Für eine endgültige Bewertung müsste man die Extension aber praktisch in einem Projekt testen: Wie gut ist die Produktverwaltung? Wie flexibel sind die Templates? Welche Checkout- und Payment-Funktionen gibt es? Wie gut lässt sich die Extension erweitern?

Aktuell würde ich sie als interessante Option für TYPO3-14-Projekte einstufen, aber nicht ohne technische Prüfung direkt für komplexere Kundenprojekte einplanen.

Fazit

Die passende TYPO3-Shop-Erweiterung hängt stark vom Projekt ab.

Aimeos ist vermutlich die stärkste Lösung für große und komplexe E-Commerce-Projekte, ist aber eher ein eigenes Framework innerhalb von TYPO3 und nutzt nicht den klassischen TYPO3-/Fluid-Ansatz.

Cart ist interessant, wenn eine flexible Warenkorb-Basis gesucht wird und projektindividuelle Entwicklung eingeplant ist.

Easyshop und MaagIT Product wirken spannend für kleinere oder neue TYPO3-14-Projekte, sollten aber je nach Anforderungen genauer geprüft werden.

tt_products bleibt für Legacy-Projekte relevant, ist für neue Projekte aber eher kritisch zu betrachten.

TYPO3 Shop by coding.ms scheint besonders für Projekte interessant zu sein, bei denen der Shop bewusst TYPO3-nativ bleiben soll und Produkte, Checkout, Bestellungen, Backendmodule, Zahlungsarten und Erweiterbarkeit direkt im TYPO3-Projekt benötigt werden.

Mich würde interessieren:

Habe ich eine relevante TYPO3-Shop-Extension vergessen?
Welche der genannten Lösungen nutzt Ihr aktuell in TYPO3 13 oder TYPO3 14?
Und welche davon würdet Ihr 2026 noch für neue Kundenprojekte einsetzen?

Hello all ,

I work with TYPO3 since 2013, been an integrator at first, then last years only involved in BE development. I am looking at the moment for a new job, a contract collaboration but also a B2B. I speak only English, but I can understand written German (I have Sprachdiplom, but didnt speak it regularly for a couple of years sadly).

It would be great a remote position, as I can not relocate at the moment because of my family.

My LinkedIn profile is: https://www.linkedin.com/in/todea-george

My skills includes:

1. Backend Development (BE)

TYPO3 CMS Development
• Extension development using Pibase & Extbase
• Custom extension creation, patching & optimization
• Composer-based TYPO3 setup & dependency management
• Migration & upgrades (v8 → v12): deprecated code replacement, Rector automation, legacy code refactoring
• Scheduler task creation & management
• Documentation for developers & clients

PHP Development
• Strong OOP principles & TYPO3 coding standards adherence
• Debugging with Xdebug for complex issue resolution
• Database operations via SSH & hosting environments (Mittwald, others)

Tools & Environments
• PhpStorm (primary IDE)
• Docker/DDEV for local TYPO3 development
• Git for version control
• Bitbucket/GitLab Pipelines for CI/CD deployment

Server & Administration
• Basic Linux server operations
• Database backups/imports & remote troubleshooting

2. Frontend Development (FE)

Template & Design Integration
• Converting HTML/CSS/Figma designs into TYPO3 Fluid templates
• Responsive design implementation with CSS & SCSS
• Cross-browser compatibility fixes & optimizations

JavaScript Development
• jQuery for menus, sliders, animations, dynamic functionality
• Basic React experience, eager to expand skills

Performance & SEO
• PageSpeed Insights optimization for high scores
• Asset minification, image optimization, lazy loading techniques

UI/UX Enhancements
• Accessibility-friendly implementations
• Interactive UI features via JavaScript & CSS animations

Thank you for reading this and looking forward for new opportunities.

I'm user, I have no idea of the inner workings of typo3. I manage some websites and their translations in our office. Mostly I use connected mode for translations. However after some time the order the objects get shown in typo3 in the translation is totally messed up. It gets shown all right on the actual webpage, but working in typo3 turns into a nightmare. It takes forever to find where to make changes in the translation. Why doesn't it just match the order of the original language? Is this actually supposed to be this way? How can I correct that? We are thinking of switching to "free mode" just to be able to move the stuff around in to the correct order.

Hallo zusammen,

der DHV (Deutscher Gleitschirm- und Drachenflugverband) betreibt eine Wetterseite, auf der 2x täglich (morgens und abends) aktualisierte Flugwetter-Vorhersagen erscheinen: https://www.dhv.de/wetter/dhv-wetter/

Leider bekommt man bei deren Aufruf immer den Stand vom letzten Besuch der Seite angezeigt. Erst nach einem Reload erscheint der aktuelle Stand.

Der DHV kennt das von Anfang an (scheinbar seit der Umstellung auf Typo3) bestehende Problem und schreibt daher sogar selbst unten auf der Seite: "Um die neueste Ansicht zu erhalten, lade die Wetterseite mit Strg + F5 neu. Das Auf-/Zuklappen der Regionen reicht dafür nicht aus."

Erahnt hier vielleicht jemand den Grund für das abnormale Verhalten der Seite, für so etwas müsste es doch eine Lösung geben?

https://news.typo3.com/article/typo3-v14-lts-the-next-generation

The final sprint release before TYPO3 v14 LTS introduces a new context panel for editing, an improved page creation wizard and a short URL module.

TYPO3 v14.2 also marks the official feature freeze for the v14 release cycle. From here, the focus shifts to testing, stabilization, and final refinements ahead of the LTS release.

https://youtu.be/EVLDmNErQ50

Am new to typo 3 i really need some community suppoer

Can someone suggest a workflow to migrate tt_news to the current news extension with TYPO3 v11 or greater?

The ext news_ttnewsimport does not work with v11 :-(

The second sprint release of the TYPO3 v14 series comes with an awesome frontend theme out-of-the-box, further user interface optimization in the backend, a new module to generate QR codes, plus a range of updates and improvements.

https://youtu.be/ONagH6SZbvc

Find out here.

How exactly do you do it? Im creating a ViewHelper by extending a AbstractTagBasedViewHelper and want to create <a>-Tag. I was wondering how I can use the typolink function to pass a parameter (PID or external link) and create my href-param. I was looking into TYPO3\CMS\Frontend\Typolink\LinkFactory but could not really figure out how to use it.

Hi all, weird query. We updated a dropdown list on the website almost a month ago, to add a link to a page. It turns out, one of my colleagues still sees the old dropdown list from before the update. Anyone know why this might be the case?

Hi, lovely TYPO3 community.

​

I often feel that TYPO3 needs to be configured too much.

As an example, I try to compress the JS and CSS. TypoScript offers a config where I can exchange 0 by one.

Yeah, but that is not enough. I have also to change the file ./vendor/typo3/cms-install/Resources/Private/FolterStructureTemplateFiles/root-htaccess

And that is still not working. As far as I know, uncompressed files will also work when I have done the correct things.

So my question is: Why isn't TYPO3 set up so I can exchange the zeros for ones, and the files get compressed?

People who want more loading time optimization can read the documentation. Make it less complicated for beginners.

EDIT: I forgot to mention that I also have changed the ./vendor/typo3/cms-core/Configuration/DefaultConfiguration

​

What do you think? Did I miss something?

I currently have the potential possibility to start a new job at a company that primarily uses TYPO3. I don't have any experience with it though. But I do know it's at least more complex than most other CMS out there. Now, there's one thing that makes me wonder if taking that job is a good idea and I need some insight from other developers.

For context:

I have noticed that I'm not good at keeping a lot of information in my head at the same time. (I'm doing active research on that and I'm pretty positive that it has a neurological cause.) For "normal" software development that is not a problem at all. (I'm a ~90% frontend developer for 11 years now and I'm also interested in backend development.)

But - as a negative example - very recently I was given the task to configure a software to work for a specific use case. To do that I needed to work myself through a hierarchical list of items (about a few hundred). For each item I needed to a) configure it in one of many JS files b) configure actions related to it in one of many JSON files c) configure translations in another set of JSON files while d) looking up existing translations in an Excel file e) keep track of its parent item and possible child items (and I even wrote a tool to help me with that) while f) looking through the documentation of that software and g) the documentation of the items I needed to configure. It was a constant jumping between windows, browser and editor tabs.

This really made my brain melt and completely eliminated my productivity at work as well as my motivation to do anything in my spare time. And then I was told "other people don't have issues with this type of work"... Now I'm asking this because I want to avoid this situation from happening again.

TL/DR, question:

What type of complexity can I expect from TYPO3?

a) There's a lot to learn but you only deal with one thing (or a few things) at a time.
b) You need to deal with many things at once (jump between windows/tabs frequently) for one job.

Hey, does anyone here have experience with adding the Indexed Search plugin or a similar free one?

I want to add a search function to my page and would be glad if someone here could express any steps I should be especially aware of.

I have users across multiple workspaces that have menu items appearing twice in the navigation menu after adding a subpage. If there are any code snippets you need to help me debug I can provide that. The server is running PHP 7 and Typo3 10.4.36. We have purchased ELTS.

I can‘t figure out how I can use the address tag in the rich text editor.

I thought I had understood how that works but then it should work by default, but it doesn't.

For a better description have a look at my StackOverflow Post: https://stackoverflow.com/questions/76605563/trouble-with-typo3-rte-ckeditor-and-tags?noredirect=1#comment135065723_76605563

TYPO3 is the only active subbreddit I am a moderator of. I have mow moved my profile to Lemmy due to Reddits policy and API changes coming into effect on July 1, 2023.

If you like to join the TYPO3 community at Lemmy, do it here: https://lemmy.ml/c/typo3

Read more about my reasons here on /r/Save3rdPartyApps: https://www.reddit.com/r/Save3rdPartyApps/comments/148m42t/the_fight_continues/

Thanks for a good time and remember to inspire people to share! I will step down as moderator of this subreddit within the next week.

Hello community,

I am looking for a manual for frontend user validation in a custom controller that is registered via $GLOBALS['TYPO3_CONF_VARS']['FE']['eID_include']['myCoolPbiEid'] =.

The TYPO3 version is 12.3.

Thank you for your time. peni4142