Masquer des commandes dans le back-office PrestaShop sans les supprimer

Le problème : un back-office saturé par des milliers de commandes

Après plusieurs années d'activité, la liste des commandes dans le back-office PrestaShop peut devenir difficile à gérer. Entre les commandes abandonnées, les tests, les annulations anciennes et les commandes archivées depuis longtemps, le listing devient un frein à la productivité quotidienne des équipes.

La tentation initiale serait de supprimer directement les lignes dans la table ps_orders. C'est une très mauvaise idée dans la majorité des cas : les commandes sont liées à de nombreuses tables (détails produits, historique de statuts, factures, avoirs, paiements) et leur suppression brutale peut créer des incohérences en base de données, voire des obligations légales non respectées.

La solution propre consiste à ajouter un mécanisme de masquage réversible, sans toucher aux données réelles.

La solution : un champ `active` et un override du contrôleur

Le principe est simple et éprouvé :

1. Ajouter une colonne `active` à la table `ps_orders`
2. Créer un override de `AdminOrdersController` qui filtre sur ce champ
3. Les commandes marquées `active = 0` disparaissent du listing, mais restent intactes en base

Étape 1 : Ajouter la colonne en base de données

Exécutez cette requête SQL via phpMyAdmin ou en ligne de commande :

ALTER TABLE `ps_orders`
ADD COLUMN `active` TINYINT(1) UNSIGNED NOT NULL DEFAULT 1
AFTER `date_upd`;

Points importants :

• `DEFAULT 1` garantit que toutes les commandes existantes et futures restent visibles par défaut
• `TINYINT(1) UNSIGNED` est le type standard pour un booléen dans PrestaShop
• Adaptez le préfixe `ps_` si vous utilisez un préfixe personnalisé

Conseil : Sur une boutique avec un volume important de commandes (> 100 000 lignes), ajoutez également un index sur cette colonne pour optimiser les performances du filtre :

ALTER TABLE `ps_orders`
ADD INDEX `idx_active` (`active`);

Étape 2 : Déclarer la propriété dans la classe Order

Pour que PrestaShop reconnaisse ce nouveau champ, il faut étendre la définition de l'objet Order.

PrestaShop 1.6 / 1.7 : Créez le fichier override/classes/Order.php :

<?php
/**
 * @author Alexandre Carette <contact@alexandrecarette.fr>
 * @copyright 2026 Alexandre Carette
 * @license Propriétaire et Confidentiel
 */

class Order extends OrderCore
{
    /** @var bool Commande active (visible dans le BO) */
    public $active = 1;

    public static $definition = null;

    public function __construct($id = null, $id_lang = null)
    {
        // Copie la définition parente et ajoute le champ
        if (self::$definition === null) {
            self::$definition = OrderCore::$definition;
            self::$definition['fields']['active'] = [
                'type' => self::TYPE_BOOL,
                'validate' => 'isBool',
            ];
        }
        parent::__construct($id, $id_lang);
    }
}

PrestaShop 8.x : Le mécanisme d'override reste identique, mais pensez à vider le cache des classes après création :

rm -f var/cache/prod/class_index.php
rm -f var/cache/dev/class_index.php

Étape 3 : Override du contrôleur AdminOrdersController

Créez le fichier override/controllers/admin/AdminOrdersController.php :

<?php
/**
 * @author Alexandre Carette <contact@alexandrecarette.fr>
 * @copyright 2026 Alexandre Carette
 * @license Propriétaire et Confidentiel
 */

class AdminOrdersController extends AdminOrdersControllerCore
{
    public function __construct()
    {
        parent::__construct();

        // Filtrer uniquement les commandes actives
        $this->_where .= ' AND a.`active` = 1';

        // Ajouter la colonne "active" dans la liste pour pouvoir filtrer manuellement
        $this->fields_list['active'] = [
            'title' => $this->trans('Visible', [], 'Admin.Global'),
            'align' => 'text-center',
            'active' => 'status',
            'type' => 'bool',
            'orderby' => false,
            'filter_key' => 'a!active',
        ];
    }
}

