Mai puțin înseamnă mai mult: curățenie și rezolvarea conflictelor

Modulul 5: Teme și module (pluginuri) · Timp de citire: 9 minute

Obiectiv de învățare: După această lecție veți putea face ordine în modulele (pluginurile) dumneavoastră și veți putea depista și rezolva singur un conflict sau o pagină albă.

Concepte-cheie: dezactivare vs ștergere, cod inactiv, eroare critică, modul de recuperare (recovery mode), Sănătate site, modul de depanare (troubleshooting mode), redenumirea folderului unui modul, WP_DEBUG, WP_DEBUG_LOG, debug.log, jurnal de erori

A dezactiva nu înseamnă a arunca

În secțiunea Module puteți dezactiva sau șterge un modul (plugin). Diferența:

• Dezactivare: WordPress nu mai încarcă modulul. Însă fișierele rămân în wp-content/plugins/ și de multe ori pot fi accesate în continuare direct prin serverul web. Dacă un fișier PHP separat al acelui modul are o vulnerabilitate, aceasta există în continuare. Atacatorii scanează după fișiere vulnerabile cunoscute, nu după module active.
• Ștergere: fișierele dispar. Unele module își șterg la dezinstalare și setările și tabelele din baza de date; altele le lasă acolo.

Dacă nu mai folosiți un modul, ștergeți-l. Dezactivarea este doar pentru scurt timp (în timp ce căutați cauza unei probleme). Același lucru este valabil și pentru teme (lecția 2.4).

Curățenia: o verificare periodică

Treceți o dată pe trimestru (lecția 9.4) prin lista de module. Pentru fiecare modul:

1. La ce folosește? Dacă nu mai știți, aflați. Adesea se dovedește că un modul a fost instalat cândva pentru un singur lucru și nu a mai fost eliminat.
2. Mai este folosit? Un modul de slider, deși nicăieri nu există un slider; un modul de formulare, deși pagina de contact folosește alt formular.
3. Vă puteți descurca fără el? Poate WordPress, tema sau alt modul să facă deja același lucru (lecția 5.3)?
4. Mai este întreținut? Când a fost actualizat ultima dată, mai apare în directorul de module?

Faceți curățenia mai întâi în mediul de testare (staging) (lecția 8.3) sau creați cel puțin o copie de siguranță (backup) și ștergeți câte un singur modul pe rând, ca să știți ce a cauzat problema dacă ceva nu merge. Atenție la shortcode-uri: dacă ștergeți un modul care furniza [formular id="2"], acel text va apărea apoi ca atare pe pagina dumneavoastră.

Când ceva nu merge: eroarea critică

După o actualizare, un modul nou sau un upgrade PHP vedeți brusc:

A apărut o eroare critică pe acest site.

sau o pagină complet albă. Asta înseamnă: PHP s-a oprit cu o eroare fatală înainte să existe o pagină (lecția 1.2). De obicei cauza este un modul sau o temă care nu se împacă cu altceva: un alt modul, noua versiune de WordPress sau versiunea de PHP.

Începând cu WordPress 5.2, WordPress face în acest caz două lucruri:

• trimite un e-mail la adresa administratorului cu modulul sau tema care a provocat eroarea și un link special;
• cu acel link vă autentificați în modul de recuperare (recovery mode): panoul de administrare funcționează atunci, cu modulul care a provocat eroarea dezactivat temporar, astfel încât să îl puteți actualiza, înlocui sau șterge.

De aceea este atât de important să aveți o adresă de administrator pe care o citiți (lecția 2.2).

Căutarea pe cont propriu: pașii

Nu primiți niciun e-mail sau modul de recuperare nu funcționează? Iată cum găsiți singur cauza.

1. Consultați jurnalul de erori

Eroarea apare aproape întotdeauna în jurnalul de erori al serverului web sau al PHP. În DirectAdmin îl găsiți la jurnalele (logurile) domeniului dumneavoastră. Căutați un rând cu PHP Fatal error și ora încercării dumneavoastră:

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

Calea vă spune cine este vinovatul: aici modulul din folderul slider-vechi. Restul rândului vă spune de ce (aici: o funcție care a fost eliminată în PHP 8, lecția 8.4).

2. Activați jurnalul de depanare (nu afișarea pe ecran)

Dacă în jurnalul de erori nu găsiți nimic util, adăugați în wp-config.php (deasupra comentariului care spune să nu mai editați, „stop editing”):

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

WordPress scrie atunci toate erorile în wp-content/debug.log, fără să le arate vizitatorilor. Nu lăsați niciodată această setare activă mai mult decât este necesar: debug.log se află într-un folder pe care serverul web îl servește, iar oricine cunoaște adresa îl poate citi. Fișierul conține căi, uneori nume de utilizator și alte informații care ajută un atacator. După ce ați găsit cauza, dezactivați setarea și ștergeți debug.log. Sau lăsați WordPress să scrie jurnalul în afara folderului web, indicând o cale la WP_DEBUG_LOG (de exemplu '/home/utilizator/logs/wp-debug.log', dacă furnizorul de găzduire (hosting) permite acest lucru). În lecția 7.4 verificați că debug.log nu este public.

