Conflit d'overrides PrestaShop : installer un module malgré une surcharge existante

Comprendre le système d'overrides PrestaShop

Le mécanisme d'override est l'un des piliers de la personnalisation PrestaShop. Il permet de modifier le comportement d'une classe ou d'un contrôleur du cœur sans toucher aux fichiers originaux. Chaque override se place dans le dossier /override/ et étend la classe parente.

Le problème survient lorsque deux modules tentent de surcharger la même méthode d'une même classe. PrestaShop ne sait pas fusionner automatiquement deux overrides concurrents et bloque l'installation avec un message du type :

Impossible d'installer la surcharge : La méthode __construct dans la classe AdminOrdersController est déjà surchargée.

Cette erreur est parfaitement normale : c'est un garde-fou qui empêche un module d'écraser silencieusement les modifications d'un autre.

Pourquoi ce conflit se produit

Quand un module s'installe, PrestaShop exécute la méthode installOverrides(). Cette méthode parcourt le dossier override/ du module et tente d'injecter chaque méthode dans le fichier d'override global correspondant (/override/controllers/admin/AdminOrdersController.php par exemple).

Si la méthode existe déjà dans le fichier d'override global — placée là par un autre module ou manuellement — l'installation est refusée.

Le fichier clé à examiner est :

/override/controllers/admin/AdminOrdersController.php

Ouvrez-le : vous y trouverez la méthode __construct() déjà présente, injectée par un module précédemment installé.

Solution : la fusion manuelle des overrides

La fusion manuelle est la méthode la plus fiable et ne nécessite aucun module tiers. Voici la procédure complète.

Étape 1 — Identifier les deux versions du code

Récupérez le contenu de la méthode conflictuelle depuis deux sources :

1. **L'override existant** : `/override/controllers/admin/AdminOrdersController.php`
2. **L'override du nouveau module** : `/modules/nom_du_module/override/controllers/admin/AdminOrdersController.php`

Étape 2 — Fusionner le code

Créez une version unifiée de la méthode qui intègre la logique des deux modules. Voici un exemple concret avec __construct() :

<?php
/**
 * Override fusionné — AdminOrdersController
 * Module A + Module B
 */
class AdminOrdersController extends AdminOrdersControllerCore
{
    public function __construct()
    {
        // Code du Module A
        $this->bootstrap = true;
        // ... logique spécifique au module A ...

        // Code du Module B
        // ... logique spécifique au module B ...

        // Appel au constructeur parent (toujours en dernier)
        parent::__construct();
    }
}

Point critique : l'appel à parent::__construct() doit généralement rester en dernière position, sauf si l'un des modules attend explicitement qu'il soit appelé avant. Lisez attentivement le code de chaque module pour comprendre l'ordre attendu.

Étape 3 — Supprimer l'override du module avant installation

Une fois la fusion effectuée dans le fichier global, supprimez ou renommez le fichier d'override dans le dossier du nouveau module :

mv modules/nom_du_module/override/controllers/admin/AdminOrdersController.php \
   modules/nom_du_module/override/controllers/admin/AdminOrdersController.php.bak

Relancez ensuite l'installation du module depuis le back-office. Sans fichier d'override à injecter, le conflit disparaît.

Étape 4 — Vider le cache

Après toute modification d'override, videz impérativement le cache :

# Supprimer le fichier de cache des classes
rm -f var/cache/prod/class_index.php
rm -f var/cache/dev/class_index.php

# PrestaShop 1.6
rm -f cache/class_index.php

Sur PrestaShop 8.x, vous pouvez également vider le cache Symfony :

php bin/console cache:clear --env=prod

Approche alternative sur PrestaShop 8.x : les hooks plutôt que les overrides

Depuis PrestaShop 1.7.7 et surtout sur la version 8.x, Symfony a profondément changé la donne. Les overrides de contrôleurs admin sont dépréciés au profit de mécanismes plus propres :

• **Hooks** : `actionAdminOrdersControllerBefore`, `actionObjectOrderUpdateAfter`, etc.
• **Décorateurs de services Symfony** : pour modifier le comportement d'un service sans toucher à la classe.
• **Event subscribers** : pour réagir aux événements du cycle de vie.

Si vous développez un module neuf, privilégiez systématiquement les hooks. Les overrides restent fonctionnels mais constituent une dette technique croissante.

// Exemple : hook moderne remplaçant un override de __construct
public function hookActionAdminControllerSetMedia()
{
    if ($this->context->controller instanceof AdminOrdersController) {
        // Votre logique ici, sans override
        $this->context->controller->addCSS($this->getPathUri() . 'views/css/custom.css');
    }
}

Bonnes pratiques pour éviter les conflits d'overrides

1. **Documentez vos overrides** : ajoutez un commentaire en tête de chaque méthode surchargée indiquant quel module l'a posée et pourquoi.
2. **Avant d'installer un module**, inspectez son dossier `override/` pour anticiper les conflits.
3. **Tenez un registre** des overrides actifs sur votre boutique. Un simple fichier texte listant module → classe → méthode vous évitera bien des surprises.
4. **Préférez les hooks** quand c'est possible : ils sont cumulables par nature, contrairement aux overrides.
5. **Sauvegardez** toujours le fichier d'override global avant de le modifier.

Cas particulier : désinstallation d'un module après fusion

Attention : si vous désinstallez un module dont l'override a été fusionné manuellement, PrestaShop tentera de retirer ses méthodes du fichier d'override global via uninstallOverrides(). Comme vous avez modifié ce fichier manuellement, la désinstallation pourrait échouer ou laisser du code orphelin.

Dans ce cas, nettoyez manuellement le fichier d'override après désinstallation et videz le cache.