Cronaca di un disastro: come sopravvivere alla pagina bianca di WordPress

Questo non è un post adatto per chi si spaventa facilmente. Se siete ansiosi o deboli di cuore fatevi un favore e non continuate a leggere.

Premessa

Quando si verifica un disastro in ambito informatico (e non solo) la cosa più importante è non perdere mai la calma. E poi non bisogna avere fretta di rimettere le cose a posto, meglio riflettere prima di agire. Naturalmente avere un backup aggiornato a disposizione aiuta sempre moltissimo.

Tutte le volte che ho dovuto affrontare un disastro di tipo informatico – e fra casi personali, amici e conoscenti succede relativamente spesso – queste linee guida sono sempre state utilissime per risolvere il problema. L’ultima volta, però, una installazione di WordPress andata completamente in tilt ha messo a durissima prova la mia pazienza, oltre che le mie conoscenze tecniche. Ecco il racconto di quello che è successo.

Una giornata particolare

Oltre a questo blog, amministro da anni Il nostro CNR, un sito finalizzato alla discussione di tematiche relative al mondo del CNR e della ricerca in generale. Come melabit, anche Il nostro CNR è basato su WordPress. Il sito è piuttosto popolare, ha un discreto numero di visualizzazioni giornaliere, purtroppo sono sempre troppo pochi quelli che hanno la voglia e la pazienza di intervenire sul forum. Ma questo è un male tipico degli italiani, bravissimi a discutere animatamente al bar (verba volant…), ma molto meno propensi a mettere per iscritto quello che pensano, magari per paura di ritorsioni (…scripta manent ).

Poco prima di Natale Corrado Zunino, un giornalista di Repubblica sempre molto attento ai problemi della ricerca, pubblica un articolo in cui rivela che la procedura di elezione del rappresentante del personale nel CdA del CNR, conclusa un mese prima, potrebbe essere stata viziata da brogli. Il rappresentante eletto alla tornata precedente era stato una vera e propria spina nel fianco per la dirigenza del CNR e, non pago di quattro anni di fatiche e sacrifici anche personali, aveva deciso di ripresentarsi per un secondo mandato, con ottime possibilità di successo. Toglierlo di mezzo e sostituirlo con qualcuno meno rigido e competente era quasi una necessità.

Subito dopo aver letto l’articolo su Repubblica decido di diffonderlo tramite Il nostro CNR. Del resto, dopo la trasmissione di Report del marzo 2017 che ha rivelato la lunga serie di ruberie avvenute in un istituto del CNR (di certo non l’unico) e ancora di più dopo l’arresto dell’ex-direttore del CNR e dei suoi sodali, nel nostro ente l’interesse per queste vicende ripugnanti è altissimo.

– Fonte: Il Mattino, 20 novembre 2019.

Aggiornamenti inattesi

Entro quindi in quello che è un po’ il retrobottega del sito, la cosiddetta dashboard, l’interfaccia di gestione dei contenuti e delle funzionalità di WordPress, per scrivere un post sulla notizia di Repubblica e come al solito trovo alcuni plugin da aggiornare (i plugin sono dei pezzetti di codice che estendono le funzioni del sito). Succede praticamente ogni volta che accedo alla dashboard, e senza pensarci più di tanto clicco sul pulsante di aggiornamento. È una procedura assolutamente sicura e comunque, anche se uno dei plugin non dovesse più funzionare bloccando il resto del sistema, mi basterebbe modificare i nomi di qualche file per disattivarlo e recuperare la piena operatività del sito.

Questa volta invece, per qualche motivo incomprensibile, insieme all’aggiornamento dei plugin parte anche l’aggiornamento dell’intero codice di WordPress dalla versione 4.x all’ultima versione disponibile, la 5.qualcosa. Aggiornamento che per tanti motivi non volevo ancora fare, e soprattutto che non avrei mai fatto senza prima eseguire un backup affidabile di tutto il sito.

Non riesco ancora a capacitarmi di cosa possa essere successo, ma sono sicuro al 100% di non averlo fatto io stesso per errore. I pulsanti per aggiornare i plugin o il codice di WordPress sono ben distinti e non possono essere premuti contemporaneamente (lo vedete qui sotto), e poi ricordo benissimo di aver letto i messaggi che elencavano i plugin in corso di aggiornamento. Ma, quando alla fine del processo ho cliccato per tornare alla pagina principale, ho visto partire anche l’aggiornamento del codice di WordPress, e a quel punto non potevo più far niente per interromperlo.

