FTUG goes Butzbach: Ein Abend mit der Frankfurt TYPO3 User Group bei Flowd

Am 19. Mai 2026 ist die Frankfurt TYPO3 User Group für einen Abend nach Butzbach gefahren. 40 Kilometer nach Norden, in ein Büro, das auf den wenigsten TYPO3-Landkarten verzeichnet sein dürfte. In unseres.

Tatsächlich hat Butzbach einen Vorteil, den man auf den ersten Blick nicht erwartet: gut erreichbar aus Frankfurt, gut erreichbar aus dem Raum Gießen, und damit für Teilnehmende aus beiden Richtungen ähnlich nah.

Es war das erste Mal, dass die FTUG bei Flowd zu Gast war, und ehrlich: Wir wussten vorher nicht so recht, wie der Abend laufen würde. Drei Themen hatten wir vorbereitet: TYPO3 14, unsere Firewall und MCP.

Durch den Abend geführt haben Olivier Dobberkau und unser Sascha Egerer. Bevor wir allerdings in die eigentlichen Vorträge eingestiegen sind, ging es einmal kurz durch die Runde. Wer ist da, was macht ihr, woran arbeitet ihr gerade? Was sich dabei zeigte, ist eigentlich der Grund, warum die FTUG funktioniert: Agenturen und Freelancer in einer Runde, ohne Hierarchie, ohne Sales-Pitches, und niemand redet aneinander vorbei.

TYPO3 14: Eine Evolution mit Fokus auf den Editor

Den Auftakt hat ein kurzer Walkthrough durch die TYPO3 14 LTS gemacht. Olivier hat dafür die offizielle Marketingfolie aufgelegt, Sascha hat ergänzt, wo Hintergründe oder konkrete Beispiele gefehlt haben, und an fast jedem Punkt ist die Diskussion sofort losgegangen. Hängen geblieben sind am Ende weniger die einzelnen Features als drei größere Bewegungen: die spürbar überarbeitete accessible Editor-Experience, das neue Backend-Layout und die Modulumbenennungen, mit denen sich TYPO3 ein Stück weniger „TYPO3ish” anfühlt. Bei Menschen, die täglich im Backend unterwegs sind, war der Konsens schnell klar: keine Revolution, aber die Evolution, auf die Redaktionsteams lange gewartet haben.

Länger gehalten hat sich die Runde an einem anderen Thema: LTS-Horizonte und PHP-Legacy. TYPO3 14 setzt PHP 8.2 voraus, bekommt Bugfixes bis Ende 2027 und Sicherheits-Updates bis Mitte 2029. Klingt entspannt, ist es in der Praxis aber nicht. Im Raum saßen Agenturen und Freelancer, deren Kunden noch auf älteren TYPO3- und PHP-Versionen unterwegs sind und für die jeder Versionssprung eine politische Diskussion bedeutet. Wie sauber man die Erwartung kommuniziert, wie viel Spielraum man Kunden lässt und ab wann ein „wir bleiben noch” zu teuer wird: das sind die Fragen, auf die niemand eine fertige Antwort hatte, und entsprechend lange hat sich die Runde dabei aufgehalten.

Phirewall im Einsatz

Bevor wir in den Code gegangen sind, einen Schritt zurück: Was ist eigentlich eine Web Application Firewall, und warum sollte man eine haben? Die schnelle Antwort, dass eine WAF idealerweise der Anwendung vorgelagert sein sollte, irgendwo zwischen Internet und Server, kennt fast jeder. Die ehrlichere Antwort ist, dass das in der Praxis oft nicht geht. Komplexität, Abhängigkeit von der internen IT, Managed Hosting ohne tiefen Zugriff, Zusatzkosten, TLS-Terminierung: jeder dieser Punkte kann allein schon Grund genug sein, das Thema lieber gar nicht erst anzufassen.

Genau in diese Lücke zwischen Wunsch-Architektur und Projektrealität spielen unsere TYPO3-Extension EXT:firewall und das Paket Phirewall.

EXT:firewall und das dahinterliegende Paket Phirewall sind aus dem TYPO3 Community Budget gefördert und kommen damit aus der Community zurück in die Community. Sascha hat die wichtigsten Funktionen live durchgespielt: vom Basis-Setup über Brute-Force-Schutz, SQL-Injection- und XSS-Erkennung, Bot-Detection und Known-Scanner-Listen bis hin zu eher tiefergehenden Themen wie Sliding-Window-Rate-Limiting, dynamischen Limits und Header-Analyse.

Besonders Anklang gefunden hat ein Feature, das von der Anwendung selbst ausgeht: Phirewall lässt sich aus dem eigenen Code heraus ansprechen, um den fail2ban-Zähler für eine bestimmte IP gezielt zu erhöhen. Damit kann die Applikation selbst entscheiden, ab wann ein Zugriff verdächtig ist, und das auch dort, wo auf Infrastruktur-Ebene kein klassischer Schutz greifen kann. Typische Beispiele aus der Diskussion: wiederholte Loginversuche oder Massenanfragen auf Kontaktformularen, also genau die Muster, die ein vorgelagerter Reverse-Proxy gar nicht zu Gesicht bekommt.

Ähnlich praktisch zeigt sich Phirewall beim Thema Crawler-Last. Wenn Google, Bing oder die immer aktiveren AI-Bots eine Seite überrollen, kann das schnell den gleichen Effekt haben wie ein gezielter Angriff: die Seite ist nicht mehr erreichbar, obwohl niemand etwas Böses wollte. Phirewall reagiert über gezieltes Rate-Limiting und kann dem Crawler direkt mitteilen, wie häufig er die Seite anfragen darf. Die seriösen unter ihnen halten sich daran, weil sie auf genau diesen Standard hören.

