WordPress on pärast uuendust katki – mida teha?

WordPressi, plugina või teema uuendamine peaks muutma veebilehe turvalisemaks ja töökindlamaks. Vahel juhtub aga vastupidi: ilmub critical error, leht muutub valgeks, kujundus laguneb või WordPressi administraatoriala ei avane.

Sellises olukorras on kõige olulisem mitte teha paanikas järjest uusi muudatusi. Enne vana varukoopia taastamist tuleb välja selgitada, mis täpselt katki läks. Sageli piisab ühe plugina ajutisest deaktiveerimisest, vahemälu puhastamisest või PHP-versiooni korrigeerimisest.

Kiire tegevusplaan, kui veebileht on praegu maas

1. Ära tee uusi uuendusi ega kustuta faile. Pane kirja, mida ja millal viimati uuendati.
2. Tee praegusest seisust uus varukoopia, isegi kui leht on katki. E-poes võivad andmebaasis olla uued tellimused, mida vanas backup’is pole.
3. Kontrolli administraatori e-posti ja serveri vealogi. WordPress võib olla saatnud Recovery Mode’i lingi koos vea põhjustanud plugina või teema nimega.
4. Kui wp-admin ei avane, deaktiveeri viimasena uuendatud plugin FTP või File Manageri kaudu.
5. Taasta vana versioon või backup alles pärast põhjuse tuvastamist. WooCommerce’i puhul ära taasta vana andmebaasi pimesi.

Kui veebileht teenib aktiivselt müüki, tasub enne põhjalikumat sekkumist panna ostmine ajutiselt pausile või kasutada hooldusrežiimi. Nii ei teki parandamise ajal uusi tellimusi, mille andmed võivad taastamisel kaduma minna.

Sümptom, võimalik põhjus ja esimene kontroll

Sümptom	Võimalik põhjus	Mida esimesena kontrollida
„There has been a critical error“	Plugina, teema või PHP fataalne viga	Administraatori e-post, Recovery Mode ja serveri PHP error log
WordPressi valge leht	PHP fatal error, mälupuudus või pluginakonflikt	debug.log ja viimasena uuendatud plugin
HTTP 500	PHP viga, serveriseadistus, mälupiirang või vigane .htaccess	Serveri error log ja WP_DEBUG_LOG
WordPress admin ei avane	Adminis käivituv plugin, turvaplugin või PHP konflikt	Ava Recovery Mode või deaktiveeri kahtlustatav plugin
Avaleht töötab, kuid osa lehti ei avane	Püsiviited, .htaccess, mall või plugin	Salvesta püsiviited uuesti ja kontrolli serveri logi
Kujundus on katki	Vana CSS-cache, minimeerimine, CDN või Elementori failid	Puhasta cache ja genereeri CSS uuesti
Elementor ei avane	Elementor/Pro versioonikonflikt, lisa või mälupuudus	Elementor Safe Mode ning Core/Pro versioonid
Leht on hooldusrežiimi kinni jäänud	Uuendus katkes enne .maintenance faili eemaldamist	Kontrolli, kas uuendusprotsess lõppes, ja eemalda fail
WooCommerce’i ostukorv ei tööta	Cache, pluginakonflikt või andmebaasi versioonierinevus	Testi ilma cache’ita ning kontrolli WooCommerce’i logisid
Viga tekkis pärast PHP muutmist	Teema või plugin ei ühildu uue PHP-versiooniga	Plugina nõuded ja serveri PHP error log

Alusta sellest, mis vahetult enne viga muutus

Esimene küsimus ei ole „milline backup taastada?“, vaid „mis täpselt muutus?“.

Pane kirja:

• millist WordPressi versiooni uuendati
• millised pluginad said uue versiooni
• kas teemat või child theme’i muudeti
• kas serveris muutus PHP-versioon
• kas pärast uuendust puhastati cache
• kas viga ilmub kõigil lehtedel või ainult ühes kohas
• kas probleem puudutab ainult wp-admini, Elementori editori või WooCommerce’i ostuprotsessi.