È possibile che l’aggiornamento del codice sia partito da solo per qualche baco di Wordpress o di un plugin, del resto i bachi del software sono inevitabili. Una cosa seccante, ma ancora niente di preoccupante.

Un backup è per sempre?

Una volta concluso l’aggiornamento non voluto di WordPress, apro una nuova scheda del browser per controllare cos’è successo al sito. Compare solo una pagina completamente bianca. Il sito in effetti funziona ancora, ma non carica correttamente le pagine, e anche la dashboard appare completamente vuota. Per fortuna i file che costituiscono il sito ci sono ancora tutti, e anche il database usato da WordPress per memorizzare i dati variabili del sito è ancora al suo posto.

Un sito web dinamico come WordPress è costituito in genere da due componenti ben distinte: la prima comprende tutti file che costituiscono il sito web vero e proprio e che vengono modificati di rado, in particolare il codice WordPress e le personalizzazioni dell'utente, i plugin, i temi grafici, le immagini e tutti i documenti collegati alle pagine del sito (questa componente sarà denominata da ora in poi "file del sito" o semplicemente "sito"). La seconda componente è costituita da un database nel quale vengono memorizzati i dati variabili del sito, fra cui i testi degli articoli e degli interventi sul forum, le informazioni relative agli utenti registrati, i dati di accesso e moltissimo altro.

Quando succedono queste cose nel 99% dei casi la colpa è di qualche plugin che funziona male o non funziona affatto. Non c’era del resto da stupirsi, uno dei motivi per decidere di non aggiornare alla versione più recente di WordPress era legato proprio al fatto che almeno due plugin piuttosto importanti non erano ancora stati aggiornati per funzionare con le nuove versioni di WordPress e di PHP, il linguaggio di programmazione per il web con il quale è sviluppato WordPress.

Per correggere il problema della pagina bianca ci sono sostanzialmente due metodi: il primo richiede di disattivare i plugin uno ad uno, fino a scoprire quello che non funziona. Richiede ore ed ore di lavoro certosino e non avrebbe comunque risolto il problema dell’aggiornamento indesiderato del sito. Nonostante tutto, ho provato a disattivare i due, tre plugin più critici ma non cambiava niente.

Il secondo metodo prevede di ripristinare il sito da un backup recente e, in questo caso specifico, ha l’enorme vantaggio di poter tornare alla versione precedente di WordPress. E dato che il provider scelto per ospitare il sito fa un backup ogni ora, mi sembrava più che naturale scegliere la seconda soluzione.

Ed è qui che sono cominciati i guai.

Apro un ticket, cioè una richiesta di supporto tecnico, presso il provider e chiedo come ripristinare il sito da un backup eseguito intorno alle 9 del mattino, ora alla quale ero sicuro di non aver fatto ancora niente. Purtroppo non posso fare da solo, l’assistenza tecnica mi avvisa che la procedura di ripristino del database di WordPress deve essere effettuata dal provider, altrimenti dà errore.

Ovviamente li lascio fare, indicando il backup da ripristinare, il #687 eseguito alle 8:53, e ribadendo che volevo un ripristino totale, pulito, sia del sito che del database su cui si appoggia (la conversazione qui sotto, così come tutte le conversazioni successive, vanno lette dal basso verso l’alto).

Non funziona, anzi è peggio, i file del sito sembrano a posto, ma il database viene ripristinato solo in parte e quindi in pratica non serve a niente.

Intanto mi sono fatto dare l’intero backup del sito e del database delle ore 8:53 in formato standard e in questo backup il database sembra completo. Però ogni volta che l’assistenza tecnica prova a ripristinarlo la procedura fallisce. Secondo loro perché il database è corrotto, secondo me perché la loro procedura di ripristino non funziona bene.

Provo allora a chiedere il ripristino da un backup di un paio di giorni prima, ma non cambia niente. È già passato un giorno, il sito è ancora giù e io faccio una pessima figura con i colleghi che lo frequentano.

Andare sul cloud

