Modulul 5 · 5.4

Română

Nederlands English Deutsch Français Español Italiano Polski Română Čeština Magyar Slovenčina Български

Mai puțin înseamnă mai mult: curățarea ș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 să faceți ordine în module (pluginuri) și să depistați și rezolvați singur un conflict sau o pagină albă.

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

Oprirea nu înseamnă aruncarea

La Module (Plugins) puteți dezactiva sau șterge un modul (plugin). Diferența:

Dezactivare: WordPress nu mai încarcă modulul (pluginul). Dar fișierele rămân în wp-content/plugins/ și pot fi adesea accesate direct prin serverul web. Dacă există o vulnerabilitate într-un fișier PHP izolat al acelui modul (plugin), acea vulnerabilitate rămâne în continuare acolo. Atacatorii caută fișiere cunoscute ca vulnerabile, nu module (pluginuri) active.
Ștergere: fișierele sunt eliminate. Unele module (pluginuri) curăță la ștergere și setările și tabelele din baza de date; altele le lasă acolo.

Dacă nu mai folosiți un modul (plugin), ștergeți-l. Dezactivarea este doar pentru moment (în timpul căutării unei probleme). Același lucru este valabil pentru teme (lecția 2.4).

Curățarea: o rutină fixă

Parcurgeți-vă modulele (pluginurile) o dată pe trimestru (lecția 9.4). Pentru fiecare modul (plugin):

Pentru ce este? Dacă nu mai știți, verificați. Se întâmplă adesea ca un modul (plugin) să fi fost instalat cândva pentru un singur lucru și apoi să nu mai fi fost niciodată eliminat.
Mai este folosit? Un modul (plugin) de slider deși nicăieri nu există un slider, un modul (plugin) de formular deși pagina dumneavoastră de contact folosește alt formular.
Se poate fără el? Poate WordPress, tema sau alt modul (plugin) deja face asta (lecția 5.3)?
Mai este întreținut? Ultima actualizare, mai este în directorul de module (pluginuri)?

Faceți curățenia mai întâi într-un mediu de testare (staging) (lecția 8.3), sau măcar faceți o copie de siguranță, și ștergeți câte un modul (plugin) pe rând, astfel încât să știți ce a mers prost dacă ceva merge prost. Atenție la shortcode-uri: dacă ștergeți un modul (plugin) care oferea [formulier id="2"], acel text va rămâne apoi literal pe pagina dumneavoastră.

Dacă ceva nu merge: eroarea critică

După o actualizare, un modul (plugin) nou sau o actualizare de PHP, vedeți brusc:

A fost o eroare critică pe acest site web.

sau o pagină complet albă. Aceasta înseamnă: PHP s-a oprit cu o eroare fatală înainte să existe o pagină (lecția 1.2). De obicei acest lucru se datorează unui modul (plugin) sau unei teme care nu este compatibilă cu altceva: un alt modul (plugin), noua versiune de WordPress sau versiunea de PHP.

Începând cu WordPress 5.2, WordPress face atunci două lucruri:

trimite un e-mail la adresa administratorului cu modulul (pluginul) sau tema care a cauzat eroarea și un link special;
cu acel link vă autentificați în modul de recuperare (recovery mode): panoul de control funcționează atunci, cu modulul (pluginul) care a cauzat 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 ați primit niciun e-mail, sau modul de recuperare nu funcționează? Iată cum găsiți singur problema.

1. Verificați jurnalul de erori

Eroarea se află aproape întotdeauna în jurnalul de erori al serverului web sau al PHP. În DirectAdmin îl găsiți la jurnalele (logboeken) domeniului dumneavoastră. Căutați o linie cu PHP Fatal error și ora încercării dumneavoastră:

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

Calea vă spune cine este vinovat: aici modulul (pluginul) din folderul oude-slider. Restul liniei 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, introduceți în wp-config.php (deasupra liniei „stop met bewerken”):

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 afișeze vizitatorilor. Nu lăsați acest lucru activat mai mult decât este necesar: debug.log se află într-un folder pe care serverul web îl oferă, și oricine cunoaște adresa îl poate citi. În el se găsesc căi, uneori nume de utilizator și alte informații care ajută un atacator. Dezactivați-l din nou după ce ați terminat căutarea și ștergeți debug.log. Sau lăsați WordPress să scrie fișierul jurnal în afara folderului web, specificând o cale la WP_DEBUG_LOG (de exemplu '/home/gebruiker/logs/wp-debug.log', dacă furnizorul dumneavoastră de găzduire permite acest lucru). În lecția 7.4 verificați că debug.log nu este public.

3. Dezactivarea unui modul (plugin) fără acces la panoul de control

