Áttelepítési hibák és megoldásuk

Ha az áttelepítés nem sikerül

Mielőtt újra próbálkozol, nézd végig az előzetes ellenőrzőlistát:

• A biztonsági és gyorsítótárazó bővítmények ki vannak kapcsolva.
• A közted és a webhely közötti proxyk (például a Cloudflare) ki vannak kapcsolva.
• Az UpdraftPlus a forrás- és a célwebhelyen is telepítve van.

Ha a kulcsos (webhelyek közötti) küldés nem megy, és sürgős a költözés, használd a kézi módszert:

1. A forráson nyisd meg az UpdraftPlus → Biztonsági mentés / visszaállítás → Meglévő biztonsági mentések részt, és töltsd le a kívánt mentést.
2. A célon ugyanitt kattints a Biztonsági mentési fájlok feltöltése hivatkozásra, és töltsd fel a fájlokat.
3. Kattints A helyi mappa újbóli átvizsgálása új mentéskészletek kereséséhez hivatkozásra, majd a mentés melletti Visszaállítás gombra.

Fizetős kiadás, de nincs áttelepítési lehetőség

Ha megvan a fizetős kiadás, de nem látod az áttelepítési lehetőségeket, nézd meg a Prémium / kiegészítők fület a forráson és a célon is. Ott a TeamUpdraft-fiókodnak kapcsolva kell lennie. Ha kapcsolva van, a „You are presently connected…” üzenetet látod. Ha nem, jelentkezz be a vásárláskor használt felhasználónévvel és jelszóval.

„Existing unremoved folders from a previous restore exist”

Visszaállítás után az UpdraftPlus megtartja a régi fájlokat, hogy ellenőrizhesd az eredményt. Új visszaállítás előtt ezeket törölni kell, különben ezt a hibát kapod. Kattints a Régi mappák törlése gombra a Biztonsági mentés / visszaállítás fülön.

„You have no local backups to send”

Az áttelepítés a helyi wp-content/updraft mappán keresztül mozgatja a mentést a két oldal között. Ha a jelenlegi oldalt telepíted át, az UpdraftPlus magától készít helyi mentést küldés előtt. Ha olyan meglévő mentést akarsz átvinni, amely nincs helyben:

1. Töltsd le a mentést a távoli tárhelyről (például Dropboxból vagy Google Drive-ról).
2. Töltsd fel a célra. Vagy SFTP-vel másold a fájlokat a wp-content/updraft mappába, vagy a Meglévő biztonsági mentések résznél használd a Biztonsági mentési fájlok feltöltése hivatkozást.
3. A célon kattints A helyi mappa újbóli átvizsgálása új mentéskészletek kereséséhez hivatkozásra.
4. A mentéskészlet melletti Visszaállítás gombbal indítsd a visszaállítást.

Hogy a jövőben a helyi példány megmaradjon, a Beállítások fülön kattints a Szakértői beállítások megjelenítése hivatkozásra, kapcsold ki a Helyi biztonsági mentés törlése jelölőnégyzetet, és mentsd a módosítást. A helyben tartott fájlokra nem vonatkoznak a megőrzési korlátok.

Eltérő PHP- és WordPress-verzió

A forrás és a cél PHP- és WordPress-verziója egyezzen, különben a visszaállítás nem biztos, hogy jól működik. Hogy a forrás hogyan viselkedik másik verzióval, az áttelepítés előtt kipróbálhatod egy ideiglenes klónon (UpdraftClone).

A kulcs nem a távoli webhelyhez tartozik

Lásd a Költözés új tárhelyre fejezet végét.

Hol találod a naplót?

Az UpdraftPlus naplófájljai alapból a webhely wp-content/updraft mappájában vannak, log. kezdetű névvel (például log.e6e671bf1be6.txt). Az áttelepítéshez tartozó napló módosítási ideje megegyezik az áttelepítés idejével.

ModSecurity

A ModSecurity egy webalkalmazás-tűzfal, amely Apache, NGINX és IIS kiszolgálókon is elérhető. Ha a küldés a kapcsolódási szakaszban elakad, kérdezd meg a tárhelyszolgáltatót, bekapcsolt-e. Ha igen, valószínűleg ki kell vennie az áttelepítést a tűzfal szabályai alól.

Gyakori hibaüzenetek

Ezek a hibák jellemzően a küldés közbeni kapcsolódási hibára utalnak (tűzfal, proxy, időtúllépés):

Unexpected response: Error: Response from remote site could not be understood (response_not_understood)
Unexpected response: Error: Unexpected HTTP response code (403) (unexpected_http_code)
remotesend: upload: error (Exception)
remotesend: ERROR (Exception)
updraft_send_command: error: UpdraftPlus: could not parse the JSON (502)

pCloud időtúllépés

pCloud: chunked upload exception (Exception): cURL error 28: Operation timed out after 180001 milliseconds with 0 bytes received

A mentés pCloudra való feltöltése időtúllépést kapott, ami a tárhelyszerver és a pCloud közötti hálózati hibából is adódhat. Javítás:

1. Nyisd meg a Beállítások fület, és kattints a Szakértői beállítások megjelenítése hivatkozásra.
2. Az Archívumok felosztása ekkora méretnél mezőben csökkentsd a méretet 25 MB-ra.
3. Kattints a Módosítások mentése gombra.

MySQL-hibák az adatbázis áttelepítésekor

Az adatbázismentés néha olyan hibát ad, amely megakadályozza az áttelepítés befejezését. Tipikus ok, hogy a forrás és a cél MySQL-verziója különbözik. Példa a hibákra:

An error (1) occurred: @@GLOBAL.GTID_PURGED cannot be changed: the new value must be a superset of the old value
Requested table character set (utf8) is not present

