You are here

Drupal upgrade: problemi e soluzioni

Inviato da giovanninews on Mar, 22/04/2014 - 19:47

upgrade drupal Questo articolo sull' upgrade di Drupal dalla versione 6 a Drupal 7 arriva dopo circa due mesi dal precedente; oltre che indicare qualche motivo per cui è necessario passare a Drupal 7, ho voluto anche indicare la convenienza nel fare l' upgrade:

tanti infatti, forse a causa di errori che non sono riusciti a risolvere, hanno preferito fare una nuova installazione importando i vecchi contenuti.

Certamente avranno perso tutto il valore acquisito dal sito precedente, perdendo pagerank e backlinks e forse avranno anche incassato penalizzazioni, se il dominio è lo stesso e le url sono cambiate.

So che adesso è forse un pò tardi per parlare di upgrade di Drupal, ma alcuni sono ancora con Drupal 6 e questi potranno trovare interessanti le righe che seguono.

Procedura di upgrade da Drupal 6 a Drupal 7

Non sto ad elencare passo passo la procedura di upgrade Drupal; ciò è perfettamente documentato sia su Drupal.org che su tanti siti di drupalisti. Voglio soltanto ricordare che prima di trasferire sul sito il nuovo core di Drupal 7 è indispensabile:

  1. aggiornare sia il core di Drupal 6 che i moduli utilizzati alle ultime versioni rilasciate
  2. effettuare un backup del sito web salvando sia i files che il database

Consigli per l' upgrade di Drupal

  • verificare i moduli utilizzati per vedere se è disponibile lo stesso modulo per Drupal 7; per fare questo nel modo più rapido si può utilizzare il modulo upgrade_status
  • preparare una cartella contenente il nuovo core Drupal 7 ed una cartella contenente i nuovi moduli per Drupal 7 da utilizzare. I moduli che non esistono o vanno sostituiti con moduli equivalenti o vanno pensate possibili alternative; ricordo che se un modulo per Drupal 6 non esiste per Drupal 7, significa che o era superfluo o obsoleto.
  • mettere al sicuro i vecchi file di configurazione: .htaccess, settings.php e robots.txt. Il file .htaccess fornito con Drupal 7 è sicuramente migliore del precedente (è quello che io utilizzo) in quanto gli sviluppatori di Drupal cercano di fornire un file .htaccess che può andare bene con la maggior parte dei server e dei fornitori di servizio. Certamente a volte è necessario fare qualche modifica.

Il mio consiglio è quello di procedere all' upgrade Drupal con una copia del sito, in quanto, per un sito corposo, le variabili che possono portare ad errori nell' upgrade, sono tante.

La fase di upgrade può anche durare settimane, se si vuole avere lo stesso sito con Drupal 7, senza perdere niente di ciò che si aveva prima; il fermo del sito per una settimana comporta la perdita di indicizzazione e valorizzazione.

Per creare una copia del sito è sufficiente creare un sottodominio in cui metteremo i files identici del sito ed un database (con nome diverso) in cui metteremo il database copiato dall' originale sul quale, con un editor di testo tipo Notepad++, sostituiremo il nome del dominio con quello del sottodominio.

Nella copia del sottodominio dovremo inoltre modificare il settings.php mettendo i valori del sottodominio, il robots.txt dove metteremo solo un bel

User-agent: *

Disallow: /

per evitarne l' indicizzazione se vogliamo provare a metterlo online (per poco tempo onde evitare il più possibile in SERP, nei risultati supplementari, la presenza delle url del sottodominio anche se il robots ne impedisce l' accesso) ed un diverso file .htaccess se contiene puntamenti al dominio principale.

Lavorare con la copia porterà ad fermo del sito in produzione solo per il tempo necessario a fare l' operazione inversa, quando saremo sicuri che tutto funzionerà perfettamente con Drupal 7. Rifaremo un bakup dei files e del database del sito di test, cambieremo nuovamente i puntamenti al database mettendo questa volta il dominio principale, e cambieremo il setting.php ed il robots.txt con i valori normali.

Siamo pronti ?

OK, si mette offline il sito di produzione, si cancella il tutto e si sostituisce con quello che abbiamo preparato in test e modificato.

Fermo del sito: 30 minuti.

Abbiamo deciso di fare tutto in test, ma non abbiamo ancora fatto l' upgrade. Abbiamo ora in test il core di Drupal 6 con i moduli tutti aggiornati. Prima di procedere con l' ugrade consiglio di fare un ulteriore controllo: è importante sapere se, negli anni di utilizzo di Drupal, abbiamo involontariamente modificato qualche variabile che potrebbe compromettere l' upgrade.