Ce que fait cet override :

• `$this->_where .= ' AND a.active = 1'` : ajoute une clause WHERE à la requête SQL du listing, excluant les commandes inactives
• `$this->fields_list['active']` : ajoute une colonne dans le tableau avec un toggle booléen, permettant de réactiver une commande directement depuis le listing si besoin

Important : Utilisez $this->_where .= (concaténation) et non $this->_where = (affectation) pour ne pas écraser d'éventuels filtres existants.

Étape 4 : Masquer les commandes souhaitées

Pour masquer un lot de commandes (par exemple toutes celles antérieures à 2020 et en statut annulé) :

UPDATE `ps_orders`
SET `active` = 0
WHERE `date_add` < '2020-01-01'
AND `current_state` IN (6, 7, 8);

Les statuts 6 (annulé), 7 (remboursé) et 8 (erreur de paiement) sont les candidats typiques au masquage. Vérifiez les ID de vos statuts dans la table ps_order_state avant d'exécuter.

Étape 5 : Vider le cache

Après tout override, videz le cache PrestaShop :

# PrestaShop 1.6
rm -rf cache/class_index.php

# PrestaShop 1.7 / 8.x
rm -rf var/cache/*
# ou depuis le back-office : Paramètres avancés > Performances > Vider le cache

Approche alternative : la suppression en base (à éviter)

Il est techniquement possible de supprimer des commandes directement en base de données. Cette approche est fortement déconseillée pour plusieurs raisons :

• **Intégrité référentielle** : une commande est liée à `ps_order_detail`, `ps_order_history`, `ps_order_payment`, `ps_order_invoice`, `ps_order_cart_rule`, etc. Supprimer uniquement dans `ps_orders` laisse des orphelins
• **Obligations comptables** : en France, les factures émises doivent être conservées 10 ans. Supprimer une commande facturée est potentiellement illégal
• **Irréversibilité** : contrairement au champ `active`, une suppression est définitive

Si malgré tout vous devez nettoyer la base (environnement de test, commandes de test pré-production), voici l'ordre de suppression sécurisé :

-- UNIQUEMENT en environnement de test !
-- Sauvegardez TOUJOURS votre base avant
SET @order_id = 12345;

DELETE FROM `ps_order_detail` WHERE `id_order` = @order_id;
DELETE FROM `ps_order_history` WHERE `id_order` = @order_id;
DELETE FROM `ps_order_payment` WHERE `order_reference` = (
    SELECT `reference` FROM `ps_orders` WHERE `id_order` = @order_id
);
DELETE FROM `ps_order_invoice` WHERE `id_order` = @order_id;
DELETE FROM `ps_order_cart_rule` WHERE `id_order` = @order_id;
DELETE FROM `ps_orders` WHERE `id_order` = @order_id;

Variante avancée : archivage avec date

Pour aller plus loin, vous pouvez remplacer le simple booléen par une date d'archivage, ce qui permet de tracer quand et pourquoi une commande a été masquée :

ALTER TABLE `ps_orders`
ADD COLUMN `archived_at` DATETIME DEFAULT NULL
AFTER `date_upd`;

ALTER TABLE `ps_orders`
ADD INDEX `idx_archived` (`archived_at`);

Et dans l'override du contrôleur :

$this->_where .= ' AND a.`archived_at` IS NULL';

Cette approche est plus riche car elle conserve l'historique d'archivage et permet des requêtes du type « commandes archivées ce mois-ci ».

Récapitulatif

MéthodeRéversibleSûreEffort Champ `active` + overrideOuiOuiMoyen Archivage avec dateOuiOuiMoyen+ Suppression SQL directeNonNonFaible mais risqué

La méthode par override est celle que je recommande systématiquement en production. Elle respecte l'intégrité des données, reste compatible avec les mises à jour PrestaShop, et offre une flexibilité totale pour réactiver des commandes si nécessaire.