Attendi ...

Aggiornare WordPress manualmente

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.

02.02.2012

Ti potrebbero interessare

Disaster Recovery draas - Normativa NIS2

Disaster Recovery as a Service (DRaaS): La Nuova Frontiera della Business Continuity sotto la Direttiva NIS2

Nel 2026, la sicurezza informatica non è più un tema relegato esclusivamente alle sale server. È diventata una questione di governance, responsabilità legale e sopravvivenza sul mercato. Mentre molte aziende italiane si concentrano sulla difesa perimetrale per evitare intrusioni, spesso trascurano la domanda ...

13.05.2026
Dettagli

Sicurezza Avanzata WordPress

Il tuo sito WordPress potrebbe essere vulnerabile. Anche se “sembra funzionare perfettamente”.

Molti attacchi non danno segnali immediati: lavorano in background, sfruttano vulnerabilità e colpiscono quando meno te lo aspetti.

La sicurezza non è qualcosa da sistemare dopo. È qualcosa da progettare prima.

Perché la sicurezza WordPress ...
13.04.2026
Dettagli

Cloud Privato Ansible Automazione IAC

Nel panorama IT moderno, la gestione manuale dei server non è più solo un’inefficienza: è un rischio sistemico. Configurare istanze via SSH una alla volta, installare pacchetti manualmente e gestire le patch "a memoria" espone l’azienda al Configuration Drift: quella divergenza silenziosa tra i server che rende le infrastrutture fragili, insicure e impossibili da scalare.

In Aziende Italia, promuoviamo ...

24.03.2026
Dettagli