Kui uuendasid korraga kümmet pluginat, on vea põhjust raskem leida. Vaata pluginate uuendamise aega, majutuse logisid ning võimalusel WordPressi Recovery Mode’i e-kirja.

WordPress critical error ja Recovery Mode

Teade „There has been a critical error on this website“ tähendab tavaliselt, et PHP ei suutnud lehe loomist lõpule viia. Põhjuseks võib olla vigane plugin, teema, kohandatud kood või serverikeskkonna sobimatus.

WordPressi sisseehitatud Recovery Mode võib saata administraatori e-posti aadressile spetsiaalse sisselogimislingi. Selles režiimis peatatakse vigane komponent sinu administraatoriseansi jaoks, et saaksid wp-admini avada ja probleemi uurida. WordPressi Recovery Mode’i juhend

Kontrolli:

• WordPressi administraatori e-posti
• rämpsposti kausta
• majutuse serveriposti või logisid
• kas kirjas nimetatakse konkreetset pluginat, teemat ja failirida.

Recovery Mode ei paranda viga automaatselt. See aitab administraatorialale ligi pääseda, et vigane komponent ajutiselt peatada või asendada.

WordPressi valge leht ja HTTP 500

WordPressi valge leht tähendab, et brauser ei saanud kuvamiseks kasutatavat vastust. HTTP 500 annab samuti teada serveripoolsest probleemist, kuid ei näita külastajale selle põhjust.

Levinud põhjused on:

• plugina või teema PHP fatal error
• uus plugin nõuab teistsugust PHP-versiooni
• PHP mälupiirang sai täis
• failid jäid uuendamisel poolikult üles laadituks
• serveri konfiguratsioon või .htaccess sai kahjustada
• mitu pluginat kasutavad omavahel ühildumatut koodi.

WordPressi ametlik tõrkeotsing soovitab valge lehe korral kontrollida esmajärjekorras pluginaid, teemat ja debug-logi. WordPressi levinud vigade juhend

HTTP 500 puhul vaata alati ka majutuse PHP error logi. Serverilogis võib olla rohkem infot kui WordPressi enda debug.log failis.

Kuidas kasutada WP_DEBUG-i ja debug.log faili?

Kui veateade ei nimeta põhjust, saad WordPressi logimise ajutiselt sisse lülitada. Lisa või muuda wp-config.php failis järgmised read enne kommentaari That's all, stop editing!:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

@ini_set('display_errors', 0);

See seadistus:

• aktiveerib WordPressi silumise
• salvestab vead tavaliselt faili wp-content/debug.log
• ei kuva tehnilisi veateateid avaliku lehe külastajatele.

Live-lehel ei tohi PHP veateateid külastajatele nähtavaks teha. Need võivad paljastada serveri failiteid, pluginate nimetusi ja muud tehnilist infot. WordPress soovitab kasutada debugimisvahendeid eelkõige arendus- või staging-keskkonnas ning hoida WP_DEBUG_DISPLAY avalikul lehel väljalülitatuna. WordPressi ametlik debugimise juhend

Ava pärast vea uuesti esilekutsumist wp-content/debug.log ja vaata faili lõppu. Otsi väljendeid:

• PHP Fatal error
• Uncaught Error
• Allowed memory size exhausted
• Call to undefined function
• Class not found
• wp-content/plugins/...
• wp-content/themes/....

Kui veatees sisaldub konkreetse plugina kaust, on sul esimene tugev vihje. Pärast diagnoosimist lülita debugimine välja ja kustuta või kaitse logifail, sest see võib sisaldada tundlikku infot.

Kuidas plugin FTP või File Manageri kaudu deaktiveerida?

Kui WordPress admin ei avane, saad vigase plugina peatada ilma wp-adminita.

1. Ava majutuse File Manager või ühendu FTP/SFTP kaudu.
2. Mine kausta:

/wp-content/plugins/

3. Leia kahtlustatava plugina kaust.
4. Nimeta see ajutiselt ümber, näiteks:

