Quando si lavora con WordPress, backup e migrazioni da un server all’altro, prima o poi può capitare di imbattersi in una parola che sembra molto più complicata di quello che è:
collation
oppure, in italiano, collazione.
Recentemente mi è capitato proprio durante una migrazione eseguita con Akeeba Backup.
Il sito funzionava regolarmente sul server locale, il backup veniva creato senza problemi, ma al momento del ripristino sul server pubblico comparivano errori legati al database.
La causa non era WordPress.
Non era Akeeba.
Il problema era che alcune tabelle utilizzavano collazioni diverse o non perfettamente compatibili con il server di destinazione.
Da qui è nata l’idea di questo articolo.
Cerchiamo quindi di capire cosa sono charset e collazioni senza entrare subito in spiegazioni troppo tecniche.
Partiamo dal principio: un database deve sapere come leggere il testo
Un database non vede le lettere come le vediamo noi.
Per lui un testo è una sequenza di valori che devono essere interpretati secondo determinate regole.
Quando salviamo una parola come:
caffè
oppure:
perché
oppure ancora:
€
il database deve sapere come rappresentare quei caratteri.
Ed è qui che entra in gioco il set di caratteri, chiamato normalmente charset.
Il charset dice quali caratteri possiamo memorizzare
Possiamo immaginare il charset come un grande alfabeto disponibile per il database.
Un vecchio set di caratteri può conoscere soltanto un numero limitato di simboli.
Uno più moderno può gestire correttamente molte più lingue, simboli e caratteri.
Oggi, nel mondo WordPress e MySQL, incontriamo spesso charset appartenenti alla famiglia UTF-8.
Uno dei più utilizzati è:
utf8mb4
La sua funzione è permettere al database di memorizzare un insieme molto ampio di caratteri Unicode.
In pratica è quello che ci consente di gestire correttamente non soltanto lettere accentate, ma anche moltissimi simboli e caratteri appartenenti ad alfabeti diversi.
E allora che cos’è la collazione?
Qui arriva il punto interessante.
Il charset dice quali caratteri esistono.
La collazione stabilisce invece come quei caratteri devono essere confrontati e ordinati.
Facciamo un esempio molto semplice.
Supponiamo di avere queste parole:
Una collazione può decidere che maiuscole e minuscole debbano essere considerate equivalenti.
Un’altra può trattarle come diverse.
La stessa cosa può succedere con gli accenti.
Quindi la collazione stabilisce regole del tipo:
Questa è, in sostanza, la collazione.
Charset e collazione non sono la stessa cosa
È una distinzione importante.
Possiamo avere lo stesso charset ma collazioni differenti.
Per esempio possiamo trovare tabelle che utilizzano tutte utf8mb4, ma con regole di confronto diverse.
Quindi possiamo immaginare la situazione così:
Charset = quali caratteri posso usare
Collation = come confronto e ordino quei caratteri
È un modo semplificato di dirlo, ma rende abbastanza bene l’idea.
Perché normalmente non ce ne accorgiamo?
Nella maggior parte dei siti WordPress non dobbiamo mai pensare alle collazioni.
Installiamo WordPress.
Creiamo articoli.
Installiamo plugin.
Aggiorniamo il sito.
E tutto funziona.
Il problema tende a comparire quando il database viene spostato da un ambiente all’altro.
Per esempio:
Ed è esattamente qui che una migrazione può mettere in evidenza differenze rimaste nascoste per anni.
Come fanno a nascere collazioni diverse nello stesso database?
Un database WordPress non nasce necessariamente tutto nello stesso momento.
Una tabella può essere stata creata dieci anni fa.
Un plugin installato oggi può crearne altre cinque.
Un altro plugin può essere stato sviluppato con impostazioni diverse.
Una migrazione precedente può aver importato tabelle provenienti da un altro server.
Nel tempo possiamo quindi ritrovarci con un database nel quale esistono:
Finché tutto rimane nello stesso ambiente, magari non succede nulla.
Quando esportiamo e ripristiniamo il database altrove, invece, le differenze possono emergere.
Dove entra in gioco Akeeba Backup?
Akeeba Backup è uno strumento molto comodo perché ci permette di trasferire praticamente l’intero sito:
Quando il backup viene ripristinato, il database deve essere ricreato sul nuovo server.
Se il server di destinazione non supporta una determinata collazione oppure interpreta alcune impostazioni in modo differente, il ripristino può fermarsi con un errore.
Akeeba, in quel caso, non è necessariamente il responsabile.
Sta semplicemente tentando di ricreare quello che era presente nel database originale.
Un esempio pratico
Immaginiamo di avere cinquanta tabelle WordPress.
Quarantacinque utilizzano una certa collazione.
Le altre cinque ne utilizzano un’altra.
Sul server locale funzionano tutte.
Creiamo il backup.
Lo portiamo su un hosting diverso.
Durante il ripristino, il nuovo server incontra una collazione che non gestisce come previsto.
A quel punto l’installazione può interrompersi.
Da fuori sembra quasi che il backup sia corrotto.
In realtà i dati possono essere perfettamente integri.
È semplicemente comparsa un’incompatibilità tra i due ambienti.
È qui che può essere utile uniformare il database
Nel mio caso ho preferito intervenire prima di creare il backup definitivo.
Sul server locale ho utilizzato una piccola utility che avevo realizzato proprio per controllare il database.
Il programma analizza le tabelle e permette di uniformare charset e collazioni prima della migrazione.
L’idea è molto semplice:
In questo modo il database parte già in uno stato più coerente.
Perché non conviene modificare le collazioni a caso
Qui però bisogna fare attenzione.
Il fatto che sia possibile cambiare collazione non significa che dobbiamo aprire phpMyAdmin e iniziare a modificarle senza criterio.
Prima di qualsiasi intervento sul database bisogna avere un backup.
Sempre.
Una modifica sbagliata può creare problemi con:
Quindi il principio non deve essere:
vedo collazioni diverse e le cambio tutte
Deve essere:
controllo la situazione, verifico la compatibilità e intervengo solo se serve
Il backup prima di tutto
La procedura che preferisco è questa:
Così, se qualcosa non va, possiamo sempre tornare indietro.
Ma quale collazione bisogna scegliere?
Non esiste una risposta unica valida per qualsiasi server e qualsiasi progetto.
Dipende da:
L’obiettivo non è inseguire il nome più moderno disponibile.
L’obiettivo è utilizzare una configurazione coerente e compatibile con l’ambiente nel quale il sito deve funzionare.
Una cosa importante: “utf8” non significa sempre ciò che immaginiamo
Chi entra per la prima volta in MySQL può pensare:
Se leggo UTF-8, allora è tutto uguale.
Non è proprio così.
Nel mondo MySQL esistono differenze tra charset e collazioni che possono sembrare molto simili nel nome ma avere comportamenti differenti.
Per questo conviene trattare il database come una parte tecnica del sito e non come una semplice raccolta di file.
Perché questa conoscenza è utile anche se non siamo programmatori
Non serve diventare amministratori MySQL per capire il concetto.
Secondo me basta ricordare tre cose.
Già sapere questo permette di leggere con occhi diversi molti errori apparentemente incomprensibili.
Se Akeeba dà errore, quindi, non accusiamo subito Akeeba
Questo è probabilmente il punto che mi interessa di più lasciare con questo articolo.
Quando un ripristino fallisce, è normale pensare immediatamente:
il backup non funziona
Ma non sempre è così.
Il backup può aver fotografato perfettamente il database originale.
È il server nuovo che potrebbe non riuscire a ricostruirlo esattamente nello stesso modo.
E una collazione incompatibile è uno dei possibili motivi.
Il vantaggio di sistemare tutto sul server locale
Se abbiamo un ambiente locale di sviluppo, questo diventa estremamente utile.
Possiamo:
È esattamente il motivo per cui preferisco sistemare questi problemi prima della pubblicazione definitiva.
Conclusione
Le collazioni di un database possono sembrare una di quelle cose riservate agli amministratori di sistema.
In realtà il concetto di base è abbastanza semplice.
Il charset stabilisce quali caratteri possiamo memorizzare.
La collazione stabilisce come quei caratteri vengono confrontati e ordinati.
Durante la vita normale di un sito WordPress possiamo anche non accorgerci mai della loro esistenza.
Ma quando spostiamo il sito da un server all’altro, soprattutto tra ambienti con versioni o configurazioni differenti, possono diventare improvvisamente importanti.
Nel mio caso è bastato uniformare il database sul server locale prima di creare il nuovo backup Akeeba.
Una piccola correzione che ha trasformato un ripristino problematico in una migrazione riuscita.
Ed è proprio per questo che, quando una migrazione WordPress si blocca sul database, vale la pena dare un’occhiata anche a charset e collazioni prima di pensare che il backup sia da buttare.
© COSTNET – Condividi liberamente il link, ma non copiare il contenuto senza autorizzazione.
