WordPress i baza MySQL: case study o przenoszeniu strony na inny serwer

Szacunkowy czas czytania: 4 minut

 

Chciałabym opisać Wam krótką historię drobnej porażki podczas przenosin pewnej strony opierającej się na WordPressie. Jest to strona, którą kiedyś zrobiłam dobremu znajomemu. Gdy okres promocyjny hostingu się skończył, a był to dość drogi hosting w USA, okazało się, że właściciel chce przenieść stronkę w jakieś tańsze miejsce.

Migracja strony na inny serwer

Spakowałam więc stronę wtyczką Akeeba, którą naprawdę bardzo polecam. Jest darmowa i radzi sobie z dużymi backupami oraz migracją stron. Ma także wersję Pro, dla bardziej wymagających.
Po spakowaniu strony przez Akeebę, backup ma rozszerzenie .jpa. Można go pobrać i odtworzyć w dowolnym miejscu, używając do tego darmowego programu rozpakowującego Kickstart (również od twórcy Akeeby). Korzystałam wiele razy, a i tym razem stronka się pięknie odtworzyła 1:1 bez żadnego problemu (oczywiście wcześniej skierowałam oryginalną domenę na nowy serwer, by strona działała pod tym samym URLem).

Problem zaczął się, gdy chciałam się zalogować jako administrator (i jedyny, dodany kiedykolwiek użytkownik). Okazało się, że wprawdzie mogę się zalogować podając e-mail i hasło, ale potem kompletnie nic się nie dzieje. Nie widać nawet bardzo okrojonej wersji WordPressowego kokpitu – jedynie górny pasek menu z możliwością wylogowania się. Domyśliłam się, że mój użytkownik stracił w trakcie migracji uprawnienia administratorskie.

Dodawanie użytkownika bezpośrednio w bazie danych

Nie wpadłam w panikę. Użytkownika z uprawnieniami admina można utworzyć z poziomu phpMyAdmin, bezpośrednio w bazie MySQL. Możemy to zrobić ręcznie lub przez zapytanie SQL.

Dodawanie użytkownika ręcznie:

Przechodzimy do naszej bazy danych, następnie do wp_users i dodajemy nowego użytkownika (klikając w Insert)

Pola, które wypełniamy:
ID – numer użytkownika (inny niż ID już istniejących)
user_login – nasz login
user_pass – nasze hasło, na dropdownie wybieramy MD5 (algorytm kryptograficzny)
user_nicename – zwykle jest to to samo co login, ale możecie wpisać cokolwiek
user_email – nasz adres e-mail
user_registered – data rejestracji, zwykle aktualny czas
user_status – 0
display_name – zwykle to samo co login, ale można wpisać własną nazwę, która będzie wyświetlana np. przy wpisach

Klikamy „Go” (prawy dolny róg).

Następnie przechodzimy do wp_usermeta i wypełniamy pola związane z uprawnieniami admina:

user_id – takie samo ID jak powyżej (w przykładzie = 5)
meta_key – wp_capabilities
meta_value – a:1:{s:13:”administrator”;s:1:”1″;}

Klikamy w „Go”.

Ostatni krok to dodanie do wp_usermeta kolejnych informacji (user level) – powtarzamy powyższy krok, ale z innymi danymi:

user_id – takie samo ID jak powyżej (w przykładzie = 5)
meta_key – wp_user_level
meta_value – 10

Klikamy w „Go”.

Dodawanie użytkownika przez SQL query:

Na zielono zaznaczyłam informacje, które musicie uzupełnić samodzielnie, zgodnie ze stanem faktycznym (nazwa bazy, wybrane dane użytkownika itd.)
Na czerwono zaznaczyłam prefiksy (nie zawsze muszą to być „wp_”). Więcej o prefiksach w ostatnim akapicie.

INSERT INTO `nazwa_bazy_danych`.`wp_users` (`ID`, `user_login`, `user_pass`, `user_nicename`, `user_email`, `user_registered`, `user_status`, `display_name`) VALUES (’5′, 'testowy’, MD5(’test123′), 'Testowy’, 'login@domena.com’, '2021-04-19 11:47:52′, '0′, ’Testowy’);

INSERT INTO `nazwa_bazy_danych`.`wp_usermeta` (`umeta_id`, `user_id`, `meta_key`, `meta_value`) VALUES (NULL, '5′, wp_capabilities’, 'a:1:{s:13:”administrator”;s:1:”1″;}’);

INSERT INTO `nazwa_bazy_danych`.`wp_usermeta` (`umeta_id`, `user_id`, `meta_key`, `meta_value`) VALUES (NULL, '5′, wp_user_level’, ’10’);

Każdorazowo po wpisaniu query, klikamy w „Go”.

Na jakie problemy możemy napotkać?

Powyższy przykład jest jak najbardziej prawidłowy, ale w moim przypadku nie zadziałał.

Dlaczego?

Ponieważ kilka lat temu tworząc stronę ustawiłam inny prefiks bazy danych niż domyślny. Można to zrobić w trakcie instalacji WordPressa. Domyślny to „wp_”, czyli mamy też „wp_users”, „wp_capabilities” itd. Zmiana domyślnego prefiksu to zabieg związany z bezpieczeństwem strony i jak najbardziej go rekomenduję. A przy okazji polecam pamiętać, że się to zrobiło 🙂

W moim przypadku problem pojawił się w trakcie przenoszenia spakowanej strony wtyczką Akeeba. Zapomniałam jaki nadałam prefiks w bazie i w trakcie procesu rozpakowywania strony (poprzez Kickstart), nadałam bazie jeszcze inny prefiks. W ten sposób utraciłam uprawnienia admina (nowe i stare prefiksy do siebie nie pasowały). Dodawanie nowego użytkownika też za wiele nie dało, ponieważ w wp_options (w moim przypadku aut_options – patrz screenshot) wciąż w jednym rekordzie w kolumnie option_name widniał stary prefiks! Dopiero ręczne namierzenie go i zmienienie na aktualny prefiks (aut_) rozwiązało problem 🙂