Frissítés után nem működik a WordPress-oldal: vissza az előző verzióhoz

Mi frissült?

Egy WordPress-webhelyen négy dolog frissül, és mindegyik másképp állítható vissza: a WordPress magja, a bővítmények, a sablon és a szerver PHP-verziója, amelyet a tárhelyszolgáltató a saját oldalán léptet. Hogy kiderüljön, melyik változott:

• A WordPress e-mailjei: automatikus frissítés után a WordPress levelet ír a webhely adminisztrációs e-mail-címére, például „[Webhely neve] Néhány bővítmény automatikusan frissült” tárggyal, a változások listájával.
• A bővítmények oldala: az „Automatikus frissítések” oszlop mutatja, melyek frissülnek maguktól, és minden sor kiírja a telepített verziót.
• Eszközök > Webhely Egészség > Információ: a Kiszolgáló szakasz megadja a PHP-verziót, a bővítményekről és a sablonokról szóló szakaszok pedig az egyes összetevők verzióját.
• A mappák dátuma: a frissítés által újraírt bővítménymappa a frissítés dátumát viseli.

wp plugin list
ls -lt wp-content/plugins | head

Az első parancs a bővítményeket verziójukkal és állapotukkal listázza; a második a bővítménymappákat a legutóbb módosítottól a legrégebbiig. Vesse össze azzal az időponttal, amikor a webhely megváltozott.

A gyorsítótárak ürítése, mielőtt következtetést vonna le

Frissítés után a CSS- és JavaScript-fájlok tartalma megváltozik, egy gyorsítótár viszont továbbra is a régieket szolgálhatja ki. Az eredmény hibának tűnik: szétesett elrendezés, nem nyíló menük. Ebben a sorrendben ürítse a gyorsítótárazó vagy optimalizáló bővítmény gyorsítótárát, a tárhelyszolgáltatóét, ha kínál ilyet, majd a böngészőét, és töltse újra az oldalt. Ha a webhely helyreáll, nem a frissítés volt a hibás.

A webhely karbantartási módban ragadt

Frissítés közben a WordPress egy .maintenance fájlt hoz létre a webhely gyökerében, és kiírja: „Tervezett karbantartási munkák zajlanak, ezért a honlap tartalma rövid ideig nem elérhető. Érdemes lesz visszatérni egy perc múlva.” Ha a frissítés megszakad, a fájl a helyén marad. A WordPress tíz perccel a benne tárolt időpont után figyelmen kívül hagyja; ha nem akar várni, vagy az üzenet megmarad, törölje SFTP-n vagy a tárhelyszolgáltató fájlkezelőjén keresztül. Mivel a neve ponttal kezdődik, kapcsolja be a rejtett fájlok megjelenítését, hogy lássa.

Ezután lépjen a Vezérlőpult > Frissítések oldalra: azt az elemet, amelynek frissítése megszakadt, újra kell indítani, vagy az előző verziójában újratelepíteni.

Egy bővítmény előző verziójának visszaállítása

Az előző verzió újratelepítése lecseréli a bővítmény fájljait, és megtartja a beállításait, amelyek az adatbázisban vannak.

wp plugin install bovitmeny-neve --version=2.4.1 --force

• A WordPress.org bővítménytárában lévő bővítmény: a nyilvános oldalán a „Bővített nézet” fül a „Korábbi verziók” listához vezet. Töltse le a kívánt archívumot, majd a „Bővítmények hozzáadása” oldalon kattintson a „Bővítmény feltöltése” gombra: a WordPress felismeri a már telepített bővítményt, és felajánlja a „Cseréljük ki a jelenlegit a feltöltöttel” lehetőséget.
• Kiadótól vásárolt bővítmény: a korábbi verziók általában a nála lévő ügyfélfiókjából tölthetők le.
• Ezután: kattintson a bővítmény sorában az „Automatikus frissítés kikapcsolása” linkre, amíg a kiadó javítást nem ad ki.

