Manj je več: čiščenje in odpravljanje konfliktov

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

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

Ključni pojmi: onemogočanje proti odstranitvi, neaktivna koda, kritična napaka, obnovitveni način (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 ne pomeni odstranitve

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

• Onemogoči: WordPress vtičnika ne nalaga več. Datoteke pa ostanejo v wp-content/plugins/ in so pogosto še vedno neposredno dostopne prek spletnega strežnika. Če ima posamezna datoteka PHP tega vtičnika varnostno luknjo, ta luknja še vedno obstaja. Vlomilci iščejo znane ranljive datoteke, ne aktivnih vtičnikov.
• Odstrani: datoteke se izbrišejo. 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).

Čiščenje: redni pregled

Enkrat na četrtletje (lekcija 9.4) preglejte svoje vtičnike. Za vsak vtičnik:

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

Čiščenje najprej opravite v testnem okolju (staging) (lekcija 8.3) ali vsaj naredite varnostno kopijo, in odstranjujte po en vtičnik naenkrat, da boste vedeli, kaj je šlo narobe, če gre kaj narobe. Pazite na kratke kode (shortcodes): če odstranite vtičnik, ki je zagotavljal [obrazec id="2"], bo to besedilo potem dobesedno prikazano na Vaši strani.

Ko gre kaj narobe: kritična napaka

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

Na tem spletnem mestu je prišlo do kritične napake.

ali povsem belo stran. To pomeni: PHP se je ustavil zaradi usodne napake, preden je stran nastala (lekcija 1.2). Najpogosteje je vzrok vtičnik ali tema, ki ni združljiva z nečim drugim: z drugim vtičnikom, z novo različico WordPressa ali z različico PHP.

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

• pošlje e-sporočilo na skrbniški naslov z navedbo, kateri vtičnik ali katera tema je povzročila napako, in posebno povezavo;
• s to povezavo se prijavite v obnovitveni način (recovery mode): skrbništvo takrat deluje, vtičnik, ki je povzročil napako, pa je začasno izklopljen, tako da ga lahko posodobite, zamenjate ali odstranite.

Zato je tako pomembno, da je skrbniški naslov naslov, ki ga dejansko berete (lekcija 2.2).

Sami poiščite vzrok: koraki

Ne prejmete e-sporočila ali obnovitveni način ne deluje? Takole vzrok poiščete sami.

1. Preglejte dnevnik napak

Napaka je skoraj vedno zapisana v dnevniku napak spletnega strežnika ali PHP. V DirectAdminu ga najdete med dnevniki Vaše domene. Iščete vrstico s PHP Fatal error in časom Vašega poskusa:

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

Pot Vam pove, kdo je krivec: tukaj vtičnik v mapi stari-drsnik. 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česar uporabnega, v wp-config.php (nad vrstico »That's all, stop editing!«) dodajte:

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

WordPress bo nato vse napake zapisoval v wp-content/debug.log, ne da bi jih prikazal obiskovalcem. Tega nikoli ne pustite vklopljenega dlje, kot je treba: debug.log je v mapi, ki jo spletni strežnik ponuja javno, in kdor pozna naslov, ga lahko prebere. V njem so poti, včasih uporabniška imena in drugi podatki, ki vlomilcu pomagajo. Po iskanju to znova izklopite in izbrišite debug.log. Lahko pa WordPressu naročite, naj dnevnik zapisuje zunaj spletne mape, tako da pri WP_DEBUG_LOG navedete pot (na primer '/home/uporabnik/logs/wp-debug.log', če Vaš ponudnik gostovanja to dovoljuje). V lekciji 7.4 preverite, da debug.log ni javno dostopen.

3. Izklop vtičnika brez skrbništva

Če v skrbništvo ne morete, sumljivi vtičnik izklopite tako, da njegovo mapo preimenujete, prek Upravitelja datotek ali SFTP:

wp-content/plugins/stari-drsnik   postane   wp-content/plugins/stari-drsnik-izklop

WordPress vtičnika potem ne najde več in ga izklopi. Če ne veste, kateri je, preimenujte celotno mapo plugins v plugins-izklop: izklopijo se vsi vtičniki. Če spletno mesto nato deluje, ustvarite novo prazno mapo plugins, vtičnike vračajte enega za drugim in po vsakem preverite, ali se napaka vrne. Za temo velja enako: preimenujte mapo aktivne teme in WordPress preklopi na privzeto temo, če je ta še nameščena (lekcija 2.4).

4. Konflikti brez usodne napake

Ni vsaka težava kritična napaka. Včasih ne deluje le 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 vrne.

Preglejte tudi konzolo svojega brskalnika (F12): napake JavaScript pogosto navedejo datoteko in s tem vtičnik.

Zdravje spletišča

V Orodja > Zdravje spletišča WordPress sam 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, načrtovana opravila, ki zamujajo. Na zavihku Podatki so vsi podatki o Vaši namestitvi (različice, poti, nastavitve PHP). Ta zavihek lahko kopirate in priložite, ko prosite za pomoč. Po vsaki večji spremembi na hitro preverite tukaj.

Povzetek

• Onemogočanje pusti datoteke na mestu; vtičnike in teme, ki jih ne uporabljate, odstranite.
• Čistite vsako četrtletje, po en vtičnik naenkrat, z varnostno kopijo ali v testnem okolju (staging).
• Ob kritični napaki WordPress pošlje e-sporočilo s povezavo do obnovitvenega načina.
• Dnevnik napak ali debug.log navede pot do krivca; razhroščevanje po iskanju znova izklopite, sicer je debug.log javno dostopen.
• Brez 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 svojega spletnega mesta in s kodo, ki Vam jo da naloga, dokažite, da je spletno mesto Vaše (zapis TXT ali majhna datoteka). Program zahteva /wp-content/debug.log: rezultat je dober, če ta ne obstaja ali je dostop zavrnjen (404 ali 403). Če program dobi nazaj datoteko, je rezultat rdeč. Poleg tega program prešteje, koliko različnih map vtičnikov se pojavi v HTML Vaše domače strani (samo v vednost).

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. Vtičnike, ki niso več potrebni, odstranite (po izdelavi varnostne kopije ali v testnem okolju (staging)), po enega naenkrat, 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, ki ste jih morali počistiti.

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/
• Izbira, ocenjevanje in čiščenje vtičnikov WordPress