Sin impuesto Con impuesto

Mettre à jour un module sans casser les boutiques : scripts d'upgrade et versionnage

L'installation propre, tout le monde la teste ; la mise à jour depuis la version d'il y a un an, presque personne. Voici comment nous évitons qu'une nouvelle version casse des boutiques qui fonctionnaient.

Jesús Meilán
Updated: 26/09/2026 111
Mettre à jour un module sans casser les boutiques : scripts d'upgrade et versionnage
Share:

Quand on teste un module, on l'installe généralement sur une boutique vierge. Mais vos clients n'installent pas : ils mettent à jour, en sautant parfois cinq versions. Si le chemin de mise à jour n'est pas soigné, la nouvelle version fonctionne sur votre machine et échoue sur la leur.

Comment PrestaShop décide quoi exécuter

Lors de l'envoi d'une nouvelle version, PrestaShop compare la version enregistrée dans la table module avec celle du code et exécute, dans l'ordre, les fichiers upgrade/upgrade-X.Y.Z.php dont la version se situe entre les deux. Chacun définit une fonction :

function upgrade_module_1_4_0($module)
{
    $db = Db::getInstance();
    $existe = $db->executeS("SHOW COLUMNS FROM `" . _DB_PREFIX_ . "mimodulo` LIKE 'fecha_envio'");
    if (!$existe) {
        $db->execute("ALTER TABLE `" . _DB_PREFIX_ . "mimodulo` ADD `fecha_envio` DATETIME NULL");
    }

    return $module->registerHook('actionOrderStatusPostUpdate');
}

Les quatre règles

  1. Idempotents. Un script peut s'exécuter deux fois (une mise à jour interrompue, une réinstallation). Vérifiez avant de créer : colonnes, index, onglets, configurations.
  2. Tout ce qui est nouveau, aussi dans l'upgrade. Les hooks, onglets, tables et valeurs de configuration que vous ajoutez dans install() doivent avoir leur jumeau dans un script d'upgrade, sinon les anciennes boutiques ne les auront jamais.
  3. Ne supprimez jamais les données du client. Si une colonne est en trop, laissez-la ou renommez-la ; ne la supprimez pas dans un upgrade. Et attention à la désinstallation pour réinstaller : certains modules suppriment toutes leurs tables à la désinstallation.
  4. Renvoyez vraiment true ou false. Si l'upgrade échoue et que vous renvoyez true, PrestaShop marque la version comme appliquée et ne réessaiera pas.
Exemple réel : un écran de back-office qui renvoie une erreur 500 dans certaines boutiques et pas dans d'autres. La cause : deux onglets avec la même classe, parce qu'une ancienne version le créait dans install() et qu'un upgrade ultérieur le recréait sans vérifier. Doctrine attend une ligne et en trouve deux.

Versionnage sémantique

  • Correctif (1.4.1) : corrections sans changement de données.
  • Mineure (1.5.0) : nouvelles fonctionnalités rétrocompatibles, avec leur script d'upgrade.
  • Majeure (2.0.0) : changements qui imposent de revoir la configuration ou qui abandonnent des versions de PrestaShop ou de PHP.

Comment nous testons

Nous installons la version précédente publiée sur une boutique de test, nous la configurons avec des données proches de celles d'un client, puis nous mettons à jour avec le nouveau ZIP depuis le gestionnaire de modules, exactement comme le fera le client. Ce n'est qu'ensuite que nous testons l'installation propre. Cela paraît plus long ; en réalité, c'est ce qui nous épargne les incidents du lundi matin.

Chargement...
Consentement aux cookies
Retour en haut