Przeniesienie strony WordPress (np. z dev.strona.pl na strona.pl) wydaje się proste: wystarczy uruchomić “Znajdź i Zamień” w bazie danych, prawda?

BŁĄD.

Jeśli spróbujesz wykonać surowe zapytanie SQL, takie jak: UPDATE wp_options SET option_value = replace(option_value, 'stara.pl', 'nowa.pl')

…to zepsujesz swoją stronę. Konkretnie: stracisz Widgety, Ustawienia Motywu i konfigurację wielu wtyczek.

Najczęstszy Błąd: Proste “Znajdź i Zamień”

Wielu programistów (a nawet niektóre firmy hostingowe) sugeruje użycie prostej funkcji SQL REPLACE() do aktualizacji adresów URL. To podejście wydaje się logiczne, ale jest fundamentalnie wadliwe w ekosystemie WordPress.

Pokusa:

-- To wygląda bezpiecznie, ale NIE JEST
UPDATE wp_options 
SET option_value = REPLACE(option_value, 'https://stara.pl', 'https://nowa.pl');

Co się stanie:

Część adresów URL zaktualizuje się poprawnie (np. w treści postów).
Serializowane dane zostaną uszkodzone.
Widgety znikną.
Opcje motywu wrócą do domyślnych.
Ustawienia wtyczek zostaną utracone.

Dlaczego to nie działa: WordPress nie przechowuje wszystkich danych jako zwykły tekst. Wiele z nich jest przechowywanych jako zserializowane dane PHP, co wymaga specjalnego traktowania.

Zrozumieć Serializację: Źródło Problemu

Czym jest Serializacja?

WordPress przechowuje złożone struktury danych (tablice, obiekty) w bazie danych jako Serializowane Ciągi Znaków (Strings). Serializacja zamienia struktury PHP w ciąg znaków, który można zapisać w kolumnie tekstowej bazy danych.

Przykład Zserializowanych Danych:

// Oryginalna tablica PHP
array(
    'home' => 'https://stara.pl',
    'siteurl' => 'https://stara.pl',
    'admin_email' => 'admin@stara.pl'
)

// Zserializowany ciąg (zapisany w bazie)
a:3:{s:4:"home";s:16:"https://stara.pl";s:7:"siteurl";s:16:"https://stara.pl";s:11:"admin_email";s:16:"admin@stara.pl";}

Analiza Ciągu Serializowanego

Rozszyfrujmy s:16:"https://stara.pl":

s = string (ciąg znaków)
16 = długość ciągu (liczba znaków)
"https://stara.pl" = wartość

Kluczowy element: Liczba 16 reprezentuje dokładną liczbę znaków w ciągu "https://stara.pl".

Co się dzieje przy prostym zamienianiu?

Oryginał:

s:16:"https://stara.pl"

Po prostej zamianie SQL (stara.pl -> nowa-domena.pl):

s:16:"https://nowa-domena.pl"

Problem:

Długość ciągu zmieniła się z 16 na 22 znaki.
Serializacja nadal mówi s:16 (oczekuje 16 znaków).
PHP próbuje odczytać 16 znaków: "https://nowa-domena"
Brakuje końcówki .pl
Cała tablica staje się niepoprawna (invalid).
PHP odrzuca dane, zwracając false.

Efekt: WordPress nie może odczytać ustawień, widgetów ani opcji, więc przywraca je do wartości domyślnych lub po prostu ich nie wyświetla.

Gdzie znajdują się zserializowane dane?

Typowe lokalizacje

1. Tabela wp_options:

Opcje siteurl i home (czasami, choć rzadko są tablicami, zazwyczaj stringami).
Dane Widgetów (sidebars_widgets).
Modyfikacje Motywów (theme_mods_*).
Opcje wtyczek (większość wtyczek trzyma tu swoje ustawienia).

2. Tabela wp_postmeta:

Własne pola (Custom Fields).
Dane ACF (Advanced Custom Fields).
Metadane załączników.

3. Tabela wp_usermeta:

Preferencje użytkowników.
Uprawnienia (Capabilities).

Rozwiązanie: Narzędzia obsługujące serializację

Musisz użyć narzędzia, które:

Odserylizuje dane (zamieni ciąg z powrotem na tablicę PHP).
Podmieni tekst wewnątrz struktury danych.
Przeliczy długość znaków.
Zserializuje dane ponownie.
Zaktualizuje bazę danych.

