Mise à niveau de Magento en version 1.9

Cela fait un moment que je n’écris que sporadiquement sur ce site, pour ceux qui me suivent un peu sur les réseaux sociaux, vous connaissez mon périple mauricien, pour les autres ce sera je pense l’objet d’un billet futur. Bref, je suis de retour en France, avec un nouveau job également. Cette petite introduction me permet d’en venir aux faits et de parler de la première grosse tâche pour laquelle j’ai été embauché à savoir mettre à jour une boutique Magento.

L’entreprise n’a pas été dénuée de stress car je n’avais pas vraiment d’expérience de Magento (ou de commerce en ligne en général) et la moindre erreur ou le moindre faux pas et le site marchand peut ne plus fonctionner. J’ai donc pris un peu de temps pour me familiariser avec le processus de mise à jour d’un site d’e-commerce en production sous Magento.

Ce document décrit le processus de mise à niveau de Magento d’une version 1.7 (1.7.0.2 en ce qui me concerne) vers la version 1.9 (1.9.2.1) que j’ai pratiqué. Ce n’est pas un guide bullet-proof et il ne correspond peut-être pas à tous les cas.
Il ne décrit pas comment mettre en place un environnement de développement / test, il suppose donc que celui-ci existe.

Prérequis

Cela semble évident mais il est toujours bon de le répéter, toujours avoir des sauvegardes de l’environnement de développement ET de production, fichiers et base de données.

Avoir l’environnement de développement versionné, dans mon cas sous GIT.

Description globale de la procédure de mise à niveau

1. Mettre en place une copie de la boutique de production dans un environnement de test, par exemple : test.monsite.com
2. Faire la mise à jour en remplaçant les fichiers de la 1.7 par les fichiers de la 1.9. Beaucoup de procédures décrites en ligne – y compris celle officielle de Magento – parlent de l’inverse : avoir une installation propre en 1.9 puis copier les modules, thèmes, personnalisations, médias, etc de l’ancienne version. Mais je trouve qu’avec cette façon de procéder, il faut une liste précise de ce qui a été modifié, chose difficile dans mon cas.
   A noter que quoi qu’il en soit ma façon de faire n’a pas été sans soucis (mineurs) non plus, j’ai effectivement écrasé certaines choses de la 1.7, mais avec les sauvegardes j’ai pu m’y retrouver.
3. Visiter le site pour mettre à jour la base de données, vérifier le bon fonctionnement du site et tester intensivement.

Prise en compte des derniers changements en BDD

A l’étape 3 du chapitre précédent, on a un site de test qui fonctionne, les éventuels bugs ou erreurs et adaptations sont faits. Le but est maintenant de finaliser la mise à niveau en prenant en compte les derniers changements de la base de données afin de ne pas perdre de données provenant des visiteurs (transactions, création d’utilisateur, etc).

1. Mettre la boutique de production en mode maintenance.
   Il suffit d’ajouter un fichier maintenance.flag à la racine de la boutique.
2. Désactiver les CRON
3. Vider le cache et les sessions :
rm -rf var/cache
rm -rf var/session
4. Faire un dump de la base de données de production :
   mysqldump -u utilisateur -p base_prod > /somewhere/dump_prod.sql
5. Faire un dump de la base de données de test :
   mysqldump -u utilisateur -p base_test > /somewhere/dump_test.sql
6. Vider la base de données de test :
   drop database base_test;
create database base_test;
7. Importer le dump de production dans la base de données de test :
   mysql -u utilisateur -p base_test < /somewhere/dump_prod.sql
8. Changer les 2 URL dans la table core_config_data de test :
   web/unsecure/base_url    http://test.monsite.com/
web/secure/base_url   http://test.monsite.com/
9. Changer les identifiants de connexion à la base de données sous app/etc/local.xml
10. Se rendre sur la boutique et tester le site. A ce niveau là, le site de test est fonctionnel et peut devenir le site de production. Pour ce faire il faut le basculer en site de production.
11. Supprimer le cache et les sessions :
    rm -rf var/cache
rm -rf var/session
12. Déplacer les fichiers de l’instance de production à un autre endroit (par ex même endroit dans un répertoire _old, mais penser à supprimer ce répertoire lorsque tout est bon pour économiser de l’espace).
13. Copier les fichiers de l’instance de test à la racine du site de production.
14. Vider la base de données de production (voir point 5).
15. Faire un dump de la base de données de test :
    mysqldump -u utilisateur -p base_test > /somewhere/dump_test_pour_prod.sql
16. Importer ce dump dans la base de données de production :
    mysql -u utilisateur -p base_prod < /root/dump_test_pour_prod.sql
17. Changer les 2 URL dans la table core_config_data de test :
    web/unsecure/base_url : http://www.monsite.com/
web/secure/base_url : http://www.monsite.com/
18. Changer les identifiants de la base de données sous app/etc/local.xml
19. Sortir du mode maintenance en supprimant le fichier maintenance.flag.
20. C’est terminé. Se rendre sur la boutique de production, vérifier et tester.

Il s’agit de la procédure générale, le gros d’une telle mise à niveau étant de veiller au bon fonctionnement des modules ajoutés. Dans mon cas il s’agissait principalement de l’Embedded ERP de Boost My Shop et de Shopping Flux. Ceci n’est bien sur pas décrit dans cet article.

UPDATE 23/08/2023

Lors de la mise en place d’un site d’archive du Magento 1.9, j’étais redirigé vers l’ancien site. Il a fallu vider le cache programmatiquement en plaçant ce script à la racine du nouvel hébergement :

<?php 
require_once 'app/Mage.php';
$app = Mage::app();

echo "<pre-->";
if($app != null) {
        echo "The app was initialized.\n";
        $cache = $app->getCache();
        if($cache != null) {
                echo "The cache is not empty. Clean it.\n";
                $cache->clean();
        }
}
exit;