Migrer drupal 7

Pour un simple site, si on change d'hébergeur ou dev/prod. Trad de Migrating a site

Attention si devel + drupalforfirebug -> consomme trop de mémoire php chez Gandi (avec commerce) => les désactiver avant ou via drush

Avant toute action... documenter

Noter modules (ver et chemin), comparer conf et versions de PHP, MySQL, Apache...
Voir cette checklist en anglais dont voici un petit résumé:

coté nouveau serveur

• drupal 7 a besoin de pdo_mysql
• phpinfo, /etc/php5/apache2/php.ini  memory limit  + post_max_size dit etre 2x upload_max_filesize
• vérifier si allow_url_fopen est necesssaire (update et rss) + include_path contient '.' + safe_mode est à off
• ne pas oublier cron

dans interface de drupal

tester upload et image. vérifier droits des users admin/editor/authenticated/anonymous. Se loguer avec chaque role, test upload gros fichiers, avec filtres input.

check des permissions

en installant: perm sur sites/${SITENAME} et sites/${SITENAME}/files (voir admin/settings/file-system)
accès en écriture sur /tmp/tmp - si besoin à changer en sites/${SITENAME}/files/tmp

ajustement sécurité

Remodifier perms (sites/${SITENAME}).

Proprio et group à vérifier ls -la files/ devraient etre à www-data et settings.php contient pw db => seul www-data devrait pouvoir le lire

pour meilleure performance: passer les paramètres du .htaccess vers conf apache

tests

naviguer sur ...files/ (doit etre ko). Vérifier que www.site.com et site.com est idem (cf .htaccess). Test envoi email.

Bonnes pratiques

Lancer un checker de liens (ex appli: www.linklint.org/ ou validator.w3.org/checklink ou module link_checker) puis vérifier admin/reports

Perf: pour drupal et autres php. Vérifier et tester le plan de backup. Conf et test autres appli non-drupal (google analytics, weblizer...), vérifier accès aux log srv. Si new hébergeur, penser à voir les charges si on dépasse charge cpu, disk...

Documenter pw, chemins, IP...

Sur l'ancien site

1. Noter modules (ver et chemin).
2. Noter où est tmp de admin/settings/file-system : soit il sera le meme, soit il faudra le modifier sur la new install. drush vget file_
3. Mettre le site en maintenance (Administer → Site maintenance ou drush vset maintenance_mode "1") et
4. mettre à jour core et modules si besoin.
5. Couper clean url (on se logera avec www.example.com/?q=userwww.example.com/?q=user )
6. vider les caches (admin/settings/performance ou par admin-menuadmin/settings/performance)
7. export db
8. remettre (ou pas, ou couper les droits users) le vieux site hors de maintenance.
9. backup des fichiers (par FTP par ex) ou faire une nouvelle install fraiche

à faire aussi: modifier le .sql

Sur old/new ou autre machine: si migration faire transfert dns + soucis des liens codés en dur à modifier dans le .sql

1. liste des fichiers (table files champ file_path ; j'ai la table file_managed + regarder field_config pour indices)
2. URL du site dans les nodes (liens, mais aussi dans les logs, modules message/imagefield/...).
3. restrictions différentes possible sur nom db (nb car)
4. éventuellement, virer cache logs... sed -E -e "/^INSERT INTO \`(cache|watchdog|sessions)/d" < /path/to/dump.sql > /path/to/dump-stripped.sql
   sed -E -e "/^INSERT INTO \`(cache|watchdog|sessions)/d" < /path/to/dump.sql > /path/to/dump-stripped.sql

Sur le new srv

si en local (version de dev): voir conf apache (conf.d et sites-enabled - rappel: sudo a2enconf nom-conf  et  sudo a2ensite monsite1)

1. soit copier les fichiers récupérés soit faire une install fraiche (test env) du core + modules + themes
2. copier répertoires de fichier, galleries d'images... au bon endroit cad ce qu'on a modifié dans le .sql (voir 1. de "à faire aussi")
3. créer new db
4. importer le .sql modifié
5. créer le user de la db avec privilèges SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, CREATE_TMP_TABLE et LOCK_TABLES
6. modif settings.php avec nom et user db. Si on change de domaine/sous domaine: modifier base URL.
   Si vers new domaine ou localhost, vérifier que $cookie_domain n'a pas l'ancien domaine.
7. parfois il faut aussi modifier les règles de rewrite et .htaccess
8. tenter de se loguer /?q=user
9. mettre à jour email et conf du rep files (admin/settings/file-system ou admin/config/media/file-system)   + /tmp si nécessaire
   drush vset file_temporary_path "/tmp"
10. parfois, des modules peuvent dysfonctionner si changement ver php et doivent etre maj/configurés.
11. Checker le statut et lancer le cron drupal
12. Modif theme (pour ne pas les confondre)
13. Administer → Site configuration → Performance
    tests et remettre on-line
14. conf cron (coté srv) ou encore Poormanscron (si hébergeur n'offre pas cron)
15. si migration vers hébergeur public (non vers localhost) conf dns