Metoda 1: WP-CLI (Rekomendowana)

Sposób Profesjonalny: Jeśli masz dostęp do SSH, WP-CLI (WordPress Command Line Interface) jest najlepszym, najszybszym i najbezpieczniejszym narzędziem do tego zadania.

Podstawowe użycie:

wp search-replace 'https://stara.pl' 'https://nowa.pl' --all-tables

Opcje Zaawansowane:

# Dry run (test "na sucho" - zobacz co się zmieni, bez wprowadzania zmian)
wp search-replace 'https://stara.pl' 'https://nowa.pl' --all-tables --dry-run

# Tylko konkretne tabele
wp search-replace 'https://stara.pl' 'https://nowa.pl' wp_posts wp_postmeta

# Eksport zmian do pliku SQL (zamiast zmiany w bazie)
wp search-replace 'https://stara.pl' 'https://nowa.pl' --all-tables --export=zmiany.sql

Dlaczego WP-CLI jest najlepsze:

✅ Obsługuje serializację bezbłędnie.
✅ Jest bardzo szybkie.
✅ Pozwala na podgląd (dry-run).
✅ Nie wymaga instalowania wtyczek.

Metoda 2: Wtyczka Better Search Replace

Dla użytkowników bez SSH: Jeśli nie czujesz się pewnie w terminalu, użyj wtyczki Better Search Replace od WP Engine.

Instrukcja:

Zainstaluj i aktywuj wtyczkę.
Wejdź w Narzędzia > Better Search Replace.
W pole “Search for” wpisz stary adres: https://stara.pl.
W pole “Replace with” wpisz nowy adres: https://nowa.pl.
Zaznacz wszystkie tabele (Ctrl+A / Cmd+A).
Ważne: Zaznacz “Run as dry run?” na początek.
Kliknij “Run Search/Replace”.
Sprawdź wyniki. Jeśli wyglądają OK, odznacz “Dry run” i uruchom ponownie.

Metoda 3: Skrypt Search-Replace-DB (Interconnect/IT)

Zewnętrzny skrypt PHP: To legendarne narzędzie, z którego korzystamy, gdy nie mamy ani dostępu do WP-Admina, ani do SSH, ale mamy FTP.

Użycie:

Pobierz skrypt ze strony Interconnect/IT.
Wrzuć folder ze skryptem do głównego katalogu strony przez FTP (zmień nazwę folderu na coś losowego dla bezpieczeństwa).
Wejdź na twojastrona.pl/losowy-folder/.
Wypełnij dane bazy danych (jeśli skrypt sam ich nie pobierze z wp-config.php).
Wykonaj zamianę.
KRYTYCZNE: Kliknij przycisk “Delete Me”, aby usunąć skrypt z serwera po zakończeniu.

Ostrzeżenie: Pozostawienie tego skryptu na serwerze to zaproszenie dla każdego do przejęcia twojej bazy danych.

Checklista Migracji

Przed Migracją

Backup: Zrób pełną kopię bazy danych. Zawsze.
```
wp db export backup.sql
```
Dokumentacja: Spisz stary i nowy adres URL. Zwróć uwagę na http vs https oraz www vs bez-www.

W Trakcie

WP-CLI:

wp search-replace 'stara.pl' 'nowa.pl' --all-tables --dry-run

wp-config.php: Zaktualizuj stałe:

define('WP_HOME','https://nowa.pl');
define('WP_SITEURL','https://nowa.pl');

Po Migracji

Wyczyść Cache: Wtyczki cache, cache serwera (Varnish/Nginx).
Zapisz Permalinki: Wejdź w Ustawienia > Bezpośrednie odnośniki i kliknij “Zapisz”, aby przegenerować plik .htaccess.
Sprawdź stronę: Przeklikaj menu, sprawdź obrazki i (co najważniejsze) widgety.

Podsumowanie

W 2026 roku, przy coraz bardziej skomplikowanych motywach i Page Builderach, poprawna obsługa serializacji danych to absolutna konieczność.

Nigdy nie rób zamiany “Find & Replace” w edytorze tekstowym na pliku .sql.
Nigdy nie używaj prostych zapytań SQL REPLACE.
Zawsze używaj WP-CLI lub dedykowanych narzędzi (Better Search Replace).

To różnica między profesjonalną migracją a “ratowaniem rozsypanej strony” w piątek wieczorem.

Jak zaktualizować adresy URL w bazie WordPress po przeniesieniu domeny?