Che nesso c’è tra il volantinaggio e l’orribile messaggio fatal error che compare sul tuo sito wordpress?
Sabato mattina ore 9.30…
pronto per una bella giornata dedicata al giardinaggio. Colazione fatta, secondo caffè E d un piede fuori dalla porta di casa … BANG NOTIFICA.
Ehi Marco, tu te ne intendi di Aruba e WordPress? MI potrest dare una dritta su questo errore che mi compare visitando la home page del mio sito?
Eccoci di fronte ad una classica schermata bianca di wordpress con tanto di Fatal Error ed un errore legato a qualche file .php.
Il cliente aveva appena commissionato la stampa di diversi volantini per la sua attività, che ovviamente rimandavano al suo sito web dedicato, ove coloro che ricevevano il volantino potevano visionare le offerte del mio cliente.
Che fare quindi? Non si può lasciare che un investimento economico in pubblicità vada sperperato. A quel punto è bastato inviarmi l’account Aruba e le credenziali d’accesso al backend di wordpress, per cominciare l’indagine.
Fatal Error e schermata bianca: cause principali di questo errore in WordPress
La schermata Fatal Error può essere causata da diverse cose come per esempio:
- mancanza di qualche file ho directory (p.e missing file or directory)
- impossibilità di aprire qualche file con estensione .php (p.e. cannot able to open fiile)
- raggiunto limite di risorse del server che ospita il tuo sito (p.e. out of memory)
- errata configurazione del server nginx o apache per il tuo sito wordpress (p.e. allowed memory size exhausted)
Fatal Error e schermata bianca: principali soluzioni per riattivare wordpress
In alcuni casi la soluzione al Fatal Error in WordPress può essere abbastanza semplice. Magari te la puoi scampare con:
- aumento dei parametri relativi a php
- un aggiornamento della versione php in uso sul tuo server
- l’aggiornamento del tema grafico che stai usando
- un aggiornamento della versione wordpress
- il ripristino di un backup antecedente alle ultime modifiche
A volte invece è necessario l’occhio di un esperto, in grado di capire l’origine del problema, ma soprattutto di fare le domande giuste al cliente per risolvere il problema velocemente.
La prima cosa che sono andato a verificare è stata la versione di PHP in uso. Se ricordo bene tutto era legato alla versione 5.3 (versione abbandonata nel 2014 per capirci). Non c’era da meravigliarsi che il sito fosse andato in blocco.
Tuttavia l’upgrade alla versione 7 ed 8 non ha portato alcun beneficio, poichè il fatal error rimaneva bello e buono sullo schermo, facendo solo cambiare il dettaglio del messaggio di errore.
A quel punto ho cominciato ad indagare, chiedendo al cliente cosa era stato fatto poco prima che l’errore si presentasse navigando nel sito web. Il cliente mi spiegò di aver provato a cambiare il tema grafico del sito, per dargli una svecchiata dal punto di vista della user experience.
Ascoltando nel dettaglio le operazioni ed i passaggi descritti dal cliente, ebbi un intuizione che mi aiutò a risolvere il caso. fortunatamente ero in grado di accedere al database WordPress gestito con phpmyadmin ed anche al file manager (tramite accesso FTP), da cui era possibile visionare tre cose:
- la versione di wordpress utilizzata per il sito
- l’ultimo tema attivato dalla sezione temi del backend wordpress
- l’elenco dei temi disponibili
- gli ultimi file aggiornati del core di wordpress
Ecco quindi che il quadro cominciava a prendere forma: versione di wordpress stravecchia (versione 3.0.1), tema grafico mai aggiornato e rimasto fermo alla versione del 2014, versione di PHP ante-guerra. Poof, cambiando il tema grafico il tutto non poteva stare in piedi. Sicuramente il nuovo tema grafico non poteva girare su un’infrastruttura così obsoleta, con file realizzati su nuove sintassi, funzioni e variabili di PHP.
A questo punto l’unica soluzione possibile era un rollback del tema grafico. Ma come farlo senza un backup che permetteva di tornare esattamente ad una settimana fa? L’unica strada percorribile era quella di modificare due valori della tabella wp_options ipotizzando quale fosse il tema utilizzato in precedenza (per aiutarmi, ho sfruttato l’accesso ftp andando a guardare il valore ultima modifica delle varie cartelle presenti nella directory themes). un paio di di tentativi ed ecco che il sito è tornato online.
Tutto questo però, al solo fine di riattivare un sito fermo al 2014! Sono sicuro che tutti possano comprendere quanto questo sia poco utile ed anche rischioso in termini di sicurezza (le vecchie versioni sono quelle più vulnerabili ed hanno numerosi problemi di velocità, visualizzazione sui vari device e limitate funzionalità). Ma questa è un’altra storia.
Probabilmente un problema del genere non sarebbe successo con un piano di manutenzione annuale, che prevede un costante aggiornamento di WordPress, ma anche del tema grafico, un monitoraggio ed un upgrade del server ove il sito è ospitato. Tutto si è risolto con l’acquisto di un ticket assistenza, ma i problemi potrebbero essere nuovamente dietro l’angolo.
E’ tu hai una piano annuale per il tuo sito web? Demandi la manutenzione A qualcuno o la esegui in autonomia? Se sei interessato ad un supporto per il tuo sito wordpress, e desideri unassistenza rapida, precisa e professionale, scopri i nostri servizi wordpress qui sotto.
- TICKET SINGOLO ASSISTENZA TECNICA WORDPRESS € 14,90
- PACCHETTO 10 TICKET ASSISTENZA WPRDORESS A € 59,90
- PIANI ASSISTENZA E MANUTENZIONE WORDPRESS a partire da € 19,90 AL MESEr
P.S. Bonus Articolo –> La guida per cambiare il tema grafico da database la trovate a questo link
