Tag: Architecture de PrestaShop

Le système de remplacement de PrestaShop permet de personnaliser le comportement de base sans modifier les fichiers originaux. Cependant, mal utilisé, il crée des boutiques fragiles qui deviennent inutilisables lors des mises à jour. Ce guide de Knowband explique le fonctionnement des remplacements, quand les utiliser et trois pièges importants que tout développeur devrait connaître.

Qu’est-ce que le système de dérogation ?

PrestaShop utilise l’héritage PHP pour vous permettre de remplacer n’importe quelle classe principale par votre propre version, sans modifier les originales. Chaque classe principale possède le suffixe « Core », par exemple « ProductCore ». Si vous créez le fichier `/override/classes/Product.php` contenant une classe nommée `Product` qui étend `ProductCore`, PrestaShop chargera votre version. Il en va de même pour les contrôleurs.

Ne modifiez que les méthodes spécifiques que vous devez changer ; ne copiez jamais un fichier de classe entier. Cela permet de conserver des modifications plus concises et de réduire considérablement les risques de conflits avec les mises à jour ultérieures.

Exemple : exposer le nom du contrôleur actuel dans votre modèle d’en-tête :

Où placer vos fichiers de remplacement

Les paramètres de remplacement peuvent être stockés à deux endroits. Le répertoire global `/override/` à la racine de votre installation est actif immédiatement après la suppression du cache. Il est préférable de regrouper les paramètres de remplacement dans un module.

Placer un fichier de surcharge dans un module (par exemple, /modules/mymodule/override/classes/Product.php) permet à PrestaShop de le copier dans /override/ lors de l’installation et de le supprimer proprement lors de la désinstallation. C’est la méthode recommandée.

Voici un exemple rapide de surcharge de classe. Supposons que vous souhaitiez exposer le nom du contrôleur actuel dans votre modèle d’en-tête :

// /override/classes/controllers/FrontController.php

classe FrontController étend FrontControllerCore {

    fonction publique initHeader() {

        self::$smarty->assign('currentController', get_class($this));

        retourner parent::initHeader();

    }}

Appelez toujours la méthode parente, sauf raison valable de ne pas le faire. L'omettre perturbera silencieusement le fonctionnement de base.

Surcharge des classes et des contrôleurs de modules

Depuis PrestaShop 1.6, vous pouvez également surcharger les classes des modules. Ajoutez « Override » au nom de la classe (par exemple, BlockUserInfoOverride étendant BlockUserInfo) et placez-la dans le répertoire /override/modules/. La même règle s’applique aux contrôleurs de modules. Après toute surcharge, videz le cache, et plus précisément supprimez le fichier /cache/class_index.php, sinon les modifications ne seront pas prises en compte.

Quand NE PAS utiliser les substitutions

Les surcharges sont exclusives : une seule est autorisée par classe. Elles sont également interdites dans les modules de la marketplace et doivent être réservées aux personnalisations de boutiques privées. Avant d’utiliser une surcharge, considérez l’une des alternatives suivantes :

• Crochets PrestaShop déclenche des événements de hook à chaque chargement de page ; vous pouvez les exploiter depuis un module pour exécuter du code personnalisé ou insérer du contenu dans la page sans avoir à toucher à une classe du noyau.
• Remplacements de services Symfony : Les parties de PrestaShop migrées vers Symfony offrent une gestion plus claire des services. Vous pouvez personnaliser ou remplacer un service plutôt que de modifier directement la classe.
• Modèle d’objet personnalisé : Besoin d’ajouter des champs à une entité principale ? Créez votre propre modèle objet avec sa propre table plutôt que de modifier celle existante.

Protection des modifications de configuration lors des mises à jour

Les mises à jour de PrestaShop peuvent modifier silencieusement la signature des méthodes, rendant ainsi vos surcharges obsolètes. Après chaque mise à jour, il est essentiel de revoir vos surcharges. Commentez les modifications apportées et leur raison d’être, consultez le journal des modifications et veillez à ce que vos surcharges restent aussi concises que possible. Une surcharge simple, bien commentée et appelant correctement les méthodes parentes résiste aux mises à jour. Une copie intégrale de la classe représente un bug potentiel.

Le cache « fantôme » : pourquoi votre modification semble invisible

La principale raison pour laquelle les développeurs pensent que leur personnalisation est défectueuse : PrestaShop n’analyse pas le répertoire `/override/` à chaque requête. Il compile une table de correspondance des classes dans `/cache/class_index.php`, et tant que ce fichier n’est pas supprimé et régénéré, votre personnalisation reste invisible, aussi correct que soit le code. Vider le cache Smarty ne suffit pas. Supprimez manuellement `class_index.php` via FTP/SSH, via Paramètres avancés > Performances dans l’interface d’administration, ou via la console Symfony.

Figure 1 : Le flux du système de remplacement PrestaShop et le rôle de /cache/class_index.php.

Le mur de Symfony : les anciennes configurations ne fonctionnent pas avec les contrôleurs modernes

Ce système PHP hérité ne fonctionne qu’avec l’ancienne couche ObjectModel de PrestaShop. À partir de PS 1.7, les principales zones du back-office, notamment les nouvelles pages produits et les écrans de commande, ont été réécrites avec Symfony. Le système de remplacement PHP n’affecte pas ces contrôleurs Symfony. Pour ceux-là, utilisez Décoration de serviceVous pouvez encapsuler ou remplacer un service via le fichier services.yml de votre module. Si une surcharge reste sans effet même après avoir vidé le fichier class_index.php, il est probable que le contrôleur ait été migré vers Symfony.

Résolution des conflits : lorsque deux modules souhaitent la même classe

Lorsque deux modules redéfinissent la même classe, PrestaShop génère une erreur lors de l’installation du second module et désactive sa redéfinition. La solution est manuelle : ouvrez les deux fichiers, fusionnez toutes les méthodes dans un seul fichier `/override/` qui étend la classe principale, puis supprimez `class_index.php`. Ajoutez des commentaires indiquant le module ayant contribué à chaque méthode. C’est pourquoi les redéfinitions sont interdites dans les modules de la marketplace : les conflits sont à la charge du marchand. Si vous développez pour d’autres plateformes, utilisez les hooks.

Figure 2 : Comment surviennent les conflits de remplacement lorsque deux modules ciblent la même classe, et la résolution de fusion manuelle.

À propos de Knowband

Knowband est un fournisseur de plugins et d’extensions e-commerce de confiance, fort d’une longue expérience dans l’accompagnement des e-commerçants pour la création de boutiques en ligne plus rapides, plus intelligentes et plus riches en fonctionnalités. Que votre boutique soit hébergée sur [plateforme manquante], Knowband est là pour vous. PrestaShop, OpenCartShopify, WooCommerce, MagentoQue ce soit pour iOS ou toute autre plateforme majeure, Knowband propose une large gamme de plugins et d’extensions prêts à l’emploi qui vous aident à améliorer les fonctionnalités, les performances et à offrir une meilleure expérience d’achat, sans avoir à tout développer à partir de zéro.