Migracja i multisite: Zaawansowane zarządzanie WordPressem

Dwa zagadnienia w ekosystemie WordPressa budzą szczególny respekt wśród administratorów i deweloperów: bezbłędna migracja rozbudowanego serwisu produkcyjnego na nową infrastrukturę oraz uruchomienie i utrzymanie sieci witryn (WordPress Multisite).

Oba procesy, wykonane po amatorsku, potrafią sparaliżować działanie firmy: zepsute zserializowane tablice w bazie danych prowadzą do utraty konfiguracji wtyczek, a błędnie zaplanowana sieć Multisite staje się architektoniczną pułapką, w której błąd w jednym module kładzie setki stron naraz.

W tym technicznym przewodniku omawiamy inżynieryjne podejście do migracji bez przestojów oraz zasady projektowania skalowalnych sieci WordPress Multisite.

Więcej o tym, jak dbamy o infrastrukturę i stabilność serwisów, przeczytasz w naszej ofercie na utrzymanie i rozwój WordPressa.

#1. Anatomia profesjonalnej migracji WordPressa

Typowy błąd początkujących to próba pobierania setek tysięcy plików przez klasyczny protokół FTP i edycja 2-gigabajtowego pliku .sql w edytorze tekstu. W profesjonalnym środowisku operujemy wyłącznie na protokole SSH oraz dedykowanych narzędziach wiersza poleceń.

#Krok 1: Bezpieczna synchronizacja plików przez rsync

Zamiast pobierać archiwum zip przez panel hostingowy, synchronizujemy drzewo katalogów bezpośrednio między serwerami za pomocą narzędzia rsync. Pozwala to na wznawianie transferu i wykluczenie zbędnych plików tymczasowych:

# Uruchomienie synchronizacji z wykluczeniem cache i zbędnych logów
rsync -avzP --delete \
  --exclude 'wp-content/cache/*' \
  --exclude 'wp-content/uploads/cache/*' \
  --exclude '*.log' \
  [email protected]:/var/www/html/ /var/www/html/

Flaga -a zachowuje uprawnienia i czasy modyfikacji plików, a -z kompresuje dane w locie, drastycznie skracając czas transferu przez łącze sieciowe.

#Krok 2: Eksport bazy danych i problem danych serializowanych

WordPress przechowuje wiele złożonych konfiguracji (np. ustawienia ACF, opcje motywów potomnych, struktury menu) w postaci tablic zserializowanych przez funkcję serialize() w PHP. Przykład zapisu w tabeli wp_options:

a:2:{s:4:"host";s:14:"stary-serwer.pl";s:4:"port";i:3306;}

Zwróć uwagę na ciąg s:14:"stary-serwer.pl". Liczba 14 oznacza dokładną długość ciągu znaków. Jeżeli zmienisz domenę ręcznie za pomocą funkcji Znajdź i zamień w edytorze tekstu na nowy-host.pl (długość: 12), parser PHP podczas odczytu natrafi na niezgodność długości i odrzuci całą tablicę. Efekt: zresetowane opcje wtyczek, znikające widżety i błędy typu Notice: unserialize(): Error at offset.

#Krok 3: Poprawna zamiana URL-i za pomocą WP-CLI

Jedyną w pełni bezpieczną metodą zmiany adresów URL w bazie danych jest użycie polecenia wp search-replace z poziomu konsoli serwera. WP-CLI deserializuje każdy obiekt w pamięci, dokonuje zamiany ciągu tekstowego, przelicza na nowo wskaźniki długości i ponownie serializuje dane przed zapisem do bazy:

# 1. Test na sucho (Dry-Run) bez modyfikowania bazy
wp search-replace 'https://stary-serwer.pl' 'https://nowy-serwer.pl' --dry-run

# 2. Wykonanie faktycznej zamiany we wszystkich tabelach
wp search-replace 'https://stary-serwer.pl' 'https://nowy-serwer.pl' \
  --all-tables \
  --precise \
  --recurse-objects

# 3. Wyczyszczenie pamięci podręcznej i przepisanie reguł .htaccess/Nginx
wp cache flush
wp rewrite flush --hard

#2. Strategia Zero-Downtime przy zmianie serwera

Aby klienci i roboty wyszukiwarek nie napotkali błędów podczas przenosin, stosuje się czterofazowy protokół migracyjny:

1. Obniżenie parametru TTL (Time to Live) w DNS: Na 48 godzin przed planowanym oknem serwisowym zmniejsz wartość TTL dla rekordu A domeny do 300 sekund (5 minut). Dzięki temu po zmianie adresu IP cały świat dowie się o nowym serwerze niemal natychmiast.
2. Synchronizacja wstępna: Prześlij 99% plików multimedialnych (wp-content/uploads/) z wyprzedzeniem.
3. Okno serwisowe:
   • Włącz tryb konserwacji na starym serwerze (wp maintenance-mode activate).
   • Wykonaj końcowy zrzut bazy danych (wp db export dump-final.sql).
   • Prześlij zrzut na nowy serwer i zaimportuj go (wp db import dump-final.sql).
   • Uruchom wp search-replace na nowej maszynie.
