in2publish dla TYPO3: Publikowanie treści między Staging i Live

Dlaczego in2publish definiuje workflow treści w projektach Enterprise TYPO3

W profesjonalnych instalacjach TYPO3 redaktorzy nie pracują bezpośrednio na systemie live. Pielęgnują treści na środowisku staging, uzgadniają zmiany wewnętrznie i publikują dopiero po zatwierdzeniu. Ale jak dane trafiają ze staging na live? Bez in2publish oznacza to: dump bazy danych na staging, wgranie na live, synchronizacja plików przez FTP. Proces podatny na błędy, trwający 30 do 60 minut, przy którym jedno złe kliknięcie może nadpisać całą bazę danych live.

in2publish od in2code eliminuje ten proces. Redaktorzy klikają w backendzie TYPO3 “Publish” i rozszerzenie synchronizuje dokładnie te zmienione rekordy i pliki na system live. Żadnych dostępów FTP, żadnych dumpów bazy danych, żadnego przestoju. Standard branżowy dla Content-Staging w TYPO3.

Typowe scenariusze zastosowań

Redakcyjny workflow zatwierdzania. Koncern prowadzi stronę korporacyjną na TYPO3 z 12 redaktorami w 3 działach. Każdy dział pielęgnuje swój obszar na staging. Kierownictwo zespołu sprawdza zmiany i zatwierdza je. Redaktor klika “Publish” i tylko jego zatwierdzone strony trafiają na live. Inne obszary strony pozostają nietknięte. in2publish wyświetla przy tym widok różnic: które pola się zmieniły, które obrazy są nowe, które rekordy zostaną nadpisane.

Publikowanie wielojęzyczne. Firma prowadzi swoją stronę w 5 językach. Polska redakcja publikuje gotowe teksty, podczas gdy tłumaczenie angielskie jest jeszcze w toku. in2publish umożliwia selektywne publikowanie per język: polska treść idzie na live, angielska pozostaje na staging, aż tłumaczenie jest zakończone.

Premiery kampanii z określonymi terminami. Zespół marketingowy przygotowuje stronę premiery produktu, która ma być opublikowana 15 października o 8:00. Wszystkie treści - teksty, obrazy, wideo, landing page - są przygotowywane i testowane na staging. W dniu premiery odpowiedzialny redaktor publikuje wszystko jednym krokiem. Przy problemach in2publish może cofnąć zmiany.

Architektura techniczna

in2publish pracuje na poziomie bazy danych i systemu plików. Rozszerzenie porównuje stan bazy danych staging z bazą danych live i przenosi różnice. Architektura składa się z czterech komponentów rdzeniowych: porównanie rekordów (identyfikacja zmienionych, nowych i usuniętych rekordów z rozwiązywaniem relacji), synchronizacja FAL (transfer obrazów i dokumentów przez SSH/SFTP z porównaniem hashów), warstwa transportowa (komunikacja przez SSH z uwierzytelnianiem kluczem publicznym) oraz konfiguracja (definicja YAML, które tabele są publikowane, a które wykluczone).

Zależności: TYPO3 Core, dostęp SSH między serwerem staging i live, rozszerzenie PHP-SSH2 lub binaria ssh2 na serwerze.

Częste problemy i rozwiązania

Publikowanie przerywa się z “SSH Connection Failed”. Najczęstsza przyczyna: klucz SSH serwera staging nie jest zdeponowany na serwerze live lub konfiguracja SSH w in2publish wskazuje na złego hosta/port. Rozwiązanie: ręczne przetestowanie połączenia SSH, potem sprawdzenie poświadczeń w konfiguracji in2publish.

Rekordy na live nie są aktualizowane. Tabela nie jest w białej liście konfiguracji in2publish. To zdarza się często przy niestandardowych tabelach z własnych rozszerzeń. Rozwiązanie: dodanie tabeli w konfiguracji i zdefiniowanie relacji.

Pliki FAL brakują po opublikowaniu na live. FAL-Storage na systemie live ma inną ścieżkę niż na staging lub uprawnienia na serwerze live nie pozwalają na zapis w folderze uploadu. Rozwiązanie: upewnienie się, że bazowa ścieżka FAL-Storage jest identyczna na obu systemach i użytkownik SSH ma uprawnienia do zapisu.

Migracja i kompatybilność wersji

in2publish jest aktywnie utrzymywane przez in2code i dostępne jako pakiet Composer dla TYPO3 v11 i v12 LTS. Wersja Enterprise oferuje dodatkowe funkcje (transport HTTP, rozszerzone logowanie, wsparcie Multi-Environment) i jest licencjonowana odpłatnie.

Przy aktualizacji TYPO3 konfiguracja in2publish musi być sprawdzona: nowe tabele systemowe, zmienione definicje TCA i nowe typy elementów treści wymagają dostosowania białej listy. Gosign zaleca po każdej aktualizacji Core testowe opublikowanie pojedynczej strony, by zwalidować konfigurację, zanim pełna operacja redakcyjna zostanie wznowiona. Test powinien obejmować stronę ze wszystkimi istotnymi typami treści: elementy tekstowe, obrazy, pliki do pobrania i co najmniej jedną relację.