Problem nie jest powszechny, jednak zdarzają się sytuacje, kiedy trzeba mocno się nagłowić, aby uruchomić „bezstratnie” swojego bloga opartego na silniku WP. Wyobraźcie sobie, że koniecznie musicie zmienić swój hosting. Cóż, z blogiem na pewno się nie pożegnacie, więc trzeba zaplanować całą operację.

Zapewne niektórzy w tym momencie pomyśleli: „co on plecie, przecież jest możliwość eksportu/importu z pliku?!”

Te osoby nigdy nie musiały przenieść żadnego bloga.

Eksport/import ma swoje minusy

Eksport to oczywiście funkcja bardzo przydatna, ale wyłącznie to prostego „backupowania” swojego bloga. Plik eksportu (.xml) plus archiwum katalogu uploads i mamy zabezpieczone dane.

Migrując system z jednego serwera na drugi można pokusić się o krok dalej. Nie potrzebujemy już archiwum uploads z pierwotnej lokalizacji, gdyż podczas importu wystarczy zaznaczyć, iż chcemy, aby załączniki zostały pobrane na lokalizacji docelowej. Sprawdzałem – działa, jednak nie mam pewności, że wszystkie zostały pobrane … jakoś tak zbyt krótko to trwało 🙂

Ok, mając zaimportowane dane w większości przypadków nie zauważymy od razu żadnych anomalii. W pierwszym przypadku z powodu tego, że serwer się nie zmienił, a w drugi z powodu tego że pierwotny serwer jeszcze działa.

Problematyczne, gdyż niezaktualizowane elementy to:

  • odnośniki w treści postów do treści wewnętrznych systemu
  • media w treści postów
  • menu (adresy url; ewentualnie media, gdy rozszerzono funkcję menu przez wtyczkę/i)
  • pozostałe metadane

WP Migrate DB

Czy możemy sobie poradzić z wykorzystaniem wtyczki? Tak. Problem migracji zapuścił już głębokie korzenie, niemal tak głębokie jak sam silnik WordPressa. Mamy do dyspozycji np. wtyczkę WP Migrate DB. Pod podanym adresem znajdziecie informację, co jest najważniejsze w całym tym problemie. Celem jest podmiana określonej części adresów URL na nowe (dostosowane do lokalizacji docelowej). Ta wtyczką świetnie sobie z tym radzi. Stosowałem, polecam, ale pewna sytuacja wymusiła na mnie zastosowanie alternatywnego sposobu.

Kiedy zaczynają się problemy

Ta problematyczna sytuacja to ogromna baza danych. Z czasem nasze dane puchną w zastraszającym tempie. Oczywiście w przypadku, gdy nasz system żyje, czyli występuje:

  • aktywność w zakresie komentarzy
  • aktywność w zakresie postów
  • aktywność w innym biznesowym zakresie, gdy wykorzystujemy WP, nie tylko jako bloga

Wówczas jest duże prawdopodobieństwo, że eksport pliku .xml poprzez moduł eksportu WP zwyczajnie się nie powiedzie. Wtedy koniecznie należy wykonać dump bazy danych i na nim oprzeć cały import w miejscu docelowym.

Gdy już mamy mirror bazy danych na serwerze docelowym wówczas należy zadbać o tę nieszczęsną podmianę adresów URL. W tym momencie doszliśmy do sedna całego artykułu.

UPDATE wp_options SET option_value = replace(option_value, 'http://oldurl', 'http://newurl') WHERE option_name = 'home' OR option_name = 'siteurl';

UPDATE wp_posts SET guid = replace(guid, 'http://oldurl','http://newurl');

UPDATE wp_posts SET post_content = replace(post_content, 'http://oldurl', 'http://newurl');

UPDATE wp_postmeta SET meta_value = replace(meta_value,'http://oldurl','http://newurl');

UPDATE wp_comments SET comment_author_url = replace(comment_author_url,'http://oldurl','http://newurl');

UPDATE wp_comments SET comment_content = replace(comment_content,'http://oldurl','http://newurl');

 

Podsumowanie

Na każdy problem jest jakieś rozwiązanie i trzeba sobie radzić możliwie jak najlepiej. Mam jednak wrażenie, że od twórców (współtwórców) WordPressa można wymagać aktualizacji adresów out-of-the-box. Skoro importując dane mamy pierwotną wartość home oraz siteurlwp_options to powyższe komendy aktualizujące odpowiednie elementy mogłyby już nie leżeć na barkach właścicieli blogów tudzież aplikacji opartych o silnik WP.