A WordPress két esetben már magától visszalép. A 6.3-as verzió óta, ha egy bővítmény vagy sablon frissítése menet közben meghiúsul, a régi verzió visszakerül a helyére. A 6.6-os verzió óta, ha egy aktív bővítmény automatikus frissítése végzetes hibát okoz, a WordPress újratelepíti az előző verziót. Azt a frissítést, amely lefut, és végzetes hiba nélkül ront el egy funkciót, kézzel kell visszaállítani.

A sablon: az előző verzió és az elveszett módosítások

wp theme install sablon-neve --version=3.1.0 --force

A sablon frissítése minden fájlját lecseréli. A közvetlenül a sablon fájljaiban, például a functions.php fájlban vagy egy stíluslapon végzett módosítások így minden frissítéskor eltűnnek. A frissítés előtt készült biztonsági másolatból visszanyerhetők; tartós megőrzésükhöz egy gyermeksablonba kerülnek, amelyet a szülősablon frissítései érintetlenül hagynak.

A WordPress magja

A WP-CLI a mag egy adott verzióját telepíti újra:

wp core update --version=7.0 --force

A mag főverziós frissítése az adatbázis szerkezetét is módosíthatja, ezt a parancs változatlanul hagyja. Gyakran az a legbiztosabb, ha a mag naprakész marad, és a nem kompatibilis bővítményt vagy sablont állítja vissza. Ha a mag visszaállítása elkerülhetetlen, a frissítés előtt készült teljes biztonsági mentésből történik.

A PHP-verzió, amelyet a tárhelyszolgáltató váltott

A tárhelyszolgáltatók akkor léptetik a PHP-verziót, amikor a régiek már nem kapnak biztonsági javításokat. Egy régi bővítmény vagy sablon ilyenkor végzetes hibával leállhat. A tárhelyszolgáltató kezelőfelületén általában kiválasztható a webhely PHP-verziója:

1. Jegyezze fel a jelenlegi verziót, majd térjen vissza az előzőre.
2. Ellenőrizze, hogy a webhely újra működik.
3. Frissítse vagy cserélje le a hibás összetevőt, amelyet a hibakeresési napló azonosít.
4. Váltson vissza a friss verzióra.

Ez a visszalépés hibaelhárítási lépés: a biztonsági javítások nélküli PHP-verzió kiszolgáltatottá teszi a webhelyet. A php.net hivatalos ütemterve szerint a PHP 8.1 2025. december 31. óta nem kap biztonsági javításokat, a PHP 8.2 2026. december 31-ig, a PHP 8.3 pedig 2027. december 31-ig kap. A WordPress a PHP 8.3-as vagy újabb verzióját ajánlja.

Teljes biztonsági mentés visszaállítása, végső megoldásként

A visszaállítás a fájlokat és az adatbázist is a mentés állapotába hozza. Minden eltűnik, amit a webhely azóta kapott: rendelések, űrlapüzenetek, hozzászólások, regisztrációk, közzétett bejegyzések.

1. Először exportálja, ami a mentés óta érkezett: rendeléseket, űrlapbejegyzéseket, új fiókokat.
2. Állítsa vissza a fájlokat és az adatbázist ugyanabból az időpontból, a tárhelyszolgáltató eszközével vagy a biztonsági mentést végző bővítményével. Az egyik napi fájlok és egy másik napi adatbázis nehezen értelmezhető hibákat okoznak.
3. Importálja vissza az exportált adatokat.
4. Alkalmazza újra a frissítéseket egyenként, mindegyik után ellenőrizve a webhelyet: a hiba előtt utoljára alkalmazott frissítés okozza a hibát.

A következő frissítéshez

• Egy tesztpéldány: sok tárhelyszolgáltató kínál tesztkörnyezetet (staging), amely egy kattintással lemásolja a webhelyet. A frissítések először ott futnak.
• Biztonsági mentés közvetlenül előtte, a fájlokról és az adatbázisról együtt.
• Egyszerre egy frissítés, mindegyik után a kulcsoldalak ellenőrzésével: kezdőlap, kapcsolatfelvételi űrlap, kosár.
• A bővítmény vagy a sablon változásnaplója, főverziós frissítés előtt elolvasva.