elementor-pro

muuda kujule:

elementor-pro.disabled

5. Laadi veebileht uuesti.

Kui veebileht hakkab tööle, on probleem seotud selle pluginaga või selle koostoimega mõne teise komponendiga.

Kui sa ei tea, milline plugin vea põhjustas, võid ajutiselt ümber nimetada terve kausta:

plugins

näiteks kujule:

plugins.disabled

See peatab kõik tavalised pluginad. Kui leht taastub, nimeta kaust tagasi plugins ning aktiveeri pluginad ükshaaval, kuni probleem kordub. WordPress kirjeldab sama meetodit oma pluginate tõrkeotsingu juhendis.

Ära kustuta kohe tervet pluginakausta. Ümbernimetamine on lihtsamini tagasipööratav ja säilitab failid edasiseks uurimiseks.

Kuidas pluginakonflikti täpselt leida?

Plugin conflict tähendab, et kaks pluginat või plugin ja teema mõjutavad sama funktsiooni viisil, mida arendajad pole koos testinud.

Konflikti diagnoosimiseks:

1. deaktiveeri viimasena uuendatud plugin
2. kontrolli, kas viga kadus;
3. aktiveeri plugin uuesti ainult staging-keskkonnas
4. deaktiveeri teised sama funktsiooniga pluginad
5. korda testi ühe muudatuse kaupa
6. vaata iga katse järel debug.log faili.

Näiteks võivad konflikti sattuda:

• mitu cache’i või CSS-i optimeerimise pluginat
• kaks turvapluginat
• Elementor ja selle kolmanda osapoole lisad
• WooCommerce ning makse- või tarneliides
• kaks plugina versiooni, mis kasutavad erinevat teeki
• vana kohandatud teema ja uus PHP-versioon.

Kui kõik pluginad on korraga välja lülitatud ja leht endiselt ei tööta, liigu edasi teema, PHP ning WordPressi põhifailide kontrollimise juurde.

Kuidas theme conflict’i kontrollida?

Kui viga viitab kaustale wp-content/themes/, võib probleem olla aktiivses teemas või child theme’is.

Kõige turvalisem on testida staging-keskkonnas mõne WordPressi vaiketeemaga. Kui wp-admin ei avane, saab aktiivse teema kausta FTP kaudu ümber nimetada.

Enne veendu, et serverisse oleks paigaldatud mõni töötav WordPressi vaiketeema. Muidu ei ole WordPressil katkise teema asemel midagi aktiveerida.

Kui vaiketeemaga probleem kaob, kontrolli:

• teema functions.php faili
• child theme’i kohandusi
• vananenud mallifaile
• WooCommerce’i template override’e
• teema ja uue PHP-versiooni ühilduvust
• kas uuendus kirjutas kohandatud parent theme’i failid üle.

Kui muudatused olid tehtud otse parent theme’i failidesse, võivad need teema uuendamisel kaduda. Püsivad kohandused peaksid üldjuhul asuma child theme’is või eraldi pluginas.

PHP-versiooni probleem pärast uuendust

Uus pluginaversioon võib nõuda uuemat PHP-d. Samal ajal võib vana plugin sisaldada koodi, mis uuemas PHP-versioonis enam ei tööta.

Kontrolli majutuse juhtpaneelist:

• aktiivset PHP-versiooni
• plugina või teema miinimumnõudeid
• PHP error logi
• WordPressi Site Health infot
• kas PHP muutus samal ajal mõne serveriuuendusega.

PHP-versiooni ajutine muutmine võib aidata diagnoosi kinnitada, kuid väga vana PHP-versiooni peale jäämine ei ole hea püsilahendus. Õige lahendus on uuendada või asendada ühildumatu plugin või teema.

Kui veebileht sisaldab erilahendusi, testi PHP-versiooni muutmist kõigepealt staging-keskkonnas.

WordPress rollback ehk eelmise versiooni taastamine

Kui viimane pluginauuendus põhjustas vea, võib eelmise töötava versiooni taastamine olla mõistlik ajutine lahendus.

