Baza obrazów dla TYPO3

Od 5000 obrazów FAL TYPO3 staje się wąskim gardłem

File Abstraction Layer TYPO3 zarządza plikami niezawodnie, dopóki ich ilość pozostaje przejrzysta. Przy 500 obrazach FAL działa bez zarzutu. Przy 5000 wyszukiwanie staje się wolne. Przy 20 000 lista plików w backendzie jest praktycznie nieużywalna. Przedsiębiorstwa z dużymi zasobami obrazów potrzebują czegoś więcej niż systemu plików: potrzebują Digital Asset Management. Pytanie brzmi, czy rozbudować FAL TYPO3 do DAM, czy podłączyć system zewnętrzny.

Oba podejścia działają. Wewnętrzna rozbudowa przez rozszerzenia FAL kosztuje mniej i pozostaje w ekosystemie TYPO3. Zewnętrzna integracja (Celum, Canto, Cloudinary, Bynder) oferuje więcej funkcji, ale wymaga licencji, utrzymania interfejsów i podwójnej logiki przechowywania danych.

Typowe scenariusze zastosowania

Przedsiębiorstwa produkcyjne z fotografią produktową. Producent maszyn ma 8000 zdjęć produktów w różnych rozdzielczościach, do tego renderingi CAD, zdjęcia zastosowań i karty katalogowe. Każdy produkt istnieje w 5-10 wariantach obrazu. Bez systematycznego tagowania redaktorzy nie znajdują właściwego obrazu - lub co gorsza, używają przestarzałego. Auto-tagowanie przez AI analizuje zawartość obrazów i automatycznie przypisuje tagi. U klienta z 12 000 zdjęć produktów auto-tagowanie oparte na AI skróciło czas opisywania z 3 tygodni do 2 dni.

Przedsiębiorstwa mediowe i wydawnictwa. Portale informacyjne, magazyny i działy wydawnictw korporacyjnych codziennie produkują nowy materiał graficzny. Wymagania: szybkie wyszukiwanie, zarządzanie prawami (wygasanie licencji, prawa użytkowania per kanał), automatyczna konwersja formatów i dziedziczenie metadanych. Rozszerzone FAL z polami niestandardowymi pokrywa podstawowe funkcje. Dla zarządzania prawami i sterowania przepływem pracy potrzebny jest zewnętrzny DAM.

Uczelnie wyższe i instytucje badawcze. Uniwersytety zarządzają zdjęciami kampusu, fotografiami z wydarzeń, grafikami badawczymi i portretami pracowników. Wyzwanie: zdecentralizowane dostarczanie z 30+ wydziałów do jednego centralnego systemu. TYPO3 FAL ze strukturą folderów opartą na kategoriach i prawami dostępu per grupa użytkowników rozwiązuje to. Zewnętrzne systemy DAM są tutaj rzadko ekonomicznie uzasadnione.

Architektura techniczna

FAL TYPO3 składa się z trzech warstw: sterownika Storage (lokalny system plików, S3, Azure), indeksu plików (tabela bazy danych sys_file z metadanymi) i systemu referencji plików (powiązanie między plikami a elementami treści). Baza obrazów w TYPO3 rozszerza głównie środkową warstwę - indeks plików.

Najprostsza rozbudowa: pola niestandardowe w tabeli sys_file_metadata. TYPO3 standardowo oferuje pola takie jak title, description, alternative i copyright. Przez TCA można dodać dowolne kolejne pola: photographer, license_type, expiry_date, usage_rights, location, keywords_auto. Te pola pojawiają się w dialogu metadanych pliku w backendzie.

Dla wyszukiwania TYPO3 oferuje standardowo tylko wyszukiwanie po nazwie pliku w module File List. Prawdziwe wyszukiwanie pełnotekstowe po wszystkich metadanych wymaga integracji Solr (przez EXT:solrfal) lub niestandardowego modułu backendowego z połączeniem Elasticsearch. Solr przeszukuje wtedy nie tylko nazwy plików, ale wszystkie pola metadanych, włącznie z automatycznie generowanymi tagami.

Auto-tagowanie przez AI działa przez zadanie Schedulera, które wysyła nowe pliki do serwisu rozpoznawania obrazów (Google Cloud Vision, AWS Rekognition lub model hostowany na własnym serwerze) i zapisuje rozpoznane tagi w polach metadanych. Proces jest asynchroniczny i nie obciąża backendu. Przy pierwszym imporcie dużych zasobów należy liczyć z około 1 sekundą per obraz na analizę API.

Częste problemy i rozwiązania

Indeks FAL i system plików rozchodzą się. Gdy pliki są przesyłane przez FTP lub ręcznie usuwane, indeks FAL nie zgadza się z systemem plików. TYPO3 wyświetla pliki, które nie istnieją, lub nie zna istniejących plików. Rozwiązanie: regularne uruchamianie indeksera FAL przez Scheduler (zalecenie: codziennie w nocy). Indekser synchronizuje system plików z bazą danych. Przy 50 000 plików synchronizacja trwa około 10-15 minut.

Metadane giną przy aktualizacjach TYPO3. Pola niestandardowe w sys_file_metadata przeżywają aktualizacje TYPO3, gdy są zdefiniowane przez własne rozszerzenie. Jeśli są zdefiniowane bezpośrednio w pliku TCA-Override sitepackage, mogą zostać utracone przy zmianach strukturalnych tabeli metadanych. Rozwiązanie: pola bazy obrazów zawsze kapsułkować we własnym małym rozszerzeniu, nie w sitepackage.

Wydajność backendu przy dużych drzewach plików. Moduł File List staje się powolny od 1000 plików per folder, ponieważ generuje miniatury dla każdego obrazu. Rozwiązanie: struktura folderów z maksymalnie 500 plikami per katalog i przełączenie generowania miniatur w File List na “on demand”.

Migracja i kompatybilność wersji

FAL TYPO3 jest częścią rdzenia od wersji 6.0 (2012) i jest rozwijany z każdą wersją major. API FAL jest stabilne - pola niestandardowe i indeksery działają od TYPO3 v10 do v13 bez modyfikacji. Rozszerzenie Solr-FAL (EXT:solrfal) obsługuje TYPO3 v12, dla v13 zapowiedziano kompatybilność.

Kto migruje z zewnętrznego systemu DAM na TYPO3 FAL, musi zmapować metadane. Każdy system DAM ma własny model danych. Sama migracja to zadanie bazodanowe: eksport z DAM jako CSV/JSON, mapowanie pól na sys_file_metadata, import przez TYPO3 DataHandler lub bezpośredni SQL.

Decyzja “rozbudowa FAL vs. zewnętrzny DAM” zależy od dwóch czynników: wielkości zasobów i złożoności przepływów pracy. Do około 10 000 zasobów i bez przepływów zatwierdzania wystarczy rozszerzone FAL. Powyżej tego lub przy wymaganiach takich jak automatyczne zarządzanie licencjami i dystrybucja wielokanałowa opłaca się wyspecjalizowany DAM z konektorem TYPO3. Gosign doradza w obu wariantach i implementuje zarówno rozszerzenia FAL, jak i integracje DAM.