Manj je več: pospravljanje in reševanje sporov

Modul 5: Teme in vtičniki · Čas branja: 9 minut

Učni cilj: Po tej lekciji boste znali počistiti vtičnike ter sami odkriti in odpraviti konflikt ali belo stran.

Ključni pojmi: onemogočanje proti odstranjevanju, neaktivna koda, kritična napaka, način za obnovitev (recovery mode), Zdravje spletišča, način za odpravljanje težav, preimenovanje mape vtičnika, WP_DEBUG, WP_DEBUG_LOG, debug.log, dnevnik napak

Izklop ni isto kot odstranitev

Pri Vtičnikih lahko vtičnik onemogočite ali odstranite. Razlika:

• Onemogoči: WordPress vtičnika ne naloži več. Vendar datoteke ostanejo v wp-content/plugins/ in so pogosto še vedno dostopne neposredno prek spletnega strežnika. Če je v posamezni PHP-datoteki tega vtičnika varnostna luknja, ta luknja še vedno obstaja. Vlomilci iščejo znane ranljive datoteke, ne aktivnih vtičnikov.
• Odstrani: datoteke se odstranijo. Nekateri vtičniki ob odstranitvi počistijo tudi svoje nastavitve in tabele v podatkovni bazi; drugi jih pustijo.

Če vtičnika ne uporabljate več, ga odstranite. Onemogočanje je namenjeno le začasni uporabi (med iskanjem težave). Enako velja za teme (lekcija 2.4).

Pospravljanje: redno čiščenje

Enkrat na četrtletje (lekcija 9.4) preglejte svoje vtičnike. Za vsak vtičnik si zastavite naslednja vprašanja:

1. Za kaj je namenjen? Če ne veste več, ugotovite. Pogosto se izkaže, da je bil vtičnik nekoč nameščen za eno samo stvar in nikoli odstranjen.
2. Se še uporablja? Vtičnik za drsnik (slider), čeprav nikjer ni drsnika, vtičnik za obrazec, čeprav Vaša kontaktna stran uporablja drug obrazec.
3. Ali gre brez njega? Ali to že zna WordPress, tema ali drug vtičnik (lekcija 5.3)?
4. Se še vzdržuje? Kdaj je bil nazadnje posodobljen, je še v mapi vtičnikov?

Pospravljanje najprej izvedite v testnem okolju (staging) (lekcija 8.3) ali vsaj naredite varnostno kopijo, in odstranite po en vtičnik naenkrat, tako da veste, kaj je šlo narobe, če kaj gre narobe. Bodite pozorni na kratke kode (shortcodes): če odstranite vtičnik, ki je prikazoval [formulier id="2"], bo to besedilo potem dobesedno ostalo na Vaši strani.

Ko gre kaj narobe: kritična napaka

Po posodobitvi, novem vtičniku ali nadgradnji PHP nenadoma zagledate:

Na spletišču je prišlo do kritične napake.

ali povsem belo stran. To pomeni, da se je PHP ustavil zaradi usodne napake (fatal error), preden je bila stran izrisana (lekcija 1.2). Največkrat gre za vtičnik ali temo, ki ni združljiva z nečim drugim: drugim vtičnikom, novo različico WordPressa ali različico PHP.

Od različice WordPress 5.2 naprej WordPress v takem primeru naredi dvoje:

• pošlje e-sporočilo na naslov skrbnika s podatkom, kateri vtičnik ali tema je povzročil napako, in posebno povezavo;
• s to povezavo se prijavite v način za obnovitev (recovery mode): skrbništvo nato deluje, vtičnik, ki je povzročil napako, pa je začasno onemogočen, tako da ga lahko posodobite, zamenjate ali odstranite.

Zato je tako pomembno, da redno berete e-pošto na naslovu skrbnika (lekcija 2.2).

Samostojno iskanje: koraki

Če e-sporočila ne prejmete ali način za obnovitev ne deluje? Tako najdete rešitev sami.

1. Preglejte dnevnik napak

Napaka je skoraj vedno zapisana v dnevniku napak spletnega strežnika ali PHP. Pri DirectAdmin ga najdete pri dnevnikih Vaše domene. Iščete vrstico z PHP Fatal error in časom Vašega poskusa:

PHP Fatal error:  Uncaught Error: Call to undefined function create_function()
in /home/gebruiker/domains/example.com/public_html/wp-content/plugins/oude-slider/slider.php:42

Pot pove, kdo je kriv: tukaj vtičnik v mapi oude-slider. Preostanek vrstice pove zakaj (tukaj: funkcija, ki je bila v PHP 8 odstranjena, lekcija 8.4).

2. Vklopite dnevnik razhroščevanja (ne prikaza na zaslonu)

Če v dnevniku napak ni nič uporabnega, v datoteki wp-config.php (nad vrstico »nehajte urejati«) nastavite:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

WordPress nato vse napake zapiše v wp-content/debug.log, ne da bi jih prikazal obiskovalcem. Tega nikoli ne pustite vklopljenega dlje, kot je potrebno: debug.log se nahaja v mapi, ki jo ponuja spletni strežnik, in kdor pozna naslov, ga lahko prebere. V njem so poti, včasih uporabniška imena in druge informacije, ki vlomilcu pomagajo. Po iskanju razhroščevanje spet izklopite in odstranite debug.log. Ali pa naj WordPress dnevniško datoteko zapisuje zunaj spletne mape, tako da pri WP_DEBUG_LOG navedete pot (na primer '/home/gebruiker/logs/wp-debug.log', če Vaš ponudnik gostovanja to omogoča). V lekciji 7.4 preverite, da debug.log ni javno dostopen.