Turvaline järjestus on:

1. tee praegusest seisust failide ja andmebaasi varukoopia
2. tuvasta täpselt probleemne plugin ja versioon
3. kontrolli plugina muudatuste logi ning võimalikke andmebaasiuuendusi
4. deaktiveeri plugin
5. taasta eelmine versioon ametlikust või arendaja usaldusväärsest allikast
6. testi veebilehe põhifunktsioone
7. peata selle plugina automaatne uuendamine kuni parandatud versiooni ilmumiseni.

Ära laadi vanu pluginaversioone juhuslikelt veebilehtedelt. Muudetud pluginapakett võib sisaldada pahavara.

Rollback ei pruugi olla ohutu, kui uuendus muutis andmebaasi struktuuri või teisendas andmeid. Sellisel juhul ei pruugi ainult vanade failide taastamisest piisata. Samuti ei tohiks turvaparandust sisaldavale vanale versioonile pikaks ajaks jääda.

Millal taastada backup?

Backupist taastamine on vajalik, kui:

• mitu komponenti sai korraga kahjustada
• uuendus jäi pooleli ja failid on puudulikud
• probleem hõlmab nii faile kui ka andmebaasi
• muudatusi on liiga palju, et neid ükshaaval tagasi pöörata
• töötav seis on varukoopias kindlalt teada.

Kui vea põhjustas ainult ühe plugina fail, on sageli parem taastada üksnes selle plugina eelmine versioon. Kogu andmebaasi taastamine võib tagasi võtta postitused, kasutajad, vormipäringud, seadistused ja e-poe tellimused.

Enne taastamist kontrolli:

• backup’i kuupäeva
• kas backup sisaldab faile ja andmebaasi
• millised andmed tekkisid pärast backup’i
• kas taastamist saab enne staging-keskkonnas proovida
• kas sul on olemas ka praeguse katkise seisu koopia.

WooCommerce: vana andmebaasi taastamine võib kustutada tellimused

WooCommerce’i puhul tuleb varukoopia taastamisega olla eriti ettevaatlik.

Tellimused, kliendid, laoseis, makseandmete viited, kupongid ja mitmed seadistused asuvad andmebaasis. Kui taastad eile tehtud andmebaasi täna, võivad kaduda kõik vahepeal tekkinud tellimused.

Ära taasta aktiivse WooCommerce’i poe vana andmebaasi enne, kui oled säilitanud pärast backup’i tekkinud tellimused ja kliendiandmed.

Enne taastamist:

1. pane checkout ajutiselt pausile või hooldusrežiimi
2. tee praegusest andmebaasist uus koopia
3. kontrolli viimase tellimuse aega ja numbrit
4. võrdle seda backup’i loomise ajaga
5. eelista võimalusel ainult plugina või teema failide taastamist
6. planeeri vajadusel uuemate tellimuste, klientide ja laoseisu valikuline ühendamine.

WooCommerce hoiatab, et backup’i ja taastamise vahele jääva perioodi tellimused, kliendid ning makseandmete viited võivad kaduda. Tellimustega või subscription’itega poe taastamine vajab seetõttu tavalisest WordPressi lehest hoolikamat andmete ühendamist. WooCommerce’i taastamise riskide juhend

Pärast taastamist testi vähemalt:

• tootelehte
• ostukorvi
• kassalehte
• makselahendust
• pakiautomaadi valikut
• tellimuskirju
• laoseisu muutumist
• makseteenuse callback’i või webhook’i
• uue tellimuse jõudmist haldusesse.

Elementor pärast uuendust

Elementori puhul võivad pärast uuendust tekkida järgmised sümptomid:

• Elementor editor ei avane
• kuvatakse „Preview could not be loaded“
• lehed on ilma kujunduseta
• päis või jalus on kadunud
• Elementor ja Elementor Pro ei ühildu
• mõni kolmanda osapoole Elementor addon põhjustab fatal error’i.

Alusta nendest sammudest:

