Image Database for TYPO3

Ab 5.000 Bildern wird TYPO3s FAL zum Engpass

TYPO3s File Abstraction Layer verwaltet Dateien zuverlässig, solange die Menge überschaubar bleibt. Bei 500 Bildern funktioniert FAL einwandfrei. Bei 5.000 wird die Suche langsam. Bei 20.000 ist die Dateiliste im Backend kaum noch nutzbar. Unternehmen mit großen Bildbeständen brauchen mehr als ein Dateisystem: Sie brauchen ein Digital Asset Management. Die Frage ist, ob man TYPO3s FAL zum DAM ausbaut oder ein externes System anbindet.

Beide Wege funktionieren. Der interne Ausbau über FAL-Erweiterungen kostet weniger und bleibt im TYPO3-Ökosystem. Die externe Anbindung (Celum, Canto, Cloudinary, Bynder) bietet mehr Funktionen, erfordert aber Lizenzen, Schnittstellen-Pflege und doppelte Datenhaltungslogik.

Typical use cases

Produzierende Unternehmen mit Produktfotografie. Ein Maschinenbauer hat 8.000 Produktfotos in verschiedenen Auflösungen, dazu CAD-Renderings, Anwendungsbilder und Datenblätter. Jedes Produkt existiert in 5-10 Bild-Varianten. Ohne systematische Verschlagwortung finden Redakteure das richtige Bild nicht, oder schlimmer, sie verwenden ein veraltetes. Auto-Tagging per KI analysiert Bildinhalte und vergibt Tags automatisch. Bei einem Kunden mit 12.000 Produktbildern reduzierte KI-basiertes Auto-Tagging die Verschlagwortungszeit von 3 Wochen auf 2 Tage.

Medienunternehmen und Verlage. Nachrichtenportale, Magazine und Corporate-Publishing-Abteilungen produzieren täglich neues Bildmaterial. Die Anforderungen: schnelle Suche, Rechteverwaltung (Lizenzablauf, Nutzungsrechte pro Kanal), automatische Formatkonvertierung und Metadaten-Vererbung. Ein erweitertes FAL mit Custom-Feldern deckt die Basisfunktionen ab. Für Rechteverwaltung und Workflow-Steuerung braucht es ein externes DAM.

Hochschulen und Forschungseinrichtungen. Universitäten verwalten Campusbilder, Veranstaltungsfotos, Forschungsgrafiken und Portraits der Mitarbeitenden. Die Herausforderung: dezentrale Zulieferung aus 30+ Fachbereichen in ein zentrales System. TYPO3 FAL mit Kategorie-basierter Ordnerstruktur und Zugriffsrechten pro Benutzergruppe löst das. Externe DAM-Systeme sind hier selten wirtschaftlich.

Technical architecture

TYPO3s FAL besteht aus drei Schichten: dem Storage Driver (lokales Dateisystem, S3, Azure), dem File Index (Datenbanktabelle sys_file mit Metadaten) und dem File Reference System (Verknüpfung zwischen Dateien und Content-Elementen). Eine Bilddatenbank in TYPO3 erweitert primär die mittlere Schicht, den File Index.

Die einfachste Erweiterung: Custom-Felder in der Tabelle sys_file_metadata. TYPO3 bringt bereits Felder wie title, description, alternative und copyright mit. Über TCA lassen sich beliebige weitere Felder ergänzen: photographer, license_type, expiry_date, usage_rights, location, keywords_auto. Diese Felder erscheinen im Datei-Metadaten-Dialog im Backend.

Für die Suche bietet TYPO3 standardmäßig nur eine Dateiname-Suche im File List Modul. Eine echte Volltextsuche über alle Metadaten erfordert entweder eine Solr-Integration (über EXT:solrfal) oder ein Custom Backend-Modul mit Elasticsearch-Anbindung. Solr durchsucht dann nicht nur Dateinamen, sondern alle Metadatenfelder, einschließlich automatisch generierter Tags.

Auto-Tagging per KI funktioniert über einen Scheduler-Task, der neue Dateien an einen Bilderkennungsdienst sendet (Google Cloud Vision, AWS Rekognition oder ein selbstgehostetes Modell) und die erkannten Tags in die Metadaten-Felder schreibt. Der Prozess ist asynchron und belastet das Backend nicht. Bei Erstimport großer Bestände rechnet man mit circa 1 Sekunde pro Bild für die API-Analyse.

Common problems and solutions

FAL-Index und Dateisystem laufen auseinander. Wenn Dateien per FTP hochgeladen oder manuell gelöscht werden, stimmt der FAL-Index nicht mehr mit dem Dateisystem überein. TYPO3 zeigt Dateien an, die nicht existieren, oder kennt vorhandene Dateien nicht. Lösung: Den FAL-Indexer regelmäßig per Scheduler laufen lassen (empfohlen: täglich nachts). Der Indexer gleicht Dateisystem und Datenbank ab. Bei 50.000 Dateien dauert der Abgleich circa 10-15 Minuten.

Metadaten gehen bei TYPO3-Upgrades verloren. Custom-Felder in sys_file_metadata überleben TYPO3-Upgrades, wenn sie über eine eigene Extension definiert sind. Werden sie direkt in der TCA-Override-Datei des Sitepackages definiert, können sie bei strukturellen Änderungen der Metadaten-Tabelle verloren gehen. Lösung: Bilddatenbank-Felder immer in einer eigenen kleinen Extension kapseln, nicht im Sitepackage.

Backend-Performance bei großen Dateibäumen. Das File List Modul wird ab 1.000 Dateien pro Ordner träge, weil es Thumbnails für jedes Bild generiert. Lösung: Ordnerstruktur mit maximal 500 Dateien pro Verzeichnis anlegen und die Thumbnail-Generierung im File List auf “on demand” umstellen.

Migration and version compatibility

TYPO3s FAL ist seit Version 6.0 (2012) Bestandteil des Core und wird mit jeder Major-Version weiterentwickelt. Die FAL-API ist stabil, Custom-Felder und Indexer funktionieren von TYPO3 v10 bis v13 ohne Anpassungen. Die Solr-FAL-Extension (EXT:solrfal) unterstützt TYPO3 v12, für v13 ist Kompatibilität angekündigt.

Wer von einem externen DAM-System auf TYPO3 FAL migriert, muss die Metadaten mappen. Jedes DAM-System hat ein eigenes Datenmodell. Die Migration selbst ist ein Datenbank-Job: Export aus dem DAM als CSV/JSON, Mapping der Felder auf sys_file_metadata, Import per TYPO3 DataHandler oder direktem SQL.

Die Entscheidung “FAL-Ausbau vs. externes DAM” hängt von zwei Faktoren ab: Bestandsgröße und Workflow-Komplexität. Bis circa 10.000 Assets und ohne Freigabe-Workflows reicht erweitertes FAL. Darüber hinaus oder bei Anforderungen wie automatischer Lizenzverwaltung und Multi-Channel-Distribution lohnt sich ein spezialisiertes DAM mit TYPO3-Connector. Gosign berät zu beiden Varianten und implementiert sowohl FAL-Erweiterungen als auch DAM-Integrationen.