Optistream połączył dwanaście niestandardowych wtyczek WordPress w jedną bazę kodu, nie tracąc przy tym SEO dla żadnej ze swoich tysiąca publicznych stron.

Dlaczego to połączenie było istotne

Typowa strona WordPress kończy z garścią wtyczek; większa przypomina warsztat pełen kabli – każdy szumi, ale żaden nie jest łatwy do odłączenia. Strona Optistream korzystała z dwunastu dedykowanych wtyczek obsługujących profile streamerów, drużyny e-sportowe i dane gier. Wtyczki te generowały tysiąc indeksowalnych stron. Zachowanie tych adresów URL w nienaruszonym stanie było kwestią bezdyskusyjną – każda zmiana mogłaby pogrążyć migrację.

Jak wyglądała stara konfiguracja

Każda z dwunastu wtyczek znajdowała się we własnym folderze, rejestrowała własny typ posta (custom post type) i podpięła się pod WordPressa w różnych punktach. Problemy piętrzyły się:

  • Hooki i zasoby były rozproszone, co utrudniało przewidzenie, kiedy uruchamiany jest dany kod.
  • Logika routingu znajdowała się w wielu oddzielnych plikach, przez co jeden adres URL mógł być modyfikowany przez kilka wtyczek jednocześnie.
  • Pliki CSS ładowały się w nieprzewidywalnej kolejności, co prowadziło do konfliktów stylów.
  • Debugowanie wymagało otwierania dwunastu różnych katalogów, co było stratą czasu dla każdego programisty.

Celem nie było zmniejszenie liczby plików, lecz nadanie całemu systemowi jednego cyklu życia i jednego miejsca do zarządzania zależnościami.

Jak zaplanowano migrację

Zespół potraktował interfejs publiczny – adresy URL, szablony i metadane – jako kontrakt, którego nie można złamać. Każda zmiana na front-endzie oznaczałaby porażkę. Mając to na uwadze, przygotowali listę kontrolną, którą realizowano po każdym kroku.

1. Wypisanie publicznych kontraktów

Każda ścieżka URL została zapisana wraz z jej typem posta, slugiem do przepisywania (rewrite slug), plikiem szablonu oraz kluczami meta, na których polegała. Arkusz kalkulacyjny stał się zbiorem zasad: jeśli adres URL uległ zmianie po przeniesieniu modułu, migracja była cofana.

2. Stworzenie prostego ładowarki (loader)

Utworzono niewielki plik bootstrap. Każda dawna wtyczka rejestruje teraz pojedynczą „domenę treści” (content domain) poprzez przewidywalną nazwę funkcji. Loader nie robi nic skomplikowanego – wystarczy, aby załadować odpowiedni moduł do WordPressa w razie potrzeby. Prostota sprawia, że błędy są od razu widoczne.

3. Ochrona danych

Zmiana nazw kluczy meta zmieniłaby modyfikację kodu w migrację danych, co niosłoby ze sobą niepotrzebne ryzyko. Stare klucze pozostały nienaruszone; nowe funkcje pomocnicze (helper functions) je opakowują, utrzymując stabilność schematu bazy danych.

4. Rozwiązanie problemu własności CSS

Konflikty stylów rozwiązano za pomocą trzech środków:

  • Pliki CSS modułów są kolejkowane (enqueued) z wysokim priorytetem, aby ładowały się na końcu.
  • Wszystkie selektory są ograniczone (scoped) do unikalnej klasy opakowującej dla każdego modułu.
  • Podczas kolejkowania używa się filemtime(), aby wymusić odświeżenie pamięci podręcznej przeglądarki w przypadku zmiany arkusza stylów.

5. Zastosowanie bezpiecznej pętli

Migracja przebiegała moduł po module. Po przeniesieniu modułu zespół weryfikował rejestrację typu posta, routing oraz układ mobilny, zanim przeszedł do kolejnego. Oryginalne wtyczki pozostały zainstalowane, ale nieaktywne, co zapewniało możliwość natychmiastowego wycofania zmian.

Lista kontrolna wdrożenia produkcyjnego

Po każdej wymianie modułu zespół sprawdzał:

  • Każdy adres URL typu treści zwraca status HTTP 200.
  • Nagłówek canonical URL zgadza się z oryginalnym adresem URL.
  • Tytuły stron i opisy meta pozostają bez zmian.
  • Wszystkie obrazy ładują się bez błędnych linków.
  • Na ekranach mobilnych nie występuje przesunięcie poziome (horizontal overflow).
  • Konsola przeglądarki nie wykazuje żadnych błędów JavaScript ani CSS.

Dopiero po pomyślnym przejściu listy kontrolnej zespół trwale dezaktywował starą wtyczkę.

Co daje nowa wtyczka

Powstała pojedyncza wtyczka nie zmniejsza bazy kodu; ona po prostu czyni granice widocznymi. Wszystkie dwanaście obszarów funkcjonalnych współdzieli teraz jeden cykl życia, jeden zestaw hooków i jedno miejsce do zarządzania zależnościami. Nowa wtyczka nie sprawiła, że system stał się mniejszy. Sprawiła, że granice stały się widoczne. Okazało się to bardziej użyteczne niż posiadanie mniejszej liczby wtyczek.

Ryzyka i kontrargumenty

Przypadek Optistream pokazuje, że zdyscyplinowane podejście typu „contract-first” oraz etapowe wdrażanie pozwalają utrzymać ryzyko pod kontrolą.

Na co zwrócić uwagę w przyszłości

Jeśli rozważasz podobną konsolidację, zacznij od tych dwóch filarów:

  1. Stabilność adresów URL – zanim napiszesz choćby linię kodu, rozrysuj każdą publiczną ścieżkę.
  2. Stabilność danych – unikaj zmiany nazw pól w bazie danych, chyba że jesteś gotowy na pełną migrację.

Następnie zbuduj niewielki loader, zachowaj ograniczenie (scope) CSS i przenoś moduły jeden po drugim, stosując rygorystyczną listę kontrolną wdrożenia.