1. kontrolli, et Elementor ja Elementor Pro versioonid oleksid omavahel ühilduvad
2. uuenda või deaktiveeri kolmanda osapoole Elementori lisad
3. kasuta Elementor Safe Mode’i, et eraldada editor aktiivsest teemast ja teistest pluginatest;
4. puhasta Elementori loodud failid ja andmed
5. puhasta WordPressi cache, serveri cache ja CDN
6. testi incognitoaknas
7. vajadusel kasuta Elementori sisseehitatud Version Controli rollback’i.

Elementori Safe Mode mõjutab tõrkeotsingu ajal editori sessiooni, mitte tavakülastaja avalikku vaadet. See aitab kontrollida, kas probleemi põhjustab teema või kolmanda osapoole plugin. Elementori Safe Mode’i juhend

Elementoril on olemas ka ametlik eelmise versiooni taastamise võimalus, kuid enne rollback’i tuleb teha backup ning jälgida Elementor Core’i ja Pro ühilduvust. Elementori rollback’i juhend

Kujundus, CSS või JavaScript on pärast uuendust katki

Kui leht avaneb, kuid näeb vale välja, ei pruugi probleem olla PHP-s. Brauser võib laadida vana CSS-faili koos uue HTML-i või JavaScriptiga.

Puhasta vahemälud järgmises järjekorras:

1. kujundusplugina või Elementori loodud failid
2. WordPressi cache-plugin
3. serveripoolne cache
4. CDN või Cloudflare cache
5. brauseri cache.

Kui probleem püsib:

• keela ajutiselt CSS-i ja JavaScripti minimeerimine
• keela failide ühendamine
• lülita skriptide viivitamine või edasilükkamine ükshaaval välja
• kontrolli brauseri Network-vaates 404-vigu
• vaata Console’ist JavaScripti vigu
• kontrolli, kas leht laadib korraga vana ja uut failiversiooni
• kompileeri kohandatud teema CSS/JS uuesti, kui see kasutab build-protsessi.

Elementori puhul kasuta tööriista Clear Files & Data või vastava versiooni CSS-i regenereerimise funktsiooni. Seejärel puhasta ka cache-plugin ja CDN. Elementori cache’i puhastamise juhend

WordPress jäi maintenance mode’i kinni

Uuendamise ajal loob WordPress juurkausta ajutise faili:

.maintenance

Kui uuendus katkeb, võib fail alles jääda ning veebileht kuvab pidevalt teadet plaanilise hoolduse kohta.

Enne faili eemaldamist veendu, et uuendusprotsess enam ei tööta. Seejärel:

1. ava FTP või File Manager
2. mine WordPressi juurkausta
3. kuva peidetud failid
4. kustuta .maintenance
5. ava wp-admin ja kontrolli, milline uuendus pooleli jäi
6. paigalda puudulik uuendus vajadusel uuesti.

WordPress soovitab ebaõnnestunud uuenduse järel eemaldada alles jäänud .maintenance faili ning kontrollida uuenduse terviklikkust. WordPressi uuendamise juhend

Kuidas tulevikus uuendusprobleemi vältida?

Täielikult ei saa riski eemaldada, kuid seda saab oluliselt vähendada.

Kasuta staging-keskkonda

Testi suuremad WordPressi, WooCommerce’i, Elementori ja PHP uuendused veebilehe koopial. Staging peab võimalikult täpselt vastama live-serveri PHP-versioonile ja seadistustele.

Tee taastatav backup

Varukoopia peab sisaldama nii faile kui ka andmebaasi. Vähemalt korra tasub kontrollida, kas seda saab päriselt taastada.

WooCommerce’i puhul kasuta sagedasemat või reaalajalähedast andmebaasi varundamist, sest tellimused võivad tekkida iga hetk.

Uuenda ühe grupi kaupa

Hea järjestus on:

1. tee backup
2. uuenda üks plugin või seotud pluginagrupp
3. testi veebilehte
4. jätka järgmise komponendiga
5. jäta WordPressi, WooCommerce’i või PHP suuremad muudatused eraldi testiks.

