E' fortemente sconsigliabile migrare un sito in produzione senza prima verificare i possibili problemi. Come passo iniziale è bene aggiornare una copia del sito. Le operazioni che verranno descritte sono prima state provate in un ambiente di test, più di una volta, per verificare eventuali varianti e difficoltà.

Questo sito è ospitato in hosting su Aruba. Fatta una copia del file system e del DB, è stato portato su un host locale, un ambiente Suse SLES [8]. Nessuna preferenza in merito, SLES era disponibile ed è stato usato. Sono state necessarie solo alcune piccole modifiche dei files .htaccess e, naturalmente, del file di configurazione del DB: settings.php.

Le raccomandazioni di provvedere a copie di backup, per quanto banali, sono dovute. Sarà utile rifare la copia in fasi intermedie, specie per il DB, per consentire di ripristinare un punto senza iniziare di nuovo la migrazione.

In realtà, il mio sito originale non è stato migrato, è ancora vivo qui: www.rfc.it/drupal [9]. Con comodo verrà eliminato. Di fatto ho copiato il sito in una nuova cartella, migrata la copia e messa on-line giocando con le impostazioni di redirect di .htaccess.

Per il backup del sito, i metodi usati sono quelli classici descritti in vari documenti https://drupal.org/node/22281 [11]. Ci sono moduli che agevolano il backup, ma io abitualmente copio la cartella che contiene il sito e salvo il DB attraverso phpMyAdmin. Come già accennato, sarà bene ripetere l'operazione in punti intermedi del processo, per consentire un ripristino parziale a fronte di test od operazioni errate.

Occorre aggiornare (update) il core di Drupal 6, i moduli e i temi alle ultime versioni disponibili. Questa operazione è consigliata perché le procedure di upgrade fanno normalmente riferimento alle ultime release ed eventulamente contengono correzioni che agevolano la migrazione.

Questa operazione si presta  anche per rivedere i moduli, disinstallare ed eliminare quelli inutilizzati, che spesso sono stati scaricati, ma di fatto non utilizzati. I moduli inutilizzati vanno anche eliminati  da /sites/all/modules.

I moduli in uso vanno lasciati, anche quando non è possibile aggiornarli con una nuova versione per D7, per mantenere tabelle e informazioni per eventuali procedure di aggiornamento,  come si vedrà per nodewords e image.

Per la migrazione, il sito deve essere in modalità manutenzione e l’utente utilizzato deve avere user ID 1, il primo utente creato durante l’installazione del sito.

Il tema da utilizzare è Garlan, che è quello di default presente nel core di Drupal. Anche un eventuale tema di manutenzione deve essere portato a Garland.

Suggerisco anche di passare alla lingua inglese perché la documentazione, le voci dei menu, i messaggi ed altro sono per lo più in inglese, quindi viene più semplice seguire guide e suggerimenti.

Cancellazione di tutte le cache e preferiblmente disabilitarle. Le tabelle di cache hanno a volte discrete dimensioni, che penalizzano le operazioni di salvataggio e ripristino del DB.
A questo punto il sito è ‘pulito’ e pronto all’upgrade, quindi suggerisco un nuovo backup del file system e del DB.

Nel sito che ho migrato si trascinava fin dalla sua realizzazione, 2009, dei percorsi a link e a immagini non opportuni, sbagliati.
Il sito è in una cartella di nome drupal nella root dello spazio Aruba. In molti link è riportata questa cartella, ad esempio /drupal/sites/all …. Inoltre nell'URL e link la cartella drupal era sempre presente. Non è una buona pratica, meglio un nome specifico, l'ho scoperto a mie spese. Successivamente è stato utilizzato il redirect da .htaccess per puntare alla cartella del sito, ma i vecchi link sono rimasti. Cambiarli uno per uno, manualmente è improponibile. Per risolvere il problema avrei potuto modificare le tabelle del DB via SQL e cambiare in massa i link /drupal/….
Ho preferito esportare il DB (non troppo grande, nel mio caso) in formato testo e, con un editor di testo, sostituire ‘/drupal/’ con ‘/’.  Ho poi  importato il DB modificato. Lo stratagemma ha funzionato a dovere. Certamente con il linguaggio SQL si può fare altrettanto e in modo più elegante.

