FFH dla TYPO3

Branżowe rozszerzenia TYPO3 nie zawalają się na technice, ale na utrzymaniu

FFH reprezentuje kategorię rozszerzeń TYPO3 opracowanych dla konkretnego klienta lub konkretnej branży: specyficzne branżowo, funkcjonalne, ale nie powszechnie utrzymywane. W TER znajdują się setki takich rozszerzeń. Niektóre mają 5 pobrań rocznie, brak dokumentacji i ostatni commit sprzed 3 lat. To nie znaczy, że są złe. Znaczy, że potrzebują utrzymania, którego pierwotny developer już nie zapewnia.

Dla przedsiębiorstw zależnych od takich rozszerzeń powstaje praktyczne pytanie: dalej używać i samodzielnie utrzymywać, migrować na alternatywę, czy rozwijać od nowa. Wszystkie trzy drogi są możliwe. Decyzja zależy od złożoności rozszerzenia, dostępności alternatyw i presji wersjonowania TYPO3.

Typowe scenariusze zastosowania

Stowarzyszenia branżowe ze specjalnymi wymaganiami. Izby rzemieślnicze, związki sportowe i zakłady ubezpieczeń społecznych prowadzą witryny TYPO3 z funkcjami, których żaden standardowy plugin nie pokrywa: katalogi członków z promieniem wyszukiwania, zarządzanie wydarzeniami z punktami kwalifikacyjnymi, rejestry branżowe ze statusem certyfikacji. Dla tego istnieją niestandardowe rozszerzenia opracowane 5-8 lat temu i od tego czasu minimalnie aktualizowane. Funkcja działa, ale aktualizacje TYPO3 stają się ryzykiem.

Przedsiębiorstwa mediowe z przepływami redakcyjnymi. Stacje radiowe, wydawnictwa i domy mediowe używają TYPO3 z rozszerzeniami dla playlist, planowania programu, archiwów medialnych lub syndykacji treści. Te rozszerzenia często zostały opracowane wewnętrznie lub przez agencję, która już nie obsługuje projektu. Kod działa na TYPO3 v9, ale migracja na v12 nie udaje się z powodu przestarzałych API.

Instytucje publiczne z wymaganiami prawnymi. Szkoły, muzea i biblioteki używają rozszerzeń do zarządzania godzinami otwarcia, wyszukiwania w katalogach lub rezerwacji wydarzeń. Wymagania są specyficzne (np. integracja z oprogramowaniem bibliotecznym jak Koha lub Alma), rozszerzenie zostało zbudowane raz i od tego czasu nie aktualizowane.

Architektura techniczna

Branżowe rozszerzenia TYPO3 typowo podążają za wzorcem Extbase/Fluid: model domeny (klasy PHP), repozytorium (dostęp do bazy danych), kontroler (logika biznesowa) i szablony Fluid (prezentacja). Dane znajdują się we własnych tabelach bazy danych z prefiksem tx_extensionname_.

Najczęstsze wzorce architektoniczne: rozszerzenia oparte na pluginach z wyjściem frontendowym (prezentacja listowa, widok szczegółowy, filtrowanie), moduły backendowe do zarządzania danymi i zadania Schedulera do importu/eksportu. Wiele branżowych rozszerzeń integruje zewnętrzne systemy przez REST-API lub import CSV.

Jakość kodu różni się znacznie. Rozszerzenia od profesjonalnych agencji podążają za standardami kodowania TYPO3, korzystają z Dependency Injection i mają Unit Testy. Wewnętrznie opracowane rozszerzenia lub szybko zbudowane prace zlecone często mają hardkodowane konfiguracje, brak typowania i brak testów. Oba można utrzymywać, ale nakład pracy różni się o czynnik 3-5.

Typowy wzorzec analizy branżowych rozszerzeń: pomiar zakresu (linie kodu, liczba klas, liczba tabel bazy danych), sprawdzenie zależności (jakie API TYPO3 są używane, które są deprecated w v12/v13), ocena testowalności (czy istnieją Unit Testy, czy kod jest strukturalnie testowalny) i oszacowanie nakładu migracji.

Częste problemy i rozwiązania

Przestarzałe API blokują aktualizację TYPO3. Rozszerzenie używa $GLOBALS['TSFE'], GeneralUtility::_GP() lub ObjectManager::get() - API, które w TYPO3 v12 są deprecated lub usunięte. Rozwiązanie: systematyczne refaktoryzowanie. Każde deprecated API ma udokumentowany zamiennik w TYPO3 Changelog. Przy rozszerzeniu z 5000 liniami kodu nakład refaktoryzacji to 3-7 dni, w zależności od liczby deprecjacji.

Brak maintainera. Pierwotny developer opuścił firmę, agencja już nie istnieje, pakiet TER jest porzucony. Rozwiązanie: fork kodu na GitHubie, włączenie rozszerzenia do własnego repozytorium Composer i samodzielne utrzymywanie. Lub zlecenie zewnętrznemu dostawcy. Fork jest prawnie bezproblemowy, gdy rozszerzenie jest na licencji GPL (standard dla rozszerzeń TYPO3).

Brak dokumentacji. Ani komentarze inline, ani zewnętrzna dokumentacja. Nowi developerzy muszą czytać kod, żeby zrozumieć funkcjonalność. Rozwiązanie: przed refaktoryzacją sporządzenie dokumentacji technicznej. 2-4 godziny analizy wystarczą dla rozszerzenia z 3000-5000 liniami kodu, aby udokumentować architekturę, model danych i logikę biznesową.

Migracja i kompatybilność wersji

Branżowe rozszerzenia z natury rzeczy nie mają oficjalnego wsparcia v12/v13. Migracja musi być przeprowadzona indywidualnie. Nakład pracy zależy od trzech czynników:

Po pierwsze: jaka wersja TYPO3 jest punktem wyjścia? Z v9 na v12 to znacznie więcej pracy niż z v11 na v12, ponieważ v10 wprowadziło stos Middleware, a v11 zmieniło rejestrację modułów backendowych.

Po drugie: ile deprecated API jest używanych? Scanner rozszerzeń TYPO3 (w Install Tool) pokazuje to automatycznie. Rozszerzenie z 5 deprecjacjami wymaga jednego dnia, z 50 jednego tygodnia.

Po trzecie: jak dobrze ustrukturyzowany jest kod? Czysty kod Extbase można migrować mechanicznie. Kod proceduralny z bezpośrednimi zapytaniami do bazy danych wymaga przepisania.

Trzy opcje: portowanie (dostosowanie rozszerzenia do nowej wersji TYPO3, 3-10 dni), nowy rozwój (ta sama funkcja, czysta architektura, 2-4 tygodnie) lub znalezienie alternatywy (standardowe rozszerzenie pokrywające 80% funkcji plus niestandardowe dostosowanie). Gosign przeanalizował, sportował i rozwinął od nowa setki branżowych rozszerzeń TYPO3 i doradza w kwestii najbardziej ekonomicznej opcji.