L'aggiornamento di WordPress (WP) è semplice e lineare finché lavoriamo in locale: basta seguire la procedura d'aggiornamento e tutto dovrebbe filare liscio. L'operazione è più delicata se lavoriamo su un server remoto, ad esempio offerto in hosting. In tal caso il buon esisto della procedura di aggiornamento può dipendere dalla politica di chi offre il servizio di hosting. Questo articolo introduce e risolve alcuni dei possibili problemi dell'aggiornamento di WP in remoto, in particolare quelli relativi all'aggiornamento del database.

Per svariati motivi, sia tecnici che commerciali, alcuni provider offrono l'installazione di WP “inscatolata” nel pacchetto di hosting. L'utente non deve usare un client FTP per installare WP, né configurare il file wp-config.php: è sufficiente cliccare su un bottone e WP appare “magicamente” sul nostro sito. Questo tipo di installazione può però differire da quella standard di WP, e in tal caso la procedura di aggiornamento rischia di fare acqua da qualche parte.

Consideriamo ad esempio le tabelle di WP presenti nel database

wp_commentsmeta, wp_comments, wp_links ecc...

alcuni provider decidono di “personalizzare” queste tabelle, aggiungendo un prefisso davanti al nome. Il provider Tizio Caio (tc) potrebbe per esempio usare un'installazione di WP che si appoggia sulle seguenti tabelle

tc_wp_commentsmeta, tc_wp_comments, tc_wp_links ecc...

Queste tabelle hanno esattamente la stessa funzione di quelle originali, e dovrebbero contenere gli stessi dati: l'unica differenza è il nome della tabella.

Cosa succederà quando seguiamo la procedura di aggiornamento standard? Le nostre pagine PHP verranno aggiornate correttamente, i temi e gli stili che abbiamo personalizzato resteranno (giustamente) immutati, ma al momento di effettuare il login, invece di trovarci davanti una pagina che suggerisce di aggiornare il database, potremmo trovare la pagina di setup di una nuova installazione di WordPress! Ciò accade se aggiornando WP abbiamo sovrascritto la configurazione che si appoggiava sulle tabelle del tipo tc_xxx_yyy, e le nuove pagine non trovano le tabelle attese. Ecco perché il nuovo WP aggiornato crederà di lavorare su un database “vuoto”, e tenterà correttamente di creare la base dati necessaria.

La situazione non è grave come sembra. La soluzione più semplice è cambiare i prefissi delle tabelle direttamente nel file di configurazione di WP, cambiando il parametro table_prefix del file wp-config.php. In altre parole dobbiamo ripristinare la configurazione precedente, che abbiamo "rotto" per sbaglio. Questo risolve il problema solo se il database non è cambiato troppo da una versione all'altra. Se cambiare il prefisso non ripristina il nostro WordPress, l'alternativa è tentare di recuperare “manualmente” almeno le parti più importanti del nostro blog: i post e i relativi commenti. Vediamo come.

  1. Continuare l'installazione come se stessimo installato WP per la prima volta
  2. Collegarsi al database, ad esempio usando phpMyAdmin
  3. Fare un backup del database (se non l'abbiamo già fatto)
  4. Cancellare i record che WP ha inserito a titolo di esempio, quali “Hello World” o simili

Questo può essere fatto selezionando la tabella dall'interfaccia di phpMyAdmin e cliccando su Svuota.

Svuotare una tabella con phpMyAdmin

Svuotare una tabella con phpMyAdmin

L'effetto è quello di eseguire un comando del tipo

TRUNCATE TABLE `articles`

  1. Copiare i nostri “vecchi” record dal “vecchio” database al nuovo. Clicchiamo sul tab SQL e digitiamo una query come la seguente

INSERT INTO wp_terms (`term_id`,`name`,`slug`,`term_group` ) SELECT * FROM tc_wp_terms

il modo più semplice di inserire i nomi delle colonne (quelli tra parentesi qui sopra) è selezionarli nel riquadro di destra e poi cliccare sul pulsante “<<” (Inserisci).

I passi 4 e 5 andrebbero eseguiti per le tabelle

wp_posts, wp_comments, wp_terms

ma andrebbero evitati per le tabelle

wp_commentmeta, wp_postmeta, wp_options, wp_usermeta,

wp_users, wp_links, wp_options

Le tabelle qui sopra contengono spesso dati necessari alla nuova versione di WP ma assenti nelle versioni precedenti, per cui è troppo rischioso cancellare tutti i dati nuovi per importare alcuni dei vecchi dati: si rischia di compromettere il funzionamento della nuova installazione. Molto meglio dover re-inserire la vecchia configurazione manualmente, agendo sui pannelli di amministrazione di WP. Il discorso è più difficile per quanto riguarda le tabelle

wp_term_relationships e avwp_term_taxonomy

perché il significato dei dati contenuti in queste tabelle non è facilmente comprensibile dall'utente, per cui non è possibile essere sicuri di quello che si sta facendo. Se vogliamo recuperare anche i dati di queste tabelle, è necessario leggere accuratamente la documentazione tecnica di WP.

La procedura vista qui sopra non recupera tutti i dati della vecchia installazione: è necessario fare un giro dei pannelli di amministrazione di WP e controllare che sia tutto a posto. Ma dovrebbe metterci in grado di recuperare almeno “l'anima” del nostro blog, che è sicuramente la parte più importante.