A questo punto decido di lasciar perdere l’assistenza tecnica e di fare da solo, usando il backup del sito e del database che mi sono fatto dare per ricostruire il sito da zero. Potrei usare come al solito una macchina virtuale, dove installare una versione server di Linux con tutto quello che serve per far funzionare WordPress, ma questa volta preferisco di andare sul cloud in modo da poter lavorare, se serve (e servirà molto spesso!), anche da casa.

Scelgo AWS Cloud9 di Amazon, funziona bene, costa poco e mi sembra più affidabile di altri servizi che ho usato in passato, come Codeanywhere, Koding o Pilvia, che cambiano continuamente modello di business. Accedo al mio account e creo una nuova istanza di AWS Cloud9, dove installo la versione 18.04/Bionic LTS di Ubuntu Linux.¹

Potrei scegliere anche Amazon Linux, una versione di Linux specifica per Amazon AWS e basata su RedHat e CentOS, ma preferisco andare sul sicuro, in fondo Ubuntu deriva sempre da Debian, e nel mondo Linux non c’è niente di meglio di Debian.

Tralascio i dettagli dell’installazione di tutto quanto serve per far funzionare WordPress su Linux (ma se richiesto potrebbe essere argomento di un prossimo articolo). Il server web Apache, il linguaggio di programmazione PHP e il sistema di database relazionale MariaDB,² sono già installati di default in Ubuntu LTS, si tratta solo di configurare opportunamente tutto per girare su AWS Cloud9 e di creare il database per WordPress. Già che ci sono, installo anche phpMyAdmin, un programma comodissimo che permette di gestire un database MySQL (e quindi anche MariaDB) tramite una interfaccia web.

A questo punto basta scaricare il codice di WordPress ed effettuare la famosa installazione in 5 minuti per essere a posto.

Beh, magari fosse così semplice! Tutto quello che ho in questo momento è un sito funzionante ma vuoto, invece a me serve ripristinare tutto il contenuto de Il nostro CNR.

Per farlo, sostituisco i file del sito e il database di WordPress con quelli contenuti nel backup fornito dal provider. Sembra difficile, ma avendo pieno accesso al terminale di Linux ed essendo l’amministratore onnipotente del sistema su cui gira WordPress diventa un gioco da ragazzi. Riavvio MariaDB ed Apache per fargli rileggere i nuovi dati su cui operare, ma non funziona.

Naturale, il database contiene l’indirizzo web (URL) del sito originale, https://ilnostrcnr.it, ma ora sono su Amazon AWS e l’URL del sito che ho creato è completamente diverso, è qualcosa tipo https://b0ef0914612e145f8fad9237c0dabd8a.vfs.cloud9.us-east-2.amazonaws.com. Non ho intenzione di combattere con i DNS o il file hosts, per cui entro nel database con phpMyAdmin, seleziono la tabella wp_options e sostituisco l’URL originale contenuto nei record siteurl e home con quelli forniti da Amazon AWS.

Riavvio di nuovo MariaDB ed Apache e finalmente il sito torna a vivere. Con phpMyAdmin controllo se il database ha degli errori, e in effetti ci sono, ma niente di così grave che possa impedirne il ripristino (e del resto a me funziona tutto perfettamente).

A questo punto è quasi routine, ed è anche l’occasione per dare una bella rinfrescata alle funzionalità del sito. Entro nella dashboard e rimuovo il plugin All-in-One WP Migration, che usavo per fare i backup personali del sito ma che che non è compatibile con le ultime versioni di PHP 7.x, e cancello dal terminale la directory relativa. Rimuovo anche il plugin Count per Day, ottimo per analizzare le statistiche di accesso al sito ma che non è aggiornato da un anno e non è stato testato con le versioni più recenti di WordPress. E dato che ha violato le linee guida di WordPress è stato pure rimosso dall’archivio (repository) ufficiale dei plugin di WordPress.

Controllo di nuovo il database usando sia una funzione seminascosta di WordPress³ che il solito phpMyAdmin ed ora è tutto a posto, dopo la rimozione dei due plugin problematici anche gli errori del database sono scomparsi.

Ritorno al provider

A questo punto mi rimane solo da fare un backup del sito e del database, che il provider potrà usare (o meglio “dovrà usare”, visto che finora non ha fatto niente di significativo) per ripristinare il sito originale.