Kontrolli ühilduvust

Loe muudatuste logi ja süsteeminõudeid. Pööra erilist tähelepanu:

• PHP miinimumversioonile
• WordPressi toetatud versioonile
• WooCommerce’i ühilduvusele
• Elementor Core’i, Pro ja add-on’ide versioonidele
• andmebaasi migratsioonidele
• katkestatud või enam mitte toetatud pluginatele.

Testi pärast uuendust päris tegevusi

Avalehe vaatamisest ei piisa. Kontrolli:

• wp-admini
• mobiilivaadet
• menüüd ja otsingut
• kontaktivorme
• sisselogimist
• olulisi teenuselehti
• Elementori editori
• WooCommerce’i ostukorvi ja kassalehte
• testmakset ning tellimuskirju
• serveri ja WordPressi vealogi.

KKK

Mida teha esimesena, kui WordPress ei tööta pärast uuendust?

Pane kirja viimane uuendatud komponent, tee praegusest seisust varukoopia ning kontrolli Recovery Mode’i e-posti ja PHP error logi. Ära taasta kohe vana andmebaasi.

Kas plugina saab ilma wp-adminita välja lülitada?

Jah. Ava FTP või majutuse File Manager ning nimeta vastava plugina kaust wp-content/plugins/ all ajutiselt ümber.

Kas WordPress rollback on turvaline?

Rollback võib olla ajutiselt sobiv, kui probleemne komponent ja töötanud versioon on täpselt teada. See võib olla riskantne, kui uuendus muutis andmebaasi või eelmine versioon sisaldab turvanõrkust.

Miks WordPress admin ei avane, kuigi avaleht töötab?

Mõni plugin võib käivitada vigase koodi ainult administraatorialas. Põhjuseks võivad olla ka turvaplugin, mälupuudus, õiguste probleem või wp-adminis kasutatav JavaScript.

Kas vana backup’i taastamine kustutab WooCommerce’i tellimused?

Jah. Vana andmebaasi taastamine võib eemaldada kõik pärast backup’i tekkinud tellimused, kliendid, laoseisumuudatused ja muud andmed. Enne taastamist tuleb praegune andmebaas säilitada ning uuemad tellimused arvesse võtta.

Miks kujundus on katki, kuigi critical error puudub?

Tõenäoline põhjus on vana cache, puuduva CSS-faili 404-viga, minimeerimise konflikt, Elementori genereeritud failid või CDN-i vana versioon.

Millal tasub ise parandamise asemel abi küsida?

Küsi abi, kui probleem puudutab aktiivset e-poodi, serveri- või andmebaasivigu, uuemaid tellimusi, makselahendusi või olukorda, kus vea põhjus pole logidest selge. Mida rohkem juhuslikke muudatusi teha, seda raskemaks võib algse põhjuse leidmine muutuda.

Kokkuvõte

Kui WordPress on pärast uuendust katki, ei tähenda see tavaliselt, et kogu veebileht tuleb uuesti teha. Enamasti on põhjuseks üks ühildumatu plugin, teema, PHP-versioon või valesti segunenud cache.

Õige tegevusjärjekord on:

1. säilita praegune seis
2. tuvasta sümptom ja viimati tehtud muudatus
3. kontrolli Recovery Mode’i ning vealogi
4. eralda probleemne plugin või teema
5. tee rollback või taastamine ainult vajalikus ulatuses
6. testi pärast parandust veebilehe tegelikke funktsioone.

Vajad abi?

Tegid kõik aga siiski ei õnnestunud kodulehte taastada?

Kui vajad tehnilist abi, saada veebilehe aadress, nähtav veateade või ekraanitõmmis, vea tekkimise aeg ning info selle kohta, mida vahetult enne probleemi uuendati.

Tasuta esmane konsultatsioon

Selge tegevusplaan

Personaalne hinnapakkumine

Küsi pakkumist

Tasuta esmane konsultatsioon · vastame üldjuhul ühe tööpäeva jooksul