Jak zaimportować bibliotekę mediów w WordPressie?
Z tego tekstu dowiesz się jak w WordPressie zaimportować bibliotekę mediów z innej (lub tej samej) strony przy pomocy wbudowanego, bezpłatnego importera/eksportera do nowej bazy danych SQL. Poradnik przyda się administratorom portali, które:
- przenoszą się na inny hosting
- zmieniają domenę
- łączone są z kilku małych w jeden duży
- były celem ataków wirusowych lub włamań hakerskich i istnieje podejrzenie, że nadal w plikach/bazie „coś” siedzi
- robione są od nowa, na bazie starej strony, bez bezpośredniego skopiowania starej bazy danych SQL i starych plików WordPressa (np. gdy na serwerze i w bazie zalegają niepotrzebne oraz „martwe” pliki i wpisy, których chcemy się pozbyć celem wzrostu wydajności i zmniejszenia rozmiarów, np. pozostałości po odinstalowanych motywach czy wtyczkach)
- z jakichś innych powodów chcemy mieć w bibliotece wierne odwzorowanie mediów z innego WordPressa
Niniejszy poradnik jest uzupełnieniem TEGO tekstu o „fabrycznym resecie” strony internetowej (czyli 'backupie’ bez wykorzystania starej, zaśmieconej bazy danych SQL). Paradoksalnie najmniej roboty z biblioteką mediów jest wtedy, gdy zmieniamy domenę, a dwa razy więcej, gdy działamy na tej samej domenie (robimy nową wersję starej strony pod tym samym adresem).
Na początek trochę teorii. Gdy klikniemy w kokpicie pasek „Media”- wyświetlą nam się wszystkie pliki, które tam wgraliśmy przy pomocy WordPressa od początku istnienia danej strony (głównie grafiki, ale też filmy, dźwięki, pdf-y, arkusze i inne pliki). Gdy wgrywamy plik na serwer przy pomocy WordPressa- odbywa się jednocześnie kilka procesów. Przede wszystkim ten plik kopiowany jest w całości na serwer (zwyczajowo do folderu wp-content/uploads/ i tam segregowany do podfolderów pod względem wybranej metody, najczęściej daty). Ponadto w przypadku grafik WordPress automatycznie podczas uploadu tworzy z każdego wgrywanego pliku kilka miniatur (nowych, mniejszych plików) o różnych rozdzielczościach (najczęściej, w zależności od motywu od 4 do 8 miniatur na każdy plik graficzny, które w nazwie pliku mają dopisaną rozdzielczość), aby strona szybciej się wczytywała (zwłaszcza w galeriach z miniaturami oraz na niskich rozdzielnościach ekranu użytkownika, głównie na telefonach). Trzecią rzeczą (z powodu której prawdopodobnie tu trafiłeś) jest to, że po wgraniu grafiki przez WordPress pojawia się ona w jego bibliotece (Kokpit->Media) i wtedy ma swój unikalny alias (odnotowany w bazie SQL), wykorzystywany później np. przez niektóre pluginy galerii.
Jeżeli „chamsko” przegramy grafiki na serwer przez FTP to będą one normalnie dostępne przez URL, ale nie będzie ich widać w bibliotece mediów WordPressa. W większości przypadków nie jest to problem i strona będzie działać prawidłowo (nie licząc tego, że niekiedy użytkownikowi prezentowany będzie największy, „główny” plik, a nie miniatura, co wydłuży czas ładowania się strony), ale jeżeli ktoś chce np. edytować tagi, zrobić podpisy, albo galerię, to może potrzebować tejże biblioteki. Jest kilka metod jej wiernego przeniesienia, niestety większość powiązana jest z płatnymi wtyczkami (których darmowe wersje nie nadają się do niczego, może poza migracją bardzo małych stron). Problem zaczyna się, gdy mamy portal z tysiącami zdjęć, zajmujących ciężkie gigabajty, których obecności potrzebujemy w bibliotece nowego WordPressa.
Do procesu najbezpieczniej (i najtaniej, bo za darmo) wykorzystać certyfikowany przez społeczność WordPressa programik, a właściwie dwa- eksporter oraz importer. Ten pierwszy jest wbudowany w każdy WordPress (w kokpicie wybieramy Narzędzia->Eksport), a drugi musimy zainstalować na docelowej stronie (Narzędzia->Import), potem można go usunąć. Całość wyjaśniłem w TYM tekście. Problemy z mediami występują głównie w dwóch sytuacjach:
- Gdy mediów jest bardzo dużo i importer nie potrafi wszystkiego załadować za jednym razem
- Gdy „importujemy” bibliotekę do strony o tej samej domenie (czyli gdy założyliśmy nową stronę o tym samym adresie i chcemy w bibliotece mieć wszystkie media)
Problem 1: Dużo mediów
Eksporter de facto nie ma bezpośrednio nic wspólnego z plikami mediów, robi tylko ich unikalny spis, dlatego jest programem dużo prostszym i mniej zasobożernym, niż importer. Na ogół eksporter da radę zrobić cały backup treści i spisu mediów za jednym żądaniem, do jednego pliku xml (chyba, że witryna jest duża i całość zajmuje powyżej 64 MB, wtedy trzeba podzielić plik na więcej mniejszych plików).
Gorzej z importerem, który ma dużo więcej roboty, a jego zadania są bardzo zasobożerne, co przy dużych portalach w 99% przypadków kończy się na przerwaniu procesu importu przez systemy bezpieczeństwa hostingu. Jak pisałem wyżej- importer poza implementowaniem przygotowanego wcześniej pliku (lub plików) xml przeprowadza zasobożerny proces kopiowania wszystkich mediów na serwer. W przypadku obrazów- kopiowane są tylko te „główne”, natomiast wszystkie miniatury robione są od nowa, jako całkiem nowe pliki, później jeszcze importer implementuje je do karty z biblioteką mediów w kokpicie WordPressa i dodaje do każdego medium wzmiankę w bazie danych. Gdy zdjęć jest dużo- importer wykona tylko część zadań za jednym żądaniem (w zależności od hostingu i „wagi” zdjęć- od kilku do kilkuset sztuk na raz). Reszty nie zrobi i żeby było śmieszniej- nie poinformuje nas, czemu przestał. Co wtedy? Po prostu każemy mu robić to kolejny raz, a potem kolejny i tak do skutku. Jest to metoda stosunkowo głupia, ale skuteczna i bezpieczna. Co ważne (i zbawienne)- importer najpierw sprawdza, czy dany plik już nie figuruje w bibliotece i jeżeli tak jest, to go pominie (nie załaduje drugi raz i nie zdubluje, tylko przejdzie do kolejnego, aż nie dojdzie do takich, których jeszcze nie ma). Przy każdym kolejnym żądaniu musimy wysyłać plik xml od nowa, więc jeżeli jest on duży i długo to trwa, to lepiej na etapie eksportu zrobić tych plików więcej (można tam wybierać daty). Zamiast jednego pliku 50MB, który będziemy musieli ze 100 razy wysyłać- lepiej zrobić 25 plików po 2MB i każdy wysłać 4 razy, a zaoszczędzimy trochę czasu. Zatem z uporem maniaka, aż do skutku importujemy jeden i ten sam plik (albo wiele, każdy po kolei), aż importer uroczyście nie zakomunikuje, że przegrał już wszystko. Jak to się mówi- 'robota głupiego’, ale 'u mnie działa’. Możemy za każdą „rundą” sprawdzić w bibliotece ile mediów przybyło (jeżeli nie przybyło w ogóle, to problem jest innego rodzaju i wtedy najlepiej aktywować debugowanie w pliku wp-config, aby poznać więcej szczegółów).
Na koniec sprawdzamy w bibliotece mediów, czy jest ich tam tyle, ile powinno być (zwyczajowo tyle samo, co na „starej” stronie). Po wszystkim należy skasować wszystkie pliki xml, które wgrywaliśmy (powinny być na samej górze w bibliotece).
Jak pisałem wyżej- importer robi miniatury od nowa, więc jeżeli ktoś wcześniej kompresował grafiki (aby mniej zajmowały miejsca) to można rozważyć zrobienie tego jeszcze raz. Wprawdzie zdjęcie „główne” będzie skopiowane żywcem (a więc skompresowane), natomiast wszystkie miniatury (zwłaszcza ta największa) będą miały duże zdolności do bycia lżejszymi.
Problem 2: Domena źródłowa i docelowa są te same
Podczas wykonywania procesu importer musi mieć dostęp do plików mediów (zwyczajowo jest to folder wp-content/uploads/) strony internetowej, z której eksportowaliśmy plik xml. Jeżeli domeny są różne to nie ma problemu, bo dostęp do plików domeny źródłowej będzie cały czas. Gorzej, gdy domena jest ta sama, bo wtedy po „przełączeniu” w opcjach hostingu na katalog nowej strony- stara (wraz z zawartością) nie będzie dostępna z poziomu przeglądarki.
Pierwsza myśl to oczywiście 'chamskie’ skopiowanie całego folderu wp-content/uploads/ ze starej strony na nową i liczenie na to, że importer stwierdzi, iż skoro pliki mediów są na miejscu, to tylko pozostaje mu zrobić pozostałe czynności (wprowadzić je do biblioteki w kokpicie WordPressa i bazy danych). Niestety, jest to marzenie ściętej głowy, bo importer zachowa się zupełnie inaczej. Mianowicie- skopiuje on główny plik w to samo miejsce (zdubluje go, dodając do nazwy -1, czyli z pliku „zdjecie.jpg” zrobi sobie drugi, taki sam plik „zdjecie-1.jpg”), a potem z nowego zrobi nowe miniatury, oczywiście wszystkie stare zdjęcia i miniatury zostaną w najlepsze na serwerze. W efekcie będziemy mieli w folderze z mediami 2 razy tyle plików i jeden wielki bajzel. Ponadto w efekcie zmian nazwy pozmieniają nam się URLe wszystkich zdjęć, czyli zarżniemy sobie crawl budget i wywołamy inne reperkusje. Jeżeli skasujemy stare zdjęcia (co jest syzyfową pracą, bo pewnie są ich tysiące) to przestaną działać wszystkie do nich hotlinki. Jedyny plus jest taki, że strona będzie teoretycznie działać normalnie, ale ogólnie mocno odradzam tę, z pozoru oczywistą metodę.
Co należy zatem zrobić, aby robota była fachowa? Pewnie jest wiele różnych metod, ja opiszę tę 'najczystszą’, niewymagającą instalowania dodatkowych wtyczek. Po prostu należy użyć drugiej domeny, albo ewentualnie subdomeny i traktować ją jako jednorazowego pośrednika (wówczas odpinając domenę ze starej strony nie utracimy dostępu do plików mediów). Kolejność działania jest następująca:
- Robimy plik (lub więcej plików, jeżeli jest tego bardzo dużo) eksportu xml na starej (źródłowej) stronie
- Stawiamy nowego (tymczasowego) WordPressa na nowej (obojętnie jakiej) domenie, lub subdomenie (aczkolwiek lepiej na domenie, jeżeli nie mamy żadnej pod ręką to wiele firm oferuje domeny za złotówkę na pierwszy rok, a nam ona będzie potrzebna na 1 dzień). Ewentualnie można użyć wildcard
- Importujemy plik (lub pliki) xml do tymczasowej strony, importer utworzy też media w folderze 'uploads’ i wrzuci je do biblioteki (oczywiście nie ominie nas 'Problem 1′ opisany wyżej, czyli pewnie trzeba będzie to powtarzać wielokrotnie, bo hosting się zbuntuje/wysypie z nadmiaru roboty)
- Sprawdzamy, czy wszystko się zaimportowało (media i ich liczba, podpisy i metadane grafik, galerie, ewentualnie komentarze, wpisy, strony, tagi itp)
- Jeżeli wszystko jest OK, to robimy znowu to samo, co w punktach 1-4, czyli najpierw tworzymy nowy plik (pliki) xml w eksporterze tymczasowej strony
- Przekierowujemy główną domenę na nowy (ostateczny) folder i instalujemy tam WordPressa
- Importujemy plik (pliki) xml z tymczasowej strony
- Sprawdzamy, czy wszystko jest, jeżeli tak to:
- Kasujemy tymczasowego WordPressa i jego bazę danych
- Konfigurujemy ostatecznego WordPressa i kopiujemy 'niewordpressowe’ dodatki ze starej strony (favicony, .htaccess, robots.txt itd)
U mnie działa. Jeżeli ktoś ma problemy, to proszę opisać w komentarzu, a w miarę możliwości postaram się coś doradzić.
PS: Zdaję sobie sprawę, że pewnie da się to zrobić łatwiej i szybciej przy pomocy jakiejś wtyczki, ale są one po pierwsze płatne (darmowe wersje są tylko po to, żeby wymusić na użytkowniku płatny upgrade), a po drugie lubią coś „od siebie” dodać do bazy i zostawić to nawet po odinstalowaniu.