Infine è bene attivare la varibile $base_url nel file di configurazione settings.php per far sparire la cartella di installazione da URL e link.

Se nella prima installazione non si è provveduto a fornire un prefisso alle tabelle del DB, cosa non indispensabile ma utile e comoda, si può provvedere rinominando le tabelle [15] e dando il corretto valore alla variabile $db_prefix nel file di configurazione settings.php.

Non tutti i moduli presenti in D6 sono disponibili in D7 e alcuni moduli di D6 sono stati integrati nel core di D7, è il caso del modulo image, integrato nel core.

Bisogna verificare quali moduli possono essere migrati e quali no. Questo influenza anche la decisione sull’opportunità di migrare.

Per la verifica dei moduli, molto comodo è il modulo upgrade_status https://drupal.org/project/upgrade_status [17] che fa un report sulla situazione dei moduli in D6 e dei corrispettivi D7. Suggerisco di stamparsi il report e annotare quali operazioni future si intende adottare (quali aggiornabili e quali no, come sostituire quelli non disponibili in D7, ecc.).

Con upgrade status viene reso dieponibile anche upgrade assist (che è bene abilitare). Upgrade assist rende disponibile un menu per la facile guida nei vari passi.

Nel mio sito utilizzavo il modulo image, che in Drupal 7 è stato eliminato e integrato nel core. Usavo anche Image Gallery che non è più disponibile in D7 e si serve della tassonomia per raggruppare le immagini in un determinato insieme.

Nella migrazione i termini di tassonomia rimangono, ma non sono correttamente correlati al contenuto tipo image, perché image sparisce. Non è quindi possibile gestire correttamente, in D7, tali termini di tassonomia che prenderanno il nome di “Taxonomy Upgrade Extras”. Il problema è documentato qui: https://drupal.org/node/1823414 [19].

[20]Prima di disabilitare il modulo image, occorre leggere nella tabella {vocabulary_node_type} il campo vocabulary ID (vid) abbinato al contenuto tipo image. Nella figura a fianco la citata tabella.
Nel mio caso i campi vid 2 e 4 fanno capo a image. Problemi simili si hanno con le FAQ e Ubercart.
Disabilitato il modulo image, i record di {vocabulary_node_type} scompaiono e vanno reinseriti manualmente, usando una istruzione SQL (via phpMyAdmin, o qualunque altro metodo). L’istruzione SQL è semplicemente questa:
INSERT INTO vocabulary_node_types VALUES (2, 'image')
INSERT INTO vocabulary_node_types VALUES (4, 'image')

Dimenticare questa fase porta ad un termine di tassonomia  inutilizzabile: “Taxonomy Upgrade Extras”.

Disabilitare tutti i moduli ad esclusione Core – richiesti e dei Core - opzionali. Operazione è un po’ noiosa, perché deve essere ripetuta più volte per le dipendenze dei moduli che non ne consentono la disabilitazione in un solo passo.
C’è un comodo comando drush [22]per questa operazione:
drush pml --no-core --type=module --status=enebled --pipe > moduli.txt
per ottenere in elenco dei moduli attivi
xargs -a moduli.txt drush -y dis
per disabilitare i moduli nell'elenco.

Ovviamente per chi dispone di una shell. Drush non possibile nell’hosting di Aruba, ma utilizzabile nel mio ambiente di test.

Molto comoda è anche l'opzione fornita da Upgrade assits de disabilita tutti i moduli non core.

Questo punto è buono per un nuovo backup del file syste e del DB, per ripristini in caso di errori successivi.

Cancellare il file /sites/default/default.settings.php, ed accertarsi che setting.php abbia i permessi di scrittura abilitati: verrà modificato dalla procedura di upgrade.

