Modulo 5 · 5.4
Meno è meglio: fare pulizia e risolvere i conflitti
Modulo 5: Temi e plugin · Tempo di lettura: 9 minuti
Obiettivo: Dopo questa lezione sarà in grado di fare pulizia tra i plugin e di individuare e risolvere da solo un conflitto o una pagina bianca.
Concetti chiave: disattivare e eliminare, codice inattivo, errore critico, modalità di ripristino (recovery mode), Salute del sito, modalità di risoluzione dei problemi, rinominare la cartella del plugin, WP_DEBUG, WP_DEBUG_LOG, debug.log, log degli errori
Disattivare non significa buttare via
In Plugin può disattivare o eliminare un plugin. La differenza:
- Disattiva: WordPress non carica più il plugin. I file però restano in
wp-content/plugins/e spesso sono ancora raggiungibili direttamente tramite il server web. Se un singolo file PHP di quel plugin contiene una vulnerabilità, quella vulnerabilità esiste ancora. Gli attaccanti cercano file vulnerabili noti, non plugin attivi. - Elimina: i file vengono rimossi. Alcuni plugin, al momento dell'eliminazione, ripuliscono anche le proprie impostazioni e tabelle nel database; altri le lasciano.
Se non usa più un plugin, lo elimini. Disattivarlo serve solo per poco tempo (durante la ricerca di un problema). Lo stesso vale per i temi (lezione 2.4).
Fare pulizia: un controllo fisso
Una volta a trimestre (lezione 9.4) passi in rassegna i Suoi plugin. Per ogni plugin:
- A cosa serve? Se non lo ricorda più, lo verifichi. Spesso si scopre che un plugin è stato installato per una sola cosa e mai rimosso.
- È ancora in uso? Un plugin slider mentre da nessuna parte c'è uno slider, un plugin per moduli mentre la pagina dei contatti usa un altro modulo.
- Se ne può fare a meno? WordPress, il tema o un altro plugin lo sanno già fare (lezione 5.3)?
- È ancora mantenuto? Quando è stato aggiornato l'ultima volta, è ancora presente nella directory dei plugin?
Faccia pulizia prima in un sito di staging (lezione 8.3), o almeno crei un backup, ed elimini un plugin alla volta, così saprà cosa è andato storto se qualcosa va storto. Attenzione agli shortcode: se elimina un plugin che forniva [formulier id="2"], quel testo comparirà poi letteralmente sulla Sua pagina.
Quando qualcosa va storto: l'errore critico
Dopo un aggiornamento, un nuovo plugin o un aggiornamento di PHP vede all'improvviso:
C'è stato un errore critico su questo sito web.oppure una pagina completamente bianca. Significa che PHP si è fermato con un errore fatale prima che ci fosse una pagina (lezione 1.2). Di solito la causa è un plugin o un tema che non è compatibile con qualcos'altro: un altro plugin, la nuova versione di WordPress o la versione di PHP.
Da WordPress 5.2, in questo caso WordPress fa due cose:
- invia un'email all'indirizzo dell'amministratore indicando quale plugin o tema ha causato l'errore, con un link speciale;
- con quel link accede alla modalità di ripristino (recovery mode): l'area di amministrazione funziona, con il plugin che ha causato l'errore temporaneamente disattivato, così può aggiornarlo, sostituirlo o eliminarlo.
Per questo è così importante un indirizzo dell'amministratore che Lei legge davvero (lezione 2.2).
Cercare da soli: i passaggi
Non arriva nessuna email, oppure la modalità di ripristino non funziona? Ecco come trovare la causa da solo.
1. Consulti il log degli errori
L'errore si trova quasi sempre nel log degli errori del server web o di PHP. In DirectAdmin lo trova tra i log del Suo dominio. Cerchi una riga con PHP Fatal error e l'orario del Suo tentativo:
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:42Il percorso Le dice chi è il colpevole: qui il plugin nella cartella oude-slider. Il resto della riga spiega il perché (qui: una funzione rimossa in PHP 8, lezione 8.4).
2. Attivi il debug log (non la visualizzazione a schermo)
Se nel log degli errori non c'è nulla di utile, inserisca in wp-config.php (sopra "Finito, interrompere le modifiche!"):
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );WordPress scriverà così tutti gli errori in wp-content/debug.log, senza mostrarli ai visitatori. Non lo lasci mai attivo più del necessario: debug.log si trova in una cartella servita dal server web e chiunque conosca l'indirizzo può leggerlo. Contiene percorsi, a volte nomi utente e altre informazioni utili a un attaccante. Al termine della ricerca lo disattivi di nuovo ed elimini debug.log. In alternativa, faccia scrivere a WordPress il file di log fuori dalla cartella web indicando un percorso in WP_DEBUG_LOG (ad esempio '/home/gebruiker/logs/wp-debug.log', se il Suo provider di hosting lo consente). Nella lezione 7.4 verificherà che debug.log non sia pubblico.
3. Disattivare un plugin senza l'area di amministrazione
Se non riesce ad accedere all'area di amministrazione, disattivi il plugin sospetto rinominando la sua cartella, tramite Gestione file o SFTP:
wp-content/plugins/oude-slider diventa wp-content/plugins/oude-slider-uitWordPress non trova più il plugin e lo disattiva. Se non sa quale sia, rinomini l'intera cartella plugins in plugins-uit: tutti i plugin vengono disattivati. Se il sito web funziona, crei una nuova cartella vuota plugins, rimetta i plugin uno alla volta e controlli dopo ciascuno se l'errore ricompare. Per un tema vale lo stesso: rinomini la cartella del tema attivo e WordPress tornerà a un tema predefinito, se è ancora presente (lezione 2.4).
4. Conflitti senza errore fatale
Non ogni problema è un errore critico. A volte una sola funzione non va: un pulsante non fa nulla, il modulo non viene inviato, l'editor si carica a metà. Spesso si tratta allora di un conflitto tra due plugin o tra un plugin e il tema. Per questo è utile il plugin ufficiale Health Check & Troubleshooting: nella modalità di risoluzione dei problemi disattiva tutti i plugin e passa a un tema predefinito solo per la Sua sessione, mentre i visitatori continuano a vedere il sito web normale. Poi li riattiva uno alla volta finché il problema non ricompare.
Controlli anche la console del Suo browser (F12): gli errori JavaScript indicano spesso il file e quindi il plugin.
Salute del sito
In Strumenti > Salute del sito WordPress controlla da solo il Suo sito web: versione di PHP obsoleta, plugin e temi non attivi, estensioni PHP mancanti, una REST API che non funziona, attività pianificate in ritardo. Nella scheda Informazioni trova tutti i dati della Sua installazione (versioni, percorsi, impostazioni PHP). Può copiare questa scheda e allegarla quando chiede aiuto. Ci dia un'occhiata dopo ogni modifica importante.
Riepilogo
- Disattivare lascia i file al loro posto; elimini i plugin e i temi che non usa.
- Faccia pulizia ogni trimestre, un plugin alla volta, con un backup o in un sito di staging.
- In caso di errore critico WordPress invia un'email con un link alla modalità di ripristino.
- Il log degli errori o
debug.logindica il percorso del colpevole; disattivi il debug al termine della ricerca, altrimentidebug.logresta pubblico. - Senza area di amministrazione disattiva un plugin rinominando la sua cartella; i conflitti si cercano con la modalità di risoluzione dei problemi.
Quiz
Esercizio
Esercizio A5.4: Il Suo debug log non è pubblico? Inserisca l'indirizzo del Suo sito web e dimostri con il codice fornito dall'esercizio che il sito è Suo (un record TXT o un piccolo file). Il programma richiede /wp-content/debug.log: il risultato è corretto se il file non esiste o l'accesso viene negato (404 o 403). Se il programma riceve un file, il risultato è rosso. Inoltre il programma conta quante cartelle di plugin diverse compaiono nell'HTML della Sua homepage (solo a titolo informativo).
Esercizio D5.4: Mettere in ordine l'elenco dei plugin. Prepari un elenco di tutti i Suoi plugin (attivi e inattivi): nome, a cosa serve, ancora necessario (sì/no), alternativa senza plugin. Elimini (dopo un backup o in un sito di staging) i plugin non più necessari, uno alla volta, e controlli dopo ogni eliminazione che il sito web funzioni ancora. Indichi quanti plugin aveva e quanti ne sono rimasti, e annoti se sono rimasti shortcode che ha dovuto ripulire.
Esercizio D5.4: Mettere in ordine l'elenco dei plugin
Questo esercizio lo svolge da sé; nessuno lo verifica. Spunti ciò che ha fatto e segni l'esercizio come completato.
Il numero dopo è inferiore o uguale, e per ogni plugin rimasto c'è un motivo. I plugin inattivi vanno rimossi: anche il codice disattivato può contenere una falla.
Le Sue spunte e note restano solo in questo browser; non le inviamo da nessuna parte. Se ha effettuato l'accesso, conserviamo in I miei corsi solo il fatto che ha svolto l'esercizio.
Per approfondire
Questi articoli descrivono i passaggi nei pannelli di WebOké; in altri pannelli funzionano in modo simile.
- Guida DirectAdmin 18.1: Il mio sito web è bianco o restituisce un errore 500
- Errore 500 o "errore critico" sul Suo sito web (anche dopo un aggiornamento di WordPress)
- Guida DirectAdmin 14.6: Errori dopo un aggiornamento di PHP e come trovare il log degli errori
- Guida DirectAdmin 17.2: Riepilogo sito e log: il log degli errori e il log degli accessi
- Come posso eseguire il debug di PHP senza modificare il php.ini?
- Debug in WordPress (developer.wordpress.org, Inglese): https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
- Scegliere, valutare e ripulire i plugin di WordPress