Ma la cosa si rivela più difficile del previsto e l’interazione fra il supporto tecnico e me sembra un dialogo fra sordi,

che sfocia rapidamente nella incomunicabilità totale. Il sito è giù da ben 11 giorni ma al servizio tecnico importa pochissimo. Inutile provare ancora a ricevere un supporto degno di questo nome.

Prima di tagliare i ponti con il servizio tecnico ho preparato un Piano B. Ore di ricerche sul web mi hanno fatto trovare Duplicator, un plugin che sembra perfetto per le mie esigenze. In apparenza è uno dei soliti plugin di backup/ripristino di una installazione di WordPress, che alla fine richiedono sempre l’acquisto della versione Pro per essere davvero utili. Duplicator invece è diverso, la versione Pro aggiunge delle funzioni molto interessanti per chi gestisce dei siti web per professione, ma la versione base gratuita fa tutto quello che mi serve, è solo leggermente più complicata da utilizzare.

In previsione del piano B ho già provato a fondo Duplicator, usandolo per fare un backup completo del sito e per ripristinarlo in una nuova istanza di AWS Cloud9, e funziona in modo spettacolare. Mi piace soprattutto il fatto che lavori a bassissimo livello, sembra quasi di usare il terminale, che è poi quello che farei io stesso se il provider mi concedesse un accesso pieno e senza limitazioni via ssh al mio sito e soprattutto al database associato.

Entro quindi nel pannello di controllo del mio sito web e di tutti i tool collegati, il notissimo cPanel, cancello tutti i file del sito e anche il database che ha creato tanti problemi, e già che ci sono aggiorno PHP alla versione 7.2, la stessa versione disponibile in AWS Cloud9. Mi tremano un po’ i polsi, da ora in poi se sbaglio non posso più tornare indietro, ma ho delle alternative migliori?

A differenza degli altri plugin di backup/ripristino che conosco, Duplicator non ha bisogno di una installazione preesistente di WordPress per funzionare, ma insieme al backup del sito genera un programma in PHP che effettua da solo il processo di ripristino del sito e del database associato. Anche l’URL che ho modificato a mano diretatmente nel database vengono aggiornati correttamente. Bastano pochi minuti e il sito torna a vivere.

È il 2 gennaio, sono passati ben 14 giorni dal disastro.

Conclusioni

Quando dicevo all’inizio che la lettura di questo articolo non è adatta a chi si spaventa facilmente o è ansioso, stavo scherzando, ma non troppo. Questa esperienza ha davvero messo a dura prova le mie capacità tecniche, nonché la mia pazienza nell’interagire con chi dovrebbe fornire un supporto tecnico decente.

Ma dopo un paio di giorni era diventata una sfida personale, una specie di esame fuori tempo massimo, sei capace di risolvere questo problema difficile? E poi, naturalmente, c’era la necessità di non fare brutta figura con tanti colleghi…

Ovvio che alla scadenza del contratto bisognerà cambiare provider, tutto sommato questo finora non è stato male, ma finché va tutto bene sono buoni tutti, le differenze si vedono solo quando il gioco si fa duro. Avevo già pensato di farlo per altri motivi, ma il dover traslocare il sito su un’altro spazio web mi preoccupava un po’. Ora, con l’esperienza che mi sono fatta, sarà uno scherzetto.

1. A differenza delle versioni normali di Ubuntu Linux, che vengono rilasciate ogni sei mesi, le versioni LTS, Long Term Support, vengono rilasciate solo nella primavera degli anni pari e sono particolarmente indicate per un sistema server. ↩

2. MariaDB è un derivato (fork) del notissimo database MySQL, prodotto dagli sviluppatori originali di MySQL e compatibile praticamente al 100% con la versione corrispondente di MySQL. L’origine del fork sta nell’introduzione da parte di Oracle, che nel 2010 ha acquisito la ormai decaduta Sun Microsystems con tutto il suo parco software fra cui Java e proprio MySQL, di estensioni proprietarie disponibili solo per la versione a pagamento di MySQL. ↩

3. Bisogna aggiungere nel file wp-config.php la riga define('WP_ALLOW_REPAIR', true);, andare all’URL di amministrazione YOURSITE.com/wp-admin/maint/repair.php (dove YOURSITE.com deve essere sostituito con l’indirizzo web del sito) e seguire le istruzioni. ↩