4. Przepięcie rekordu DNS: Zmień adres IP rekordu A na nowy serwer. Od tego momentu ruch zacznie płynnie spływać na nową instancję.

#3. WordPress Multisite: Kiedy warto, a kiedy to pułapka?

WordPress Multisite (dawniej WPMU) umożliwia uruchomienie setek lub tysięcy wirtualnych serwisów w oparciu o jedną instancję kodu i wspólną bazę danych.

#Jak Multisite organizuje bazę danych?

W instalacji pojedynczej WordPress tworzy standardowe 12 tabel (np. wp_posts, wp_options, wp_users). W trybie Multisite zachodzi kluczowa zmiana architektoniczna:

• Współdzielone tabele globalne: Tabela użytkowników (wp_users) oraz ich metadanych (wp_usermeta) pozostaje jedna dla całej sieci. Konto użytkownika istnieje raz, ale może mieć różne role w różnych witrynach sieci. Dochodzą też tabele zarządzania siecią (wp_blogs, wp_site, wp_sitemeta).
• Izolowane tabele per witryna: Każda kolejna strona w sieci otrzymuje własny prefiks numeryczny: witryna nr 2 otrzymuje tabele wp_2_posts, wp_2_options, wp_2_comments itd.

+--------------------------------------------------+
|          WordPress Multisite - Baza Danych       |
+--------------------------------------------------+
| Tabele globalne:                                 |
| - wp_users                                       |
| - wp_usermeta                                    |
| - wp_blogs                                       |
| - wp_site / wp_sitemeta                          |
+--------------------------------------------------+
| Witryna Główna (ID: 1):                          |
| - wp_posts, wp_options, wp_terms...              |
+--------------------------------------------------+
| Subwitryna (ID: 2):                              |
| - wp_2_posts, wp_2_options, wp_2_terms...        |
+--------------------------------------------------+
| Subwitryna (ID: 3):                              |
| - wp_3_posts, wp_3_options, wp_3_terms...        |
+--------------------------------------------------+

#Kiedy Multisite to idealny wybór?

1. Sieci franczyzowe i oddziałowe: Gdy 50 lokalnych oddziałów firmy korzysta z tego samego szablonu graficznego, tego samego zestawu wtyczek i centralnego brandingu, a różni się jedynie danymi teleadresowymi i lokalnym cennikiem.
2. Szkolnictwo i portale uczelniane: Gdzie każdy wydział lub koło naukowe potrzebuje własnej podstrony w ujednoliconej domenie uczelni.
3. Wielojęzyczność korporacyjna: Gdy rynki zagraniczne wymagają całkowitej separacji treści i struktury URL, ale utrzymanie 10 osobnych instalacji byłoby koszmarem administracyjnym.

#Kiedy Multisite jest błędem projektowym?

• Różni, niepowiązani klienci agencyjni: Jeden fatalny błąd PHP w motywie klienta A wyłącza serwisy klientów B, C i D. Ponadto wyodrębnienie jednej witryny z sieci Multisite do osobnej bazy danych jest czasochłonnym procesem.
• Skrajnie różne zestawy wtyczek: Jeśli strona A potrzebuje WooCommerce, strona B zaawansowanego LMS, a strona C forum dyskusyjnego bbPress, wspólna baza wtyczek staje się ociężałym monolitem trudnym do aktualizacji.

#4. Konfiguracja techniczna sieci Multisite

Włączenie sieci wymaga dopisania dyrektyw do pliku wp-config.php:

// 1. Odblokowanie kreatora sieci w kokpicie
define('WP_ALLOW_MULTISITE', true);

Po przejściu do Narzędzia > Uruchamianie sieci i wybraniu modelu (subdomeny czy podkatalogi), instalator generuje ostateczny zestaw stałych:

// 2. Aktywacja właściwej sieci (wariant subdomenowy)
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);
define('DOMAIN_CURRENT_SITE', 'twojadomena.pl');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

Od wersji WordPress 4.5 natywne mapowanie domen (Domain Mapping) jest wbudowane bezpośrednio w silnik. Wystarczy w edycji konkretnej witryny w panelu Super-Administratora wpisać docelową domenę (np. zewnetrzna-marka.pl), a serwer WWW (Nginx/Apache) skierować za pomocą certyfikatu SSL na ten sam katalog główny.

#Często zadawane pytania (FAQ)

Migracja bez przestojów oraz stabilna sieć Multisite to domena inżynierii, a nie improwizacji. Precyzyjne operowanie na bazach danych, automatyzacja zadań przez WP-CLI oraz właściwe planowanie architektury pozwalają skalować projekty cyfrowe bez obawy o utratę danych czy awarie produkcyjne. Jeżeli planujesz migrację złożonego serwisu lub potrzebujesz audytu swojej infrastruktury, skonsultuj się z naszym programistą WordPress.