filefill dla TYPO3

filefill oszczędza deweloperom i agencjom dni nakładu synchronizacji, rozszerzenie automatycznie pobiera brakujące pliki z fileadmin z serwera produkcyjnego, gdy są rzeczywiście potrzebne

Kto pracuje przy istniejącym projekcie TYPO3, zna rytuał: lokalna konfiguracja stoi, dump bazy danych jest wczytany, ale na co drugiej stronie pojawiają się placeholdery zamiast obrazów. Powód jest banalny: katalog fileadmin systemu live zawiera gigabajty zasobów, których brakuje lokalnie. Klasycznym rozwiązaniem był rsync lub scp przez godziny. filefill wycina ten krok całkowicie. Zamiast kopiować wszystkie pliki wcześniej, rozszerzenie przy pierwszym dostępie pobiera dokładnie potrzebny plik z skonfigurowanego zdalnego serwera, on demand, transparentnie, z cache. Dla agencji, które stale pracują przy kilku projektach, oszczędza to nie tylko pamięć, ale też godziny per setup.

Zysk produktywności jest większy, niż wygląda na pierwszy rzut oka. Nowy deweloper nie jest gotowy do pracy dopiero po godzinie czekania na download, tylko po kilku minutach. Code review na zapomnianym feature-branch nie potrzebuje aktualnej synchronizacji plików. Krótkie odtworzenie raportu błędu nie ciągnie się przez pół dnia. Małe rozszerzenie adresuje tym samym prawdziwe wąskie gardło w codziennej pracy deweloperskiej.

Typowe scenariusze zastosowania

Najczęstszym przypadkiem jest lokalna konfiguracja deweloperska. Deweloper klonuje projekt TYPO3, konfiguruje DDEV lub Docker i wczytuje aktualny dump bazy danych. Zamiast dodatkowo pobierać 30 GB danych fileadmin, konfiguruje filefill z URL bazy systemu live. Przy każdym wywołaniu strony, które żąda obrazu lub dokumentu, rozszerzenie sprawdza, czy plik istnieje lokalnie, i pobiera go w razie potrzeby. Po kilku dniach pracy lokalnie są tylko rzeczywiście potrzebne pliki, reszta pozostaje na serwerze.

Drugim przypadkiem są środowiska staging. Agencja pielęgnuje dla każdego projektu system staging, na którym redaktorzy testują treści przed go-live. Te systemy staging nie muszą mieć wszystkich obrazów, tylko te z aktualnych wydań. filefill dba o to, żeby starsze treści mimo to działały, bo pliki są w razie potrzeby ściągane z systemu live.

Trzecie zastosowanie: scenariusze disaster recovery i hotfix. Gdy system TYPO3 musi być szybko uruchomiony na nowej maszynie (na przykład po awarii serwera lub przy pilnej migracji środowiska), filefill może w pierwszych godzinach pomostować pozyskiwanie zasobów, aż pełny restore backup jest zakończony.

Architektura techniczna

filefill wpina się w system FAL TYPO3, dokładniej w mechanizm Resource-Retrieval. Gdy tylko TYPO3 żąda pliku z lokalnego storage i stwierdza, że nie istnieje, działa event-listener filefill. Rozszerzenie sprawdza listę skonfigurowanych “sources” w kolejności ich priorytetów i próbuje pobrać plik stamtąd. Pomyślnie załadowane pliki są zapisywane lokalnie, dzięki czemu następny dostęp obywa się bez zdalnego requestu.

Konfiguracja odbywa się przez ustawienia rozszerzenia w Install-Tool. Zazwyczaj dodawane jest zdalne źródło z bazowym URL, opcjonalnie z credentials HTTP-Basic-Auth. Dla konfiguracji z CDN lub S3 ta ścieżka może również służyć jako źródło. Rozszerzenie wspiera kilka sources, co jest pomocne dla bardziej złożonych scenariuszy z oddzielnymi serwerami zasobów.

Ważne, że filefill działa tylko pasywnie. Rozszerzenie nie ładuje nic wcześniej, lecz reaguje wyłącznie na konkretne żądania plików. To czyni go oszczędnym w zużyciu zasobów i niepozornym w działaniu. Integracja z DDEV, Docker Compose lub Lando jest trywialna, bo rozszerzenie nie potrzebuje dodatkowych usług.

Częste problemy i rozwiązania

Pierwszym problemem są ograniczenia dostępu. Gdy serwer live dostarcza obrazy tylko dla zalogowanych użytkowników lub chroni określone ścieżki przez htaccess, filefill nie może ich łatwo pobierać. Rozwiązanie leży w prawidłowej konfiguracji uwierzytelniania HTTP i ewentualnie w regule whitelist na serwerze live, która daje środowisku deweloperskiemu dostęp do ścieżki fileadmin.

Drugi problem: przypadkowe użycie w produkcji. Gdy filefill jest aktywne w środowisku live, a zdalne źródło jest tym samym środowiskiem, powstaje niebezpieczna rekursja. Rozszerzenie nigdy nie powinno działać w produkcji. Pragmatyczne rozwiązanie to prowadzenie filefill tylko w bloku composer “require-dev” i aktywowanie przez zmienne środowiskowe, nie przez Install-Tool.

Trzeci problem: niespójne stany plików. Gdy system live wymienia plik, ale lokalna kopia jest już cache’owana, deweloper widzi starą wersję. Rozwiązaniem jest okazjonalne czyszczenie lokalnego fileadmin lub cache-busting przez zdalne źródło. Dla codziennej pracy to rzadko problem, bo nazwy plików przy wymianie zazwyczaj są nowe.

Migracja i kompatybilność wersji

filefill jest kompatybilne z TYPO3 v11, v12 i v13 i jest aktywnie rozwijane. Przy upgrade wersja rozszerzenia powinna pasować do wersji TYPO3, bo system zdarzeń FAL doświadczył mniejszych zmian między v11 a v12. Kto używa rozszerzenia w istniejących procesach deweloperskich, musi przy większych upgrade krótko przetestować, czy wszystkie sources są nadal poprawnie osiągalne.

Pokrewnym rozwiązaniem jest EXT:aus_driver_amazon_s3, które trzyma fileadmin bezpośrednio w bucket S3. Różnica: aus_driver_amazon_s3 to rozwiązanie produkcyjne, filefill to pomoc deweloperska. Oba się uzupełniają, projekt ze storage S3 w produkcji może lokalnie używać filefill, żeby pobierać z bucket tylko aktualnie edytowane pliki.

Dla agencji, które używają filefill standardowo, opłaca się dokumentacja w wiki projektu, która wyjaśnia, jak rozszerzenie jest aktywowane, jakie credentials są potrzebne i jak postępować przy problemach. To redukuje nakład wsparcia w zespole i czyni onboarding nowych deweloperów niezawodnym. Uzupełniająco opłaca się krótki skrypt, który przy konfiguracji nowego środowiska lokalnego automatycznie wpisuje prawidłową konfigurację.

Gosign instaluje i konfiguruje filefill w środowiskach deweloperskich i integruje rozszerzenie w setupy DDEV i Docker, dzięki czemu nowi członkowie projektu są gotowi do pracy w ciągu kilku minut.