// 1. Safelist verified search engine bots (they bypass all other rules)
$config->safelists->trustedBots(cache: $cache);

// 2. Block known attack tools
$config->blocklists->knownScanners();

// 3. Block requests missing standard browser headers
$config->blocklists->suspiciousHeaders();

// 4. Block scanner path probes
$config->blocklists->add('scanner-paths', function ($req): bool {
    $path = strtolower($req->getUri()->getPath());
    foreach (['/.env', '/.git', '/admin-panel', '/phpmyadmin'] as $probe) {
        if (str_starts_with($path, $probe)) {
            return true;
        }
    }
    return false;
});

// 5. Ban persistent scanners that keep trying
$config->fail2ban->add('persistent-scanner',
    threshold: 5, period: 60, ban: 86400,
    filter: fn($req) => true,
    key: KeyExtractors::ip()
);

// 6. Rate limit everything else
$config->throttles->add('global',
    limit: 60, period: 60,
    key: KeyExtractors::ip()
);

Code Beispiele aus unserem Vortrag zu Phirewall

Aus der Runde kam direkt der Impuls, Phirewall selbst auszuprobieren und im eigenen Team weiterzugeben. Falls jemand auf konkrete Fragen stößt, hat Sascha angeboten, beim Einstieg zu helfen. Das Projekt selbst ist noch jung: außer dem Bericht auf news.typo3.com und einem kurzen Vortrag bei der MTUG gab es bisher keine Bewerbung, und die TYPO3-Extension steht auf GitHub aktuell bei 26 Stars. Saschas Ziel ist es, mit Phirewall an die Reichweite seines PHPStan-for-TYPO3-Pakets anzuknüpfen, das in der TYPO3-Welt ein De-facto-Standard ist und auf Packagist mittlerweile über 3,8 Millionen Downloads gesammelt hat. Ein guter Anfang, aber natürlich nicht das Ende. Wer also mag: ein Stern hilft.

Aus der Diskussion sind zwei Fragen besonders hängen geblieben. Die erste, naheliegende: Wäre es nicht hilfreich, vorgefertigte oder kuratierte Blocklisten und Rate-Limit-Profile mitzuliefern? Klingt einfach, ist aber knifflig, weil die Anforderungen in echten Projekten so unterschiedlich sind, dass jede Vorlage nur ein Ausgangspunkt sein kann, nie eine fertige Lösung. Sascha denkt darüber selbst schon länger nach und sucht nach Lösungswegen, die mit dieser Vielfalt umgehen können. Die zweite, grundsätzlichere: Sollte Phirewall fester Bestandteil dessen sein, was Agenturen heute als Standard-Setup und Best Practice in TYPO3-Projekte mitbringen? Hier war sich die Runde einig: in vielen Projekten würde es echten Mehrwert bringen. Vor allem in den Konstellationen, die wir am Anfang umrissen haben, also überall dort, wo eine vorgelagerte Schutzschicht aus Infrastruktur-Gründen ohnehin keine Option ist.

MCP: Eine offene Frage

Der vielleicht spannendste Teil des Abends kam zum Schluss: eine offene Runde zur Integration des Model Context Protocol (MCP) in TYPO3. Hier prallten zum ersten Mal an dem Abend zwei berechtigte Sichtweisen aufeinander, und keine davon ist falsch.

Aus TYPO3-Perspektive ist die Antwort klar: MCP gehört sauber, durchdacht und stabil integriert. Der Core soll Core bleiben. Niemand in der Runde hatte Lust auf eine schnell hingeworfene Lösung, die in zwei Releases wieder umgebaut werden muss, und das aus guten Gründen: TYPO3 lebt davon, dass sich Projekte über Jahre auf die Plattform verlassen können.

Aus Anwender- und Editor-Sicht sieht die Sache anders aus: die Arbeitserleichterung, die MCP heute schon liefern kann, möchten viele nicht ein oder zwei Releases lang aufgeschoben sehen. Wer einmal erlebt hat, wie viel Routinearbeit aus einem Redaktionsalltag verschwinden kann, wenn die richtigen Brücken zwischen LLM und CMS gebaut sind, fragt sich zu Recht: warum noch warten?

Beides unter einen Hut zu bekommen, ist genau die Diskussion, die TYPO3 in den nächsten Monaten führen muss. Und es war eines der wenigen Themen des Abends, bei denen am Ende niemand beanspruchen wollte, die richtige Antwort zu haben. Genau das hat es zum ehrlichsten Gespräch des Abends gemacht.

Nach dem Programm

Mit der MCP-Diskussion ging das offizielle Programm in den informellen Teil über. Bier, belegte Brötchen, Muffins und Gespräche, die mehrere Themen des Abends noch eine Weile fortgesetzt haben, ohne Tagesordnung, ohne Mikro, ohne Zeitlimit.

Großer Dank an Olivier Dobberkau für die Moderation, an die FTUG dafür, dass sie diesen Schritt mit uns gewagt hat, und an alle, die den Weg zu uns gefunden haben. Es war für uns eine Premiere, und wir hoffen, dass es nicht beim einmaligen Ausflug 40 Kilometer nach Norden bleibt. Aus Frankfurt eine kurze Strecke, aus dem Raum Gießen ähnlich nah: wer mag, schafft die Anreise auch ein zweites Mal.

Den offiziellen Meetup-Eintrag findet ihr hier auf Meetup.com.