3. Dezactivarea unui modul fără panoul de administrare

Dacă nu puteți intra în panoul de administrare, dezactivați modulul suspect redenumindu-i folderul, prin File Manager sau SFTP:

wp-content/plugins/slider-vechi   devine   wp-content/plugins/slider-vechi-oprit

WordPress nu mai găsește modulul și îl dezactivează. Dacă nu știți care este, redenumiți întregul folder plugins în plugins-oprit: toate modulele se dezactivează. Dacă site-ul web funcționează atunci, creați un folder nou și gol plugins, readuceți modulele unul câte unul și verificați după fiecare modul dacă eroarea revine. Pentru o temă este la fel: redenumiți folderul temei active, iar WordPress revine la o temă implicită, dacă aceasta mai există (lecția 2.4).

4. Conflicte fără eroare fatală

Nu orice problemă este o eroare critică. Uneori o singură funcție nu merge: un buton nu face nimic, formularul nu se trimite, editorul se încarcă pe jumătate. Atunci este adesea vorba de un conflict între două module sau între un modul și temă. Pentru asta este util modulul oficial Health Check & Troubleshooting: în modul de depanare (troubleshooting mode) dezactivează toate modulele și trece la o temă implicită doar pentru sesiunea dumneavoastră, în timp ce vizitatorii văd site-ul web normal. Apoi le activați unul câte unul până când problema revine.

Verificați și consola browserului (F12): erorile JavaScript indică adesea fișierul și, prin urmare, modulul.

Sănătate site

La Unelte > Sănătate site, WordPress verifică singur site-ul dumneavoastră: versiune PHP învechită, module și teme inactive, extensii PHP lipsă, un REST API care nu funcționează, sarcini programate care rămân în urmă. Pe fila Info găsiți toate datele instalării dumneavoastră (versiuni, căi, setări PHP). Puteți copia conținutul acestei file și îl puteți trimite atunci când cereți ajutor. Aruncați o privire aici după fiecare modificare importantă.

Rezumat

• Dezactivarea lasă fișierele pe loc; ștergeți modulele și temele pe care nu le folosiți.
• Faceți curățenie în fiecare trimestru, câte un modul pe rând, cu o copie de siguranță (backup) sau în mediul de testare (staging).
• La o eroare critică, WordPress trimite un e-mail cu un link către modul de recuperare.
• Jurnalul de erori sau debug.log indică calea către vinovat; după căutare dezactivați depanarea, altfel debug.log rămâne public.
• Fără panoul de administrare dezactivați un modul redenumindu-i folderul; conflictele le căutați cu modul de depanare.

Test (quiz)

Exercițiu

Exercițiul A5.4: Jurnalul dumneavoastră de depanare (debug log) nu este public? Introduceți adresa site-ului dumneavoastră și dovediți cu codul primit în exercițiu că este propriul dumneavoastră site (o înregistrare TXT sau un fișier mic). Programul solicită /wp-content/debug.log: rezultatul este bun dacă fișierul nu există sau accesul este refuzat (404 sau 403). Dacă programul primește un fișier, rezultatul este roșu. În plus, programul numără câte foldere diferite de module apar în HTML-ul paginii principale (doar cu titlu informativ).

Exercițiul D5.4: Faceți ordine în lista dumneavoastră de module (pluginuri). Faceți o listă cu toate modulele dumneavoastră (active și inactive): nume, la ce folosește, încă necesar (da/nu), alternativă fără modul. Ștergeți (după o copie de siguranță sau în mediul de testare) modulele care nu mai sunt necesare, câte unul pe rând, și verificați după fiecare ștergere dacă site-ul web funcționează în continuare. Completați câte module aveați și câte au rămas și notați dacă au rămas shortcode-uri pe care a trebuit să le eliminați.

Lecturi suplimentare

Aceste articole descriu pașii din panourile WebOké; în alte panouri funcționează în mod similar.

• Manual DirectAdmin 18.1: Site-ul meu este alb sau afișează o eroare 500
• Eroare 500 sau „eroare critică” pe site-ul dumneavoastră (inclusiv după o actualizare WordPress)
• Manual DirectAdmin 14.6: Erori după o actualizare PHP și găsirea jurnalului de erori
• Manual DirectAdmin 17.2: Site summary & logs: jurnalul de erori și jurnalul de acces
• Cum pot depana PHP fără a modifica php.ini?
• Depanarea în WordPress (developer.wordpress.org, în engleză): https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
• Alegerea, evaluarea și curățarea pluginurilor WordPress