Dacă nu puteți accesa panoul de control, dezactivați modulul (pluginul) suspect redenumindu-i folderul, prin File Manager sau SFTP:

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

WordPress nu va mai găsi atunci modulul (pluginul) și îl va dezactiva. Dacă nu știți care este, redenumiți întregul folder plugins în plugins-uit: toate modulele (pluginurile) vor fi dezactivate. Dacă site-ul funcționează atunci, creați un folder nou gol plugins, puneți modulele (pluginurile) înapoi unul câte unul și verificați după fiecare dacă eroarea reapare. Pentru o temă este valabil același lucru: redenumiți folderul temei active și WordPress va reveni la o temă implicită, dacă aceasta mai este prezentă (lecția 2.4).

4. Conflicte fără eroare fatală

Nu orice problemă este o eroare critică. Uneori nu funcționează o singură funcție: un buton nu face nimic, formularul nu se trimite, editorul se încarcă pe jumătate. Atunci este adesea un conflict între două module (pluginuri) sau între un modul (plugin) și temă. Pentru asta este util modulul (pluginul) oficial Health Check & Troubleshooting: în modul de depanare (troubleshooting) el dezactivează toate modulele (pluginurile) doar pentru sesiunea dumneavoastră și trece la o temă implicită, în timp ce vizitatorii continuă să vadă site-ul normal. După aceea le activați unul câte unul până reapare problema.

Verificați și consola browserului dumneavoastră (F12): erorile JavaScript menționează adesea fișierul, și astfel și modulul (pluginul).

Sănătate site

Sub Instrumente > Sănătate site, WordPress își verifică singur site-ul: versiune PHP învechită, module (pluginuri) și teme care nu sunt active, extensii PHP lipsă, un REST API care nu funcționează, sarcini programate care au întârziere. În fila Informații se află toate datele instalării dumneavoastră (versiuni, căi, setări PHP). Puteți copia această filă și o puteți trimite atunci când cereți ajutor. Verificați aici după fiecare modificare majoră.

Rezumat

Dezactivarea lasă fișierele pe loc; ștergeți modulele (pluginurile) și temele pe care nu le folosiți.
Faceți curățenie în fiecare trimestru, câte un modul (plugin) pe rând, cu o copie de siguranță sau într-un mediu 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 vinovatului; dezactivați depanarea după ce ați terminat căutarea, deoarece altfel debug.log este public.
Fără acces la panoul de control, dezactivați un modul (plugin) redenumindu-i folderul; conflictele le căutați cu modul de depanare (troubleshooting).

Test

Exercițiu

Exercițiu A5.4: Jurnalul dumneavoastră de depanare (debug log) nu este public? Introduceți adresa site-ului dumneavoastră și demonstrați, cu codul pe care vi-l oferă exercițiul, că este propriul dumneavoastră site (o înregistrare TXT sau un fișier mic). Programul solicită /wp-content/debug.log: este bine dacă acesta nu există sau este refuzat (404 sau 403). Dacă programul primește un fișier înapoi, acest lucru este marcat cu roșu. În plus, programul numără câte foldere diferite de module (pluginuri) apar în codul HTML al paginii dumneavoastră principale (doar ca informație).

Exercițiu D5.4: Faceți ordine în lista dumneavoastră de module (pluginuri). Faceți o listă cu toate modulele (pluginurile) dumneavoastră (active și inactive): nume, pentru ce sunt, dacă mai sunt necesare (da/nu), alternativă fără modul (plugin). Ștergeți (după o copie de siguranță sau într-un mediu de testare/staging) modulele (pluginurile) care nu mai sunt necesare, unul câte unul, și verificați după fiecare ștergere dacă site-ul mai funcționează. Completați câte module (pluginuri) aveați și câte au rămas, și notați dacă au rămas shortcode-uri pe care a trebuit să le curățați.

Exercițiul D5.4: Faceți ordine în lista dumneavoastră de module (pluginuri)

Acest exercițiu îl faceți singur; nimeni nu îl verifică. Bifați ce ați făcut și marcați exercițiul ca finalizat.

Ați făcut mai întâi o copie de siguranță (backup) sau ați lucrat într-un mediu de testare (staging)
Ați șters câte un modul (plugin) pe rând
Ați verificat site-ul după fiecare ștergere
Ați verificat shortcode-urile rămase

Lista dumneavoastră: nume, pentru ce, dacă mai este necesar, alternativă

Câte module (pluginuri) aveați înainte și după?

Bifele și notițele dumneavoastră rămân doar în acest browser; nu le trimitem nicăieri. Dacă sunteți autentificat, păstrăm în Cursurile mele doar faptul că ați finalizat exercițiul.

Lecturi suplimentare

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

Cookie-uri pe WebOké

Setări cookie-uri

Necesare

Marketing