Kako oporaviti WordPress sajt posle pada

Pre ili kasnije svaki WordPress sajt će iskusiti “pad” koji definišemo kao problem sa sajtom ili nedostupnost sajta, ali šta raditi u ovakvim slučajevima, kako oporaviti WordPress sajt posle pada?

Identifikacija problema

Sajt može imati problem sa updateom ili tek instaliranim nekim dodatkom kao što je plugin ili tema. Ovakav problem treba da vas zamisli da li je dobro koristiti i dalje tu temu ili plugin ako dođe do ovako katastrofalnog problema.

Način na koji treba proveriti da li se pomenuti problem desio sa izvršavanjem ili skriptom je najčešće uključivanje debug moda na WP sajtu. Debug je po defaultu isključen jer verovatno ne želite da svako može videti gde je sajt pukao:

define( ‘WP_DEBUG’, true ); // uključivanje debug moda – prikaz grešaka

define( ‘WP_DEBUG’, false ); // isključivanje debug moda – skrivanje grešaka

Ovo podešavanje možete naći u wp-config.php fajlu u root-u vašeg sajta i promenom ove linije greške će se prikazati. Na osnovu ispisa tih grešaka možete utvrditi gde je problem.

Neke od grešaka koje nemaju veze sa kodom će sam wordpress ispisati, kao što je nedostupnost baze.

Rešavanje problema sa wordpress debug ispisom

Ako vam je debug ispis pokazao gde je problem tu komponentu treba ukloniti. Ukoliko ne možete da zaključite šta je problem premestite promenljive delove sajta – teme i pluginove. Pomerite ih privremeno u neki folder van themes i plugins foldera u WordPress-u i ako vam sajt proradi pokušajte sa vraćanjem jednog po jednog dok ne identifikujete krivca.

U nekim slučajevima hakovanja sajta neki od wordpress fajlova mogu biti promenjeni. Ovo se obično ne dešava jer će ovakva promena biti pregažena sa sledećim update-om, ali je moguća. Jednostavno raspakujte ponovo svežu instalaciju wordpress-a i pregazite postojeće fajlove. Iako se neće desiti da izgubite wp-config.php u kome se nalaze podešavanja kao što je konekcija ka bazi ipak preporučujemo da napravite backup ovog fajla.

Ukoliko dobijete poruku da u neki folder ili fajl ne može da se upiše verovatno imate pogrešno podešena prava nad fajlovima. Kod panela kao što je cPanel je ovo najčešće rešeno tako što se web server pokreće pod vlasnikom fajlova kako bi imao pristup nad njima. Ako nemate panel vlasnik bi trebao da bude www-data, httpd ili drugi korisnik u zavisnosti od Linux distribucije.

Rešavanje problema sa bazom

Baza može biti korumpirana posle pada mašine ili nestanka struje. Zatim može se desiti da je sadržaj baze izmenjen na način na koji wordpress ne može ga da iskoristi – na primer ako je neko ručno menjao podešavanja sajta direktno u bazi.

Takođe i ceo servis može biti nedostupan što može biti opasno po podatke u slučaju da je baza krahirala ili je ubijena od OOM (Out of Memory, manjak memorije). U ovom slučaju jednostavno restartujte bazu i pokrenite alat za popravku tabele koje su možda sada markirane kao krahirane.

Preporučujemo da periodično pravite kako backup sajta tako i backup baze kako se ne ne bi desilo da dođe do problema sa sadržajem koji može dovesti do nedostupnosti sajta.

Rešavanje problema sa servisima

Treći problem može biti sa servisima – web server se nije startovao ili se php-fpm nije startovao ako koristite fastcgi na primer.

U slučajevima veoma velike posete ili napada a ponekad i botova pretraživača vaš sajt može biti prezagušen. Ako je sajt zahtevan i generisanje stranica inače traje dugo ovakav load može dovesti do potpune nedostupnosti celog sajta. Između ostalog je veoma bitno imati što brži sajt pogotovo ako je sajt WordPress sa puno pluginova i custom temom. Ako je proces PHP-FPM krahirao jednostavno ga restartujte, a ako je sajt prezagušen preostaje vam ili optimizacija sajta i/ili povećanje resursa.

Ostalo

Pogrešno podešen Linux firewall može biti uzrok zašto su zatvoreni portovi 80 ili 443 i zašto se sajt ne odaziva.

Drugi problem može biti da je sajt https ali https ne odgovara jer sajt nije podešen kao https, pa je potrebno podesiti ga. Ukoliko dobijate upozorenje o sertifikatu verovatno je ili pogrešan ili istekao, sajt će u ovom slučaju raditi ali sa upozorenjem na početku koga ne želite da korisnici vide. Ako koristite Let’s Encrypt budite sigurni da je automatska obnova uredno podešena u cron-u.

Dešava se i da redirekcija napravi problem, na primer ukoliko je sajt na http a vi imate redirekciju na https, u tom slučaju će korisnik koji dođe na https sajt biti redirektovan od strane WordPress-a na http koji će redirektovati nazad na https i tako u nedogled. Srećom inžinjeri pretraživača imaju način da ovo detektuju i posle određenog broja redirekcija prikazuju upozorenje. 

Da li bi vam bilo korisno da pišemo još ovakvih članaka? Pišite nam slobodno predloge za teme u komentarima.