Cancellare tutte le cartelle ed i file del core 6, ad eccezione di sites e relative sottocartelle (in pratica restano solo i dati e i moduli del nostro sito). Se sono stati modificati, tenere a portata di mano una copia dei vecchi file .htaccess e robots.txt.: andranno ripristinati.

Sostituire l'ambiente cancellato con i file di core delle versione Drupal 7.
E' come cambiare il motore, e tenere la carrozzeria.
Ripristinare i file .htaccess e robots.txt .

[25]Eseguire la script di update; www.mysite.xx/update.php [26].

In alcuni casi l'upgrade richiede molto tempo, quindi è bene incrementare il valore di max_execution_time presente in php.ini

La procedura provvede ad upgradare il sito, in particolare aggiorna le tabelle di drupal e il file settinngs.php

Qualora non sia possibile accedere a update.php, occorre modificare il file settings.php, cambiando la riga:
$update_free_access = FALSE;
   con
$update_free_access = TRUE;

Dopo l’upgrade, ripristinare il valore FALSE

Se l’operazione va buon fine, dovrebbe essere disponibile la home page del sito anche se diversi link non saranno funzionanti.

Questo è un buon punto per un ulteriore backup.

Occorre ora ripristinare le varie funzionalità e i moduli del sito. I moduli preesistenti risulteranno tutti in uno stato di incompatibilità con D7.

