Vajutasid „Uuenda“. Nüüd ütleb avaleht, et veebilehel tekkis kriitiline viga. Võimalik, et hommiku esimene klient näeb täpselt sama teadet.
Kui WordPressi uuendus lõhkus lehe, alusta taastamisest, mitte järgmisest uuendusest. Siin on sammud, millega saad ligipääsu tagasi, leiad vea põhjuse ja kontrollid ka neid kohti, mis võivad katki olla ilma ühegi veateateta.
WordPressi uuendus lõhkus lehe - mida teha kõigepealt?
- Ära vajuta uuesti „Uuenda“. Pane kirja, mida ja millal uuendasid. Kui uuendasid mitu pluginat korraga, märgi need kõik üles. Iga uus muudatus teeb vea leidmise keerulisemaks.
- Vaata administraatori e-posti, ka rämpsposti kausta. Alates WordPress 5.2-st võib surmava vea kaitse saata erilise taastamislingi. Selle kaudu saad sisse logida, samal ajal kui vigane plugin või teema on peatatud. Enne järgmisi muudatusi vaata, mille WordPress peatas.
- Vali sümptomile sobiv samm. Valge ekraan või kriitiline viga tähendab, et tasub uurida vealogi ning kontrollida pluginaid ja teemat. Kui teade „Briefly unavailable for scheduled maintenance“ ei kao, ava lehe failid SFTP või majutuse failihalduriga ja kustuta WordPressi juurkaustast fail
.maintenance. Ära kustuta sarnase nimega kausta. - Lülita tõenäoline süüdlane välja. Kasuta taastamisvaadet, kui see avaneb. Kui sisse ei pääse, nimeta plugina kaust allpool kirjeldatud viisil ümber. Kui jama algas teema uuendusest, aktiveeri selle asemel mõni WordPressi vaiketeema.
- Võta muudatus tagasi. Taasta varukoopiast töötanud plugina või teema versioon. Kui tead, milline plugina versioon töötas, võid paigaldada ka selle varasema versiooni. Enne terve e-poe taastamist räägi majutajaga: täielik taastamine võib asendada pärast varukoopiat tulnud tellimused.
- Tühjenda vahemälu ja proovi uuesti. Vana salvestatud stiilifail võib jätta mulje, et uuendus läks valesti. Tühjenda lehe, majutuse ja kasutatava CDN-i vahemälu ning laadi vigane leht uuesti.
Ära eelda, et kõik on korras lihtsalt sellepärast, et avaleht avaneb. Väikese e-poe jaoks võib mittetöötav ostukorv olla hullem kui selge veateade.
Leia plugin, mis lehe katki tegi
Võib-olla kahtlustad pluginauuendust, aga wp-admin ei lase enam sisse. Alusta taastamiskirjast. Kui sellest abi pole, lülita WordPressi silumine sisse SFTP või majutuse failihalduri kaudu. Ava wp-config.php ja lisa või muuda järgmisi seadeid enne rida, mis käsib faili muutmise lõpetada:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Ära jäta faili samu määranguid topelt. Laadi katkine leht uuesti ja ava wp-content/debug.log. Otsi viimastest kirjetest plugina või teema kausta nime ning faili, kus viga tekkis. Logi on vihje, mitte lõplik otsus: konflikt võib välja paista ka pluginast, mis juhtus viimasena käivituma.
Kui leiad kahtlase plugina, nimeta selle kaust asukohas wp-content/plugins ümber, näiteks nimest plugin-name nimeks plugin-name-off. WordPress ei leia seda enam vanast asukohast ja saad uuesti sisselogimist proovida. Kui kasutad käsurida, saad plugina WP-CLI abil välja lülitada:
wp plugin deactivate plugin-name
Kui ligipääs on tagasi, kontrolli, milline versioon oli kasutusel enne uuendust. WP-CLI kaudu saadaoleva plugina puhul saad teadaolevalt töötanud versiooni paigaldada nii:
wp plugin install plugin-name --version=X.Y.Z --force
Asenda näidises plugina tunnus ja versioon õigete väärtustega. Teine võimalus on varukoopia. Näiteks Contact Form 7 6.2 põhjustas mõnel lehel kriitilise vea; selle juhtumi jaoks on olemas juhend Contact Form 7 6.2 vea parandamiseks.
Pärast testimist lülita silumine välja: määra WP_DEBUG ja WP_DEBUG_LOG väärtuseks false. Kui logi enam vaja pole, kustuta see. Vealogisse võib jääda infot, mida ei maksa niisama alles hoida.
Millal taastada terve leht varukoopiast?
Kui uuendus muutis mitut asja ja vea põhjust ei õnnestu eraldada, võib vahetult enne uuendust tehtud varukoopia taastamine olla kõige kiirem tee. Aga mis juhtus pärast selle koopia tegemist? Kas tuli uusi tellimusi, vormipäringuid või sisumuudatusi? Säilita need enne taastamist või küsi abi ainult vajaliku osa taastamiseks. Töötava avalehe nimel ei tasu tänaseid tellimusi ära kaotada.
Miks WordPressi uuendused vahel lehe lõhuvad?
Tavaliselt ei lähe WordPress üksi katki. Katki läheb hoopis mõne lehe osa omavaheline sobivus. Levinud põhjused on need:
- Pluginate konflikt: kaks pluginat ootavad samalt funktsioonilt erinevat käitumist.
- PHP muutus: plugin vajab uuemat PHP versiooni või muutis majutaja PHP versiooni ja vana kood ei tööta sellega.
- Teema kohandused: alamteema või aegunud WooCommerce’i mall ei sobi enam uuendatud pluginaga.
- Leheehitaja muudatused: suurem versiooniuuendus muudab seda, kuidas lehe osi kuvatakse.
- Oma kood: lõik failis
functions.phpsõltub käitumisest, mis vahepeal muutus. - Pikk paus uuenduste vahel: mitme versiooni korraga vahele jätmine teeb konflikti leidmise raskemaks. Ka vana vahemällu jäänud CSS või JavaScript võib layout’i katkisena näidata, kuigi uuendus ise õnnestus.
Seepärast tühjendaksin enne leheehitaja uuenduse tagasipööramist vahemälu. Mõnikord on uus kood korras, aga külastajale näidatakse eilseid faile.
WordPressi kaitsemehhanismid - ja mida need ei märka
WordPressil on omad kaitsed. Versioon 6.3 lisas automaatse tagasipööramise juhuks, kui käsitsi tehtav plugina või teema uuendus paigaldamise ajal ebaõnnestub. Versioon 6.6 lisas tagasipööramise plugina automaatsele uuendusele, kui kohe pärast seda tekib surmav viga. Taastamisrežiim võib lasta administraatori sisse, kui vigane plugin või teema on peatatud.
Kasulik? Jah. Aga see pole sinu ettevõtte lehe täielik test. Need kaitsed ei märka sassis kujundust, JavaScripti viga, mis peatab broneerimisvormi, ega ostukorvi, kus tooteid saab vaadata, aga tellimust lõpuni teha ei saa.
Ka WordPress.org-i kontroll pluginauuendustele otsib väljalasetest pahatahtlikku koodi. See ei kontrolli, kas uuendus sobib just sinu teema, PHP versiooni ja teiste pluginatega.
Kuidas WordPressi uuendustega seotud tõrkeid vältida?
Minu eelistus on teha rahulikult ettevalmistus, mitte pärast kiiruga lehte päästa. Tee vahetult enne uuendamist varukoopia ja veendu, et oskad seda taastada. Varukoopia, mille taastamist pole proovinud, on veel kontrollimata lubadus.
Suure leheehitaja, WooCommerce’i või teema uuendust proovi esmalt testkoopial. Loe suuremate versioonide muudatuste nimekirja ja võrdle plugina PHP nõudeid oma majutuse PHP versiooniga. Seejärel uuenda üks asi korraga, mitte kõike ühe nupuvajutusega. Kui midagi läheb valesti, tead, millist muudatust uurida.
Vali ka õige aeg. Reede õhtu või tund enne kampaania algust on e-poele kehv uuendusmoment. Väikesed pluginad ja turvalisusele keskenduvad pluginad võivad sobida automaatseks uuendamiseks. Leheehitaja, WooCommerce’i ja teema uuendaksin käsitsi, et jääks aega tulemust kontrollida.
Kui selleks regulaarselt aega ei ole, saab WordPressi hoolduse alates 39€ kuus kellelegi teisele anda. Point pole uuendusi vältida. Kui need kuudeks tegemata jätta, tuleb järgmine versioonihüpe lihtsalt suurem.
10 minuti kontroll pärast uuendust
Ava leht nagu tavaline külastaja ja käi läbi kohad, millest sinu äri päriselt sõltub:
- Ava avaleht ja mõni leheehitajaga tehtud leht. Kontrolli, kas kujundus või vahed on paigast ära.
- Saada proovipäring vormi kaudu ja kontrolli, kas see jõuab õigesse postkasti.
- Kui sul on e-pood, tee testtellimus ja veendu, et ost jõuab lõpuni.
- Logi sisse, ava wp-admin ja kontrolli, kas lehti, mida tavaliselt muudad, saab endiselt muuta.
- Tühjenda vahemälu ja kontrolli lehte veel korrra, soovitatavalt brauseri privaatses aknas.
24/7 veebilehe seire koos märksõnakontrolliga võib valgest ekraanist kiiresti teada anda. Testtellimust see siiski ei asenda. Ostukorvi leht võib olla võrgus ka siis, kui ostu lõpetada ei saa.
Mida täna teha?
Kui leht on praegu maas, otsi enne millegi muu muutmist taastamiskiri üles. Kui leht jälle töötab pane järgmise uuenduse jaoks kalendrisse aeg varukoopia tegemiseks ja testimiseks. Võta koige esimesena ette ostuprotsess või päringuvorm - just sealt saad teada, kas klient jõuab sinuni ka pärast uuendust.