Przeprowadzamy WordPressa

Od razu ostrzegam: nie jest łatwo. Nie jest łatwo, jeżeli założyłeś bloga w oparciu o wersję silnika starszą niż 2.2. Problem polega na tym, że w poprzednich odsłonach WordPress zakładał swoje tabele w oparciu o kodowanie zapożyczane wprost z bazy danych. MySQL używa standardowo kodowania latin1, dlatego też większość baz wordpressowych wygląda tak: kodowanie tabeli – latin1 (w polskich bazach – latin2), tekst w polach – niby UTF-8. „Niby”, bo aplikacja koduje to sobie przy użyciu funkcji utf_encode() i utf_decode(), co dodatkowo pogarsza sprawę, bo „zamyka” UTF8 wewnątrz ISO8859-1. Przy próbie zgrania tego via phpMyAdmin dostajemy sieczkę zamiast polskich znaków.

Różni ludzie różne na tą przypadłość proponowali rady. Temat jest znany od dawna, można go podobno łatwo rozwiązać, za pomocą skryptu PHP lub nawet wtyczki typu „fire-and-forget”. Piszę „podobno”, bo u mnie to nie zadziałało.

Jest jednak łatwy sposób na obejście problemu. Sposób jest łatwy, pod jednym warunkiem: wasz provider musi sporządzać automatyczne kopie bezpieczeństwa bazy danych (opróczy tych „na żądanie”).

Taka funkcjonalność jest dostępna użytkownikom systemu cPanelX, chyba najpopularniejszego wśród firm hostingowych. Różnica między kopią robioną „od ręki” (dzięki phpMyAdmin) a tą automatyczną, dzienną, jest taka, że ta druga korzysta z programu mysqldump a nie z PHP. Nie wiem szczerze powiedziawszy, czy tak się po prostu złożyło że „mój” (livenetowy) mysqldump był uruchamiany z opcją –default-character-set utf8, czy też jest na tyle sprytny, że potrafi rozpoznać UTF-8 „zawinięte” w ISO8859-1, ale sprezentował mi to, o co od początku chodziło – wynikowy plik SQL z poprawnym kodowaniem wewnątrz.

Skąd go zatem wziąć? Po zalogowaniu do panelu zaglądamy do opcji „Kopie zapasowe” i klikając na odpowiednią bazę pobieramy spakowany gzipem plik. Na docelowym serwerze na czysto instalujemy WordPressa (ważne, dzięki temu będziemy mieli od razu tabele z kodowaniem UTF-8) po czym kopiujemy wtyczki, tematy i co tam jeszcze mamy na starej lokacji.

Czas przenieść bazę, ale nie tak od razu. Musimy zrobić przynajmniej dwie rzeczy – zaktualizować wszystkie odnośniki oraz odpowiednie opcje „zaszyte” wewnątrz a także zmienić kodowanie tabel na utf8. Użytkownicy Linuksa powinni to zadanie polecić sed-owi (na marginesie: podczas przenosin miałem okazję przysiąść do tego edytora i powiem jedno – potęga!). Ja to zrobiłem tak:


sed -e 's/http:\/\/byte.livenet.pl/http:\/\/bytowisko.pl/g' foo.sql > foofoo.sql
sed -e 's/DEFAULT CHARSET=latin2/DEFAULT CHARSET=utf8/g' foofoo.sql > foofoofoo.sql

Przy takich okazjach procentuje nawyk używania względnych ścieżek przy wstawianiu grafiki. Ja się klepnąłem w czoło gdzieś po roku prowadzenia blogusia, więc musiałem dodatkowo rzucić zaklęciem:

sed -e 's/img src=\"http:\/\/byte.livenet.pl\/grafika/img src=\"grafika/g' foofoofoo.sql > final.sql

Nie polecam otwierania pliku w zwykłym edytorze, chyba że jest (ten plik, nie edytor) naprawdę niewielki. Dump generuje zrzut o bardzo, naprawdę bardzo długich liniach, co z miejsca mordowało każdy program, który próbował to odczytać. sed prześlizgnął się po moich sześciu megabajtach w dwie, może trzy sekundy. Szczęka mi opadła i została w tym położeniu czas jakiś.

OK, skoro mamy już odpowiednio spreparowany plik SQL, to czas nakarmić nim nową bazę. Najpierw proponuję spakować go gzipem, bo mało kto zapewne ma synchronicznego DSL-a pod ręką. Takim archiwum częstujemy phpMyAdmin-a albo, jeżeli mamy zdalną konsolę, wykonujemy:

mysql -u uzyszkodnik -p nazwa_bazy < final.sql

Koniec manewrów. Można się logować na nowy adres i wszystko jest tak, jak na adresie starym. Przynajmniej powinny być, o ile pamiętaliśmy o przekopiwaniu wszystkich plików. Baza w każdym razie jest idealną kopią oryginału, w dodatku od tej pory całkowicie przenośną, bo opartą w pełni na UTF-8.

Mam nadzieję, że pomogłem.

przemyślenia? | URI śladu