Override propre d'un controller PrestaShop sans casser les mises à jour

Le dossier /override de PrestaShop est un piège : à chaque mise à jour cœur, vos overrides risquent d'être écrasés ou de provoquer des fatales si le contrat de la classe parente change.

Préférez systématiquement l'override depuis un module. Voici le pattern minimal qui marche en PS 1.7 / 8 / 9.

Structure du module

/modules/myoverride/
├── myoverride.php
└── override/
    └── controllers/
        └── front/
            └── ProductController.php

Le module principal

<?php
class Myoverride extends Module
{
    public function __construct()
    {
        $this->name = 'myoverride';
        $this->version = '1.0.0';
        $this->author = 'AppNova';
        parent::__construct();
        $this->displayName = 'Override Front Product';
    }

    public function install()
    {
        // L'auto-installation des overrides depuis /override/ du module
        // est gérée par PS automatiquement à l'install.
        return parent::install();
    }
}

Le controller overridé

<?php
class ProductController extends ProductControllerCore
{
    public function initContent()
    {
        parent::initContent();
        // Votre logique custom ici
        $this->context->smarty->assign('custom_data', 'hello');
    }
}

À l'installation du module

PrestaShop copie automatiquement /modules/myoverride/override/... vers /override/... au moment de install(). À la désinstallation, le fichier est retiré.

Les bonnes pratiques

• Toujours appeler parent::initContent() ou la méthode parente pour ne pas casser la chaîne
• Versionnez le module pour pouvoir le désinstaller proprement avant un upgrade PS
• Si plusieurs modules overrident le même controller, le dernier installé gagne (vérifiez l'ordre)
• Pour PS 9, préférez les EventSubscriber Symfony quand c'est possible — moins de risque de conflit