3. Izklop vtičnika brez dostopa do skrbništva

Če ne morete do skrbništva, sumljiv vtičnik izklopite tako, da preimenujete njegovo mapo, prek Upravitelja datotek ali SFTP:

wp-content/plugins/oude-slider   wordt   wp-content/plugins/oude-slider-uit

WordPress vtičnika tako ne najde več in ga izklopi. Če ne veste, kateri vtičnik je kriv, preimenujte kar celotno mapo plugins v plugins-uit: vsi vtičniki se izklopijo. Če spletno mesto nato deluje, ustvarite novo prazno mapo plugins, vtičnike vračajte enega za drugim in po vsakem preverite, ali se napaka ponovi. Enako velja za temo: preimenujte mapo aktivne teme in WordPress preklopi na privzeto temo, če je ta še na voljo (lekcija 2.4).

4. Konflikti brez usodne napake

Ni vsaka težava kritična napaka. Včasih ne deluje samo ena funkcija: gumb ne naredi ničesar, obrazec se ne pošlje, urejevalnik se naloži le napol. Takrat gre pogosto za konflikt med dvema vtičnikoma ali med vtičnikom in temo. Za to je priročen uradni vtičnik Health Check & Troubleshooting: v načinu za odpravljanje težav samo za Vašo sejo izklopi vse vtičnike in preklopi na privzeto temo, medtem ko obiskovalci še naprej vidijo običajno spletno mesto. Nato jih vklapljate enega za drugim, dokler se težava ne ponovi.

Preverite tudi konzolo Vašega brskalnika (F12): napake JavaScript pogosto navedejo datoteko in s tem vtičnik.

Zdravje spletišča

Pod Orodja > Zdravje spletišča WordPress samodejno preveri Vaše spletno mesto: zastarelo različico PHP, vtičnike in teme, ki niso aktivni, manjkajoče razširitve PHP, REST API, ki ne deluje, in zakasnjena načrtovana opravila. Na zavihku Informacije so vsi podatki Vaše namestitve (različice, poti, nastavitve PHP). Ta zavihek lahko kopirate in pošljete, kadar prosite za pomoč. Po vsaki večji spremembi si ga na kratko oglejte.

Povzetek

• Onemogočanje pusti datoteke na mestu; odstranite vtičnike in teme, ki jih ne uporabljate.
• Vsako četrtletje pospravite, po en vtičnik naenkrat, z varnostno kopijo ali v testnem okolju.
• Ob kritični napaki WordPress pošlje e-sporočilo s povezavo do načina za obnovitev.
• Dnevnik napak ali debug.log navede pot krivca; po iskanju razhroščevanje spet izklopite, saj je debug.log sicer javno dostopen.
• Brez dostopa do skrbništva vtičnik izklopite s preimenovanjem njegove mape; konflikte iščete z načinom za odpravljanje težav.

Kviz

Naloga

Naloga A5.4: Ali Vaš dnevnik razhroščevanja (debug log) ni javno dostopen? Vnesite naslov Vašega spletnega mesta in s kodo, ki jo dobite v okviru naloge, dokažite, da gre za Vaše lastno spletno mesto (zapis TXT ali majhna datoteka). Program nato poskusi dostopati do /wp-content/debug.log: dobro je, če ta datoteka ne obstaja ali je dostop zavrnjen (404 ali 403). Če program dobi datoteko nazaj, je to prikazano rdeče. Poleg tega program prešteje, koliko različnih map vtičnikov se pojavi v HTML Vaše domače strani (le v informativne namene).

Naloga D5.4: Urejanje seznama vtičnikov. Sestavite seznam vseh svojih vtičnikov (aktivnih in neaktivnih): ime, namen, ali je še potreben (da/ne), alternativa brez vtičnika. Odstranite (po varnostni kopiji ali v testnem okolju) vtičnike, ki jih ne potrebujete več, enega za drugim, in po vsaki odstranitvi preverite, ali spletno mesto še deluje. Vpišite, koliko vtičnikov ste imeli in koliko jih je ostalo, ter zabeležite, ali so ostale kratke kode (shortcodes), ki ste jih morali pospraviti.

Dodatno branje

Ti članki opisujejo korake v nadzornih ploščah WebOké; v drugih nadzornih ploščah delujejo podobno.

• Priročnik DirectAdmin 18.1: Moja spletna stran je bela ali javlja napako 500
• Napaka 500 ali »kritična napaka« na Vaši spletni strani (tudi po posodobitvi WordPressa)
• Priročnik DirectAdmin 14.6: Napake po nadgradnji PHP in iskanje dnevnika napak
• Priročnik DirectAdmin 17.2: Povzetek in dnevniki spletnega mesta: dnevnik napak in dnevnik dostopa
• Kako razhroščujem PHP brez spreminjanja datoteke php.ini?
• Razhroščevanje v WordPressu (developer.wordpress.org, angleško): https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/