filefill für TYPO3

filefill spart Entwicklern und Agenturen Tage Synchronisierungsaufwand - die Extension lädt fehlende Dateien aus fileadmin automatisch vom Produktiv-Server nach, wenn sie tatsächlich gebraucht werden

Wer an einem bestehenden TYPO3-Projekt arbeitet, kennt das Ritual: Das lokale Setup steht, der Datenbank-Dump ist eingespielt, aber auf jeder zweiten Seite erscheinen Platzhalter statt Bilder. Der Grund ist banal: Das fileadmin-Verzeichnis des Live-Systems enthält Gigabyte an Assets, die lokal fehlen. Die klassische Lösung war rsync oder scp über Stunden. filefill schneidet diesen Schritt komplett heraus. Statt alle Dateien vorab zu kopieren, lädt die Extension beim ersten Zugriff genau die benötigte Datei vom konfigurierten Remote-Server nach - on demand, transparent, mit Caching. Für Agenturen, die dauerhaft an mehreren Projekten arbeiten, spart das nicht nur Speicher, sondern auch Stunden pro Setup.

Der Produktivitätsgewinn ist größer als er auf den ersten Blick aussieht. Ein neuer Entwickler ist nicht erst nach einer Stunde Download-Wartezeit arbeitsfähig, sondern nach wenigen Minuten. Ein Code-Review auf einem vergessenen Feature-Branch braucht keinen aktuellen File-Sync. Eine kurze Reproduktion eines Bug-Reports zieht sich nicht durch den halben Tag. Die kleine Extension adressiert damit einen echten Engpass in der täglichen Entwickler-Arbeit.

Typische Einsatzszenarien

Der häufigste Fall ist das lokale Entwicklungs-Setup. Ein Entwickler klont das TYPO3-Projekt, richtet DDEV oder Docker ein und spielt den aktuellen Datenbank-Dump ein. Statt zusätzlich 30 GB fileadmin-Daten herunterzuladen, konfiguriert er filefill mit der Basis-URL des Live-Systems. Bei jedem Seitenaufruf, der ein Bild oder Dokument anfordert, prüft die Extension, ob die Datei lokal existiert, und lädt sie bei Bedarf nach. Nach ein paar Tagen Arbeit sind nur die tatsächlich benötigten Dateien lokal, der Rest bleibt auf dem Server.

Der zweite Fall sind Staging-Umgebungen. Eine Agentur pflegt für jedes Projekt ein Staging-System, auf dem Redakteure Inhalte vor dem Live-Gang testen. Diese Staging-Systeme müssen nicht alle Bilder vorhalten, sondern nur die der aktuellen Releases. filefill sorgt dafür, dass ältere Inhalte trotzdem funktionieren, weil die Dateien bei Bedarf vom Live-System gezogen werden.

Dritter Einsatz: Disaster Recovery und Hotfix-Szenarien. Wenn ein TYPO3-System schnell auf einer neuen Maschine hochgefahren werden muss - etwa nach einem Serverausfall oder bei einer dringenden Umgebungs-Migration - kann filefill während der ersten Stunden die Asset-Beschaffung überbrücken, bis der vollständige Backup-Restore durch ist.

Technische Architektur

filefill klinkt sich in das FAL-System von TYPO3 ein, genauer in den Resource-Retrieval-Mechanismus. Sobald TYPO3 eine Datei aus der lokalen Storage anfordert und feststellt, dass sie nicht existiert, greift ein Event-Listener von filefill ein. Die Extension prüft eine Liste konfigurierter “Sources” in der Reihenfolge ihrer Priorität und versucht, die Datei von dort nachzuladen. Erfolgreich geladene Dateien werden lokal gespeichert, sodass der nächste Zugriff ohne Remote-Request auskommt.

Die Konfiguration erfolgt über die Extension-Einstellungen im Install-Tool. Typischerweise wird eine Remote-Source mit Basis-URL, optional mit HTTP-Basic-Auth-Credentials, hinterlegt. Für Setups mit CDN oder S3 kann auch dieser Pfad als Quelle dienen. Die Extension unterstützt mehrere Sources, was für komplexere Szenarien mit getrennten Asset-Servern hilfreich ist.

Wichtig ist, dass filefill nur passiv arbeitet. Die Extension lädt nichts vorab, sondern reagiert ausschließlich auf konkrete Datei-Anfragen. Das macht sie genügsam im Ressourcenverbrauch und unauffällig im Betrieb. Die Integration mit DDEV, Docker Compose oder Lando ist trivial, weil die Extension keine zusätzlichen Services braucht.

Häufige Probleme und Lösungen

Das erste Problem sind Zugriffsbeschränkungen. Wenn der Live-Server Bilder nur für eingeloggte Nutzer ausliefert oder bestimmte Pfade per htaccess schützt, kann filefill sie nicht ohne weiteres nachladen. Die Lösung liegt in der korrekten Konfiguration der HTTP-Authentifizierung und gegebenenfalls in einer Whitelist-Regel auf dem Live-Server, die der Entwicklungsumgebung Zugriff auf den fileadmin-Pfad gibt.

Zweites Problem: versehentlicher Einsatz in Produktion. Wenn filefill in einer Live-Umgebung aktiv ist und die Remote-Source dieselbe Umgebung ist, entsteht eine gefährliche Rekursion. Die Extension sollte niemals in Produktion laufen. Die pragmatische Lösung ist, filefill nur im Composer-Block “require-dev” zu führen und über Environment-Variablen zu aktivieren, nicht über das Install-Tool.

Drittes Problem: inkonsistente Datei-Stände. Wenn das Live-System eine Datei austauscht, aber die lokale Kopie bereits gecached ist, sieht der Entwickler die alte Version. Die Lösung ist ein gelegentliches Leeren des lokalen fileadmin oder ein Cache-Busting über die Remote-Source. Für die tägliche Arbeit ist das selten ein Problem, weil Dateinamen bei Austausch normalerweise neu sind.

Migration und Versions-Kompatibilität

filefill ist mit TYPO3 v11, v12 und v13 kompatibel und wird aktiv weiterentwickelt. Bei Upgrades sollte die Extension-Version zur TYPO3-Version passen, weil das FAL-Event-System zwischen v11 und v12 kleinere Änderungen erfahren hat. Wer die Extension in bestehenden Entwicklungsprozessen nutzt, muss bei größeren Upgrades kurz testen, ob alle Sources noch korrekt erreichbar sind.

Eine verwandte Lösung ist EXT:aus_driver_amazon_s3, die fileadmin direkt in einem S3-Bucket hält. Der Unterschied: aus_driver_amazon_s3 ist eine Produktions-Lösung, filefill eine Entwicklungs-Hilfe. Beide ergänzen sich - ein Projekt mit S3-Storage in Produktion kann filefill lokal einsetzen, um nur die aktuell bearbeiteten Dateien aus dem Bucket zu ziehen.

Für Agenturen, die filefill standardisiert einsetzen, bietet sich eine Dokumentation im Projektwiki an, die erklärt, wie die Extension aktiviert wird, welche Credentials nötig sind und wie man bei Problemen vorgeht. Das reduziert den Support-Aufwand im Team und macht das Onboarding neuer Entwickler verlässlich. Ergänzend lohnt sich ein kurzes Skript, das beim Setup einer neuen lokalen Umgebung die richtige Konfiguration automatisch einträgt.

Gosign installiert und konfiguriert filefill in Entwicklungsumgebungen und integriert die Extension in DDEV- und Docker-Setups, sodass neue Projektmitglieder innerhalb weniger Minuten einsatzfähig sind.