Se abbiamo modificato variabili, in fase di upgrade avremo sicuramente un errore simile a questo:

Notice: unserialize() [function.unserialize]: Error at offset 74 of 75 bytes in variable_initialize() (line 749 of /srv/www/<sitename>/includes/bootstrap.inc).

Per evitare questo esiste un altro modulo, variablecheck , disponibile sia per Drupal 6 che per Drupal 7; utilizzeremo ora la versione 6, mentre la versione 7 sarà utilizzata per il futuro upgrade a Drupal 8. Variablecheck, se troverà variabili non definite ci indicherà anche come sistemarle.

Bene, siamo sempre in test e con il sito offline e tema di default (Garland), loggati da amministratore, facciamo un po' di pulizia. Disabilitiamo tutti i moduli non core lasciando solo quelli dei quali avremo la nuova versione e disinstalliamo tutti gli altri.

Cancelliamo tutte le cartelle del core Drupal 6 e tutti i files lasciando solo la cartella sites e tutte le sottocartelle; in pratica devono rimanere soltanto i files ed i vecchi moduli (disabilitati); trasferiamo il nuovo core di Drupal 7 con tutti i files, nella stessa posizione. Il settings.php deve avere i permessi di scrittura abilitati.

Rimettiamo il robots.txt con il disallow: / , mentre per l' htaccess, si può rimettere sia l' htaccess usato con Drupal 6 se abbiamo fatto particolari modifiche, sia il nuovo htaccess di Drupal 7 (naturalmente dovremo cambiare i puntamenti al sito di test).

Una parentesi sul file .htaccess: gli sviluppatori di Drupal, con Drupal 7, hanno fornito un htaccess sicuramente meglio ottimizzato per tutti gli ambienti, per la sicurezza, per i redirect www e non-www, per http e per https, per la compressione gzip onde evitare doppie compressioni se l' hosting fa la compressione ed altro. Personalmente ho preferito l' htaccess di Drupal 7 aggiornando qualcosa.

Eseguiamo quindi la procedura di update. Se per qualche motivo ci siamo disconnessi da amministratore, il sistema non ci consentirà più di fare l ' update.

Siamo fatti ? Non ancora.

Per andare avanti dovremo mettere in scrittura il file setting.php, modificare la riga $update_free_access = FALSE; in $update_free_access = TRUE; per il tempo necessario all' update (sarà consentito a chiunque) che faremo via web (url sito/update.php) e subito dopo rimetteremo il valore FALSE e riporteremo al valore originale i permessi del setting.php.

Dopo l' update troveremo il nostro sito con il nuovo core di Drupal 7. I moduli, anche se disabilitati, presenteranno tutti un pallino rosso in quanto non compatibili con il nuovo core.

Alcuni moduli che prima erano per Drupal 6, sono ora integrati nel core di Drupal 7; è questo ad esempio il caso di CCK con il modulo Imagefield ed il modulo Filefield, integrati nel core insieme al modulo Image.

Abbiamo inoltre il modulo Token, anch' esso integrato nel core, che implicherà modifiche di token per i nuovi moduli Pathauto e Meta tags per Drupal 7.

Per importare i vecchi dati di CCK, relativamente ad Imagefield e Filefield, sarà necessario scaricare l' ultima versione di CCK per Drupal 7 che contiene CCK e Content Migrate, abilitando solo Content Migrate. Content Migrate, nella Struttura del sito metterà due campi che sarà possibile migrare nel nuovo core, field_image e field_description, e permetterà anche di effettuare un roll_back se la migrazione non ci soddisfa.

I passaggi per la migrazione dei moduli più importanti sono ben descritti in queste ottime pagine alle quali ho voluto solo aggiungere, lato SEO, la necessità di fare il tutto in un sito di test e quindi passare il tutto in produzione, perchè, sempre lato SEO, dal mio punto di vista non è una passeggiata; lo switch deve essere fatto solo quando si è sicuri che ogni singola url, indicizzata o no, rimanda alla identica url del sito che esisteva in Drupal 6.

Particolare attenzione deve essere fatta con Token, quindi agli Alias urls, alla configurazione di Meta tags un pò diversa da Nodewords ed a Pathauto.

Fate attenzione anche alla configurazione per la generazione dei feed RSS. Mi permetto inoltre di segnalarvi l' attenzione per XML Sitemap che, se implementato in test, genererà la sitemap con il percorso di test; quindi consiglio di installare XML Sitemap direttamente alla fine di tutto, dopo che si è fatti lo switch da test a produzione.

Dal mio punto di vista, Drupal è anche questo, piaccia o non piaccia.

<< Pagina precedente