Megoldás: a forrás és a cél MySQL-verziója legyen azonos. Az áttelepítés után a MySQL-t frissítheted a legújabb verzióra.

Csak a főoldal működik, a többi 404-et ad

Ez nem rossz jel: ha a főoldal jól megjött, az áttelepítés nagy része sikerült. Ha a főoldal működik, de a többi oldal 404-et ad, a webszerver állandó hivatkozásokra (permalinkekre) vonatkozó beállítása hiányzik. Ez a beállítás a szép címeket (például www.example.com/rolunk/) irányítja át a WordPress tényleges fájljaihoz. A kiszolgáló konfigurációjához tartozik, ezért a WordPress nem mindig tudja egyedül beállítani.

Milyen webszervert használ a tárhelyed?

Gyakran kiderül a 404-es oldalból. Ha nem, nyisd meg az UpdraftPlus Haladó eszközök fülét: a webhelyinformációk között megtalálod a webszerver típusát (belépni az áttelepített oldal adataival tudsz, mert a belépési adatok is átkerültek). Végső esetben kérdezd meg a tárhelyszolgáltatót.

Apache és IIS

Az Apache szerverek jellemzően a WordPress gyökérmappájában lévő .htaccess fájlt használják, az IIS pedig a web.config fájlt. A WordPress ezeket általában magától létrehozza. Ha ez nem történt meg:

1. Nyisd meg a WordPress adminban a Beállítások → Állandó hivatkozások oldalt, és mentsd a beállításokat. Ilyenkor a WordPress másodszor is megpróbálja létrehozni a fájlt. Ha elsőre nem sikerült, valószínűleg most sem fog, de megér egy próbát.
2. Ellenőrizd a WordPress gyökérmappájának jogosultságait. Az a PHP-motor, amelyen a WordPress fut, létrehozhat-e fájlt abban a mappában?
3. Saját Apache szerver esetén ellenőrizd, hogy a mod_rewrite modul be van kapcsolva (telepítéstől függően rewrite_module néven is szerepelhet), és hogy a konfiguráció engedi a .htaccess fájlok érvényesülését (például az AllowOverride beállítás a httpd.conf fájlban). Tárhelyszolgáltatónál ez szinte biztosan rendben van.

Egyéb webszerverek

Nginx, Zeus, lighttpd, LiteSpeed és más szerverek esetén valószínűleg kézzel kell beállítani az állandó hivatkozásokat. Keress a szervered nevére és a „WordPress permalinks” kifejezésre; Nginx-hez, lighttpd-hez és IIS-hez is találsz kész beállítási útmutatót.

Fehér képernyő az áttelepítés után

Ha az áttelepítés után az oldal kezdőlapja üres, fehér képernyőt mutat, a WordPress (pontosabban az a PHP-motor, amelyen fut) összeomlott. Ki kell deríteni, miért, és melyik összetevő okozza.

Befejeződött az áttelepítés?

Először nézd meg, a folyamatot mutató böngészőablakban kész lett-e a művelet. Ha még fut, várd meg. Ha egyszerűen megállt, a webszerveren valószínűleg túl alacsony az időkorlát. Kérd meg a szerver üzemeltetőjét, hogy emelje meg, vagy telepíts részletekben: előbb a bővítmények, sablonok és egyebek, aztán a feltöltések, végül az adatbázis. A továbbiak azt feltételezik, hogy az áttelepítés befejeződött.

Gyakori okok

Mivel a WordPress korábban működött, valószínűleg a mentésben lévő valamelyik bővítmény vagy az aktív sablon a hibás. Egyes fejlesztők csak szűk körű WordPress-környezetben tesztelték a bővítményüket. Más esetben a bővítmény egyszerűen régebbi, mint a mostani WordPress, vagy csak Linuxon próbálták ki, vagy a régi PHP-verziónál működik, az újnál nem (vagy fordítva).

Hibakeresés bekapcsolása

A wp-config.php fájlban (általában a webhely gyökérmappájában) állítsd a WP_DEBUG értékét false-ról true-ra, majd töltsd be újra az oldalt. Előfordulhat, hogy hibaüzenet jelzi, melyik bővítmény okozza a gondot.

PHP-hibanapló

Ha így sem derül ki, keresd meg a PHP hibanaplóját (ha nem te üzemelteted a szervert, kérdezd meg az üzemeltetőt). Nézd a legutóbbi hibaüzeneteket; ha régóta nem volt hiba, töltsd be újra az oldalt.

PHP memóriakorlát emelése

Egyes szervereken a WordPress azért omlik össze, mert eléri a memóriakorlátot, hibaüzenet nélkül. Írd a wp-config.php fájlba, majd töltsd újra az oldalt:

define('WP_MEMORY_LIMIT', '512M');

A hibás összetevő megkeresése

Ha ez sem segít, kapcsold ki egyenként (vagy sok bővítménynél több csoportban) a bővítményeket és a sablont. Először próbáld meg az admint (/wp-admin): ha be tudsz lépni, a Bővítmények oldalon kapcsold ki őket, és minden után próbáld meg az oldalt.

Ha az admin nem érhető el, nevezd át kézzel a mappáikat a wp-content/plugins és a wp-content/themes mappában. Egy bővítmény mappája a nevét viseli (például wp-content/plugins/akismet); ha átnevezed (például akismet2), kikapcsol. Az oldal nyilvános része ezzel még nem indul el, de amint az a bővítmény átneveződik, amelyik a belépést is akadályozta, be tudsz lépni az adminba, és ott látod, melyik volt a hibás. Ezután az ártatlan bővítményeket nevezd vissza az eredeti nevükre, és a Bővítmények oldalon kapcsold be újra.