Jeśli nasz dotychczasowy klient pocztowy obsługuje protokół IMAP, to jesteśmy praktycznie w domu, jeśli chodzi o przeniesienie naszej archiwalnej poczty. Pozwoli to szybko przeszukiwać zasoby archiwalne i zasili imperium Google nowymi danymi o naszej skromnej osobie. No ale to cena za „darmowe” konto pocztowe.

Operacja jest prosta. Rozpoczynamy ją od aktywacji protokołu IMAP w ustawieniach konta na Gmailu (zakładka Przekazywanie i POP/IMAP). Tutaj nie ma żadnych niespodzianek.

Teraz w programie pocztowym musimy zdefiniować nowe konto, które będzie odpowiadało naszemu kontu na Gmailu. Google dostarcza odpowiednich instrukcji konfiguracyjnych. Ja wytestowałem działanie w programach The Bat! i Mozilla Thunderbird. Po prawidłowym ustawieniu wszystkich parametrów w programie pocztowym powinna pojawić się struktura folderów odpowiadająca temu, co oferuje Gmail na starcie, plus foldery odpowiadające etykietom, gdyż Gmail nie uznaje sortowania poczty w folderach. Stworzenie nowego folderu w kliencie poczty w koncie Gmail automatycznie oznaczy stosowną etykietą wiadomości, które się w nim znajdą.

Teraz zaczyna się właściwa migracja, która polega na przeciąganiu i upuszczeniu zestawów wiadomości do stosownych folderów, lub też przenoszeniu folderów z całą zawartością. I cierpliwym czekaniu, aż nasz program pocztowy prześle te wiadomości, które przeniesiemy do folderów Gmaila. Czas tej operacji zależy jedynie od prędkości naszego łącza.

Bywa, że operacja nie jest bezbolesna – Thunderbird raportował mi rozmaite błędy, co skutkowało koniecznością wznawiania tego procesu. Udało mi się jednak cierpliwie przemigrować kilkanaście tysięcy wiadomości. Inną niemiłą niespodzianką jest błąd „Lockdown in sector 4″, który oznacza czasowe (doba) zablokowanie konta na Gmailu, a przynajmniej dostępu przez IMAP. Dzieje się tak, gdy w ciągu jednego dnia wyślemy poprzez IMAP ponad 2GB poczty. Trochę to głupie, bo przecież o to właśnie w tym chodzi, ale nikt nie powiedział, że Google jest bez wad. Najlepiej więc całą operację przeprowadzać etapami, aby zaoszczędzić sobie problemów. I to w zasadzie wszystko. Prawda, że proste?

Teraz opis całego procesu:

1. Eksport bazy z aktualnego hostingu. Nie należy używać do tego celu phpMyAdmina, przynajmniej u mnie nie przyniosło to zadowalającego rezultatu. Wyeksportowana baza miała zepsute kodowanie i w docelowym miejscu nic się nie dało z tym zrobić. Eksportujemy bazę używając funkcji Kopia Zapasowa naszego WordPressa lub poprzez phpMyAdmina. Zgrywamy sobie spakowaną bazę na dysk lokalny, czyli do domu.
2. Weryfikacja poprawności eksportu. Rozpakowujemy archiwum bazy i wczytujemy plik SQL do edytora, który daje sobie radę z kodowaniem UTF-8. Ja polecam rodzimy produkt – Fox Edit lub EmEditor Free. Jeśli wczytany plik przy ustawieniu kodowanie UTF-8 pokazuje wpisy z polskimi znaczkami poprawnie, jesteśmy w pół drogi do sukcesu.
3. Utworzenie nowej bazy w hostingu docelowym. Baza będzie pusta. Tworzymy też użytkownika z zestawem praw, który będzie miał dostęp do tej bazy.
4. Instalacja WordPressa. Uploadujemy pliki programu, ale nie uruchamiamy żadnych skryptów instalacyjnych. Odpowiednio modyfikujemy plik wp-config.php wprowadzając ustawienia dla nowej bazy i nowego użytkownika (albo zostawiamy stare, gdy się nie zmieniły). WordPress czeka sobie na wypełnienie bazy.
5. Import zawartości starej bazy. Na nowym hoście importujemy bazę, tym razem przez phpMyAdmin, bo pewnie nie będzie innej możliwości. Wybieramy naszą nową bazę i opcję Import, podajęc następnie lokalizację pliku z kopią zapasową starej bazy na naszym lokalnym dysku.
6. Uruchamiamy WordPressa i patrzymy na rezultat. Najprawdopodobniej zobaczymy sporo znaków zapytania w miejscu polskich literek. Oznacza to, że czeka nas dalszy ciąg hackowania. W tym celu otwieramy w edytorze plik wp-db.php znajdujący się w folderze wp-includes. W nim, w wierszu 43 dodajemy następujący zapis:
   
mysql_query("SET NAMES 'utf8'");

   Po tej edycji wiersze w okolicy wiersza 43 wyglądają następująco:
   
function wpdb($dbuser, $dbpassword, $dbname, $dbhost) {
$this->dbh = @mysql_connect($dbhost, $dbuser, $dbpassword);
mysql_query("SET NAMES 'utf8'");
if (!$this->dbh) {
$this->bail("

   Wysyłamy zmieniony plik na serwer, oczywiście do katalogu wp-includes i odświeżamy strony naszego WordPressa. Znaczki zapytania w cudowny sposób zmieniają się w polskie znaki i wszystko wygląda cudnie.

Ponieważ zmieniłem hosta, ale nie zmieniłem adresu bloga, nie musiałem nic modyfikować w tabelach bazy, aby WordPress uwzględniał nowy adres. Niemniej jednak, jest to operacja, którą można wykonać edytorem Fox-Edit na wyeksportowanej bazie, albo poprzez phpMyAdmina, po zaimportowaniu jej do nowego hosta.

Uaktualnienie: powtórzyłem proces przenosin, tym razem dokonując eksportu poprzez phpMyAdmina. Wszystko udało się znakomicie, z czego wnioskuję, że jeśli plik wyeksportowany SQL dobrze wygląda w np. edytorze EmEditor, czyli mam poprawnie zakodowane polskie znaki, to wszystko będzie w porządku.