Il modulo cck, consentiva in D6 di creare campi nei tipo di contenuto. In D7, queste operazioni sono integrate nel core e quindi i campi vanno manipolati per eliminare il modulo cck.
La procedura è presente nel modulo cck per D7 (http://ftp.drupal.org/files/projects/cck-7.x-2.x-dev.tar.gz [28] ) disponibile nella versione development. Le istruzioni sono qui: https://drupal.org/node/1144136 [29]

Prima della operazione occorre installare e abilitare i moduli per i tipi di campo usati nel sito e non supportati dal core, ad esempio date. Altri campi, come file, vanno abilitati nel core.
Installare e abilitare cck (field migration) e dal menu Structure -> Migrate Fields avviare la migrazione dei campi.
Se alcuni campi risultano non migrabili è perché non è stato installato e abilitato il modulo relativo alla loro gestione.

I contenuti  di tipo image, gestiti attraverso il modulo image, non sono migrati completamente e correttamente. Per quanto strano questo processo non è completamente integrato in D7.
Alcune tabelle devono essere corrette in particolare {files}. Nel mio caso ho seguito questo post: https://drupal.org/node/757808 [31] in particolare il punto #83.
Ho usato il modulo image_legacy (che oggi marzo 2015, sembra sparito) disponibile qui: http://drupalcode.org/project/image.git/snapshot/8d13e3c972876948c7b28db... [32]. questa versione ha funzionato correttamente, mentre altre hanno dato problemi. Image_legacy va installato ed abilitato assieme al modulo field_convert disponibile qui: https://drupal.org/project/field_convert [33] la voce di menu per la conversione è content -> field convert.

Dopo la conversione ci si ritrova un contenuto tipo image correttamente funzionante.

Successivamente occorrerà sostituire la funzionalità di image gallery attraverso view slideshow e l’uso dei termini di tassonomia.

Nota: ad oggi, marzo 2015, il module image legacy sembra introvabile. Io ne avevo una copia e l'ho usato per la migrazione di un sito senza grossi probemi. Se qualcuno a migliori notizie sarei contento di uno scambio di informazioni.

In Drupal 6 ho utilizzato il modulo Nodewords che non esiste più in D7. Ho individuato due possibili soluzioni: Meta tags quick https://drupal.org/project/metatags_quick [35] e Metatag https://drupal.org/project/metatag [36]

Ho provato entrambi e ho scelto il secondo: partiamo con il primo.

Meta Tags quick
La procedura di migrazione è descritta qui: https://drupal.org/node/1201046 [37] e qui: https://drupal.org/sandbox/maxiorel/1198734 [38]

I problemi riscontrati sono stati errori dovuti alla dimensione dei campi descrizione e abstract in D6 presenti nella tabella {nodewords}. Di default Meta tags quick supporta non più di 160 caratteri e quando copia i dati da {nodewords} da errore. Si può modificare {nodewords} e portare i campi sotto i 160 caratteri o meglio modificare il default del nuovo modulo. Non è di comprensione immediata. Come farlo l’ho descritto qui: https://drupal.org/node/2139575 [39]

Meta tags quick è implementato attraverso nuovi campi nei nodi, a pelle non mi è piaciuto molto, non sono sicuro abbia migrato tutti i tgas e ho preferito indagare una soluzione con il modulo metatag

Per la migrazione a metatag ho seguito le indicazioni in https://drupal.org/node/1434756 [41], in particolare i punti #18 e #26.
Il modulo di migrazione (nodewords_migrate) utilizzato è qui https://drupal.org/files/issues/nodewords_migrate.tar_.gz [42]
Ho seguito le indicazioni al punto #18, ad esclusione del punto 1), io non ho usato la versione Metatag suggerita, ma l’ultima ufficiale disponibile. Non eliminare nodeword prima della sua migrazione.

La procedura migra solo i campi description e keywords. Per le mie necessità l’ho ritenuto sufficiente.

E’ ora possibile eliminare le cartelle /sites/all/modules/image e /site/all/modules/nodewords

Non resta che migrare gli altri moduli. E’ relativamente semplice. Si cancella la cartella del vecchio modulo /sites/all/modules/modulo, si installa il nuovo, lo si attiva e si esegue lo script update.php. E' importante ricordarsi di eseguire lo script, perchè è questa procedura che adatta le tabelle del DB alla nuova versione del modulo.

I token, in particolare quelli utlizzati nella automatizzazione degli Alias URL sono diversi in D7, devono essere  nodificati in Configurazione -> Ricerca e metadati -> Alias URL -> Patterns.
Ad esempio, nel mio caso, [title-raw] è diventato [node:title].

Una breve nota in merito i temi per i quali valgono considerazioni analoghe ai moduli. Vanno sostituiti con l'equivalente per D7.

Io ho cambiato il tema, perché utilizzavo un sottotema di Zen non più supportato in D7.
Semplicemente basta sostituire il tema ed abilitarlo. Certo, temi personalizzati richiederanno maggior impegno, ma non è il mio caso.

Non resta che ripristinare eventuali settaggi, come ad esempio la cache, la lingua (pur non essendo un requisito, ho preferito fare la migrazine in inglese), controllare i permessi, in particolare per i nuovi moduli e rimettere il sito on-line (era in manutenzione) e alla fine il sito è migrato.
Si possono disinstallare ed eliminare i moduli di supporto usati per la migrazione: imag_legacy, cck, filed_convert, nodewords_migrate.

Non ci dovrebbero essere moduli contrassegnati come incompatibili con D7.

Non può mancare un controllo generale sul funzionamento del sito, per verificare che tutto giri correttamente.

Gli URL del sito restano per lo più invariati, cosa buona per il SEO, questo è uno dei motivi per cui conviene la migrazione alla realizzazione di un nuovo sito. I motori di ricerca continuano a vedere quello che c’era e nella stessa posizione.

Alcuni URL cambiano, nel mio sito certamente quelli connessi alle gallerie di immagini. Per rimediare, alcune pagine verranno redirette usando istruzioni in .htassess del tipo redirect 301 vecchiopath nuovopath, altre resteranno come sono.

Per le pagini più importanti rivedrò anche i matatgs, in quanto certamente mi sono portato appresso alcune vecchie definizioni non convincenti.

Conclusioni
Il risultato della migrazione è visibile su questo sito. Spero sia piacevole e funzionale. La sola fatica è stata capire i passi fondamentali ed individuare le soluzioni per image e nodewords, il resto normali procedure al più noiose.