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

> Sikertelen áttelepítés, 404-es oldalak, fehér képernyő és MySQL-hibák az áttelepítés után.

## 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](https://hub.hellowp.io/hu/plugins/updraftplus/migralas-tarhelyvaltas/) 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):

```text
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

```text
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:

```text
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:

```php
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.