PS PrestaShop Intermédiaire

DataFirefly Staging Pro — Guide complet

Créer, protéger et envoyer en production un staging PrestaShop 8 et 9 : assistant en 4 étapes, vérification de l'espace disque, progression en direct, sauvegardes et annulation.

Mis à jour Version du module 2.0.0

Staging Pro crée une copie complète de votre boutique (fichiers et base de données) pour tester modules, thèmes et mises à jour sans risque, puis renvoyer vos modifications en production. Depuis la version 2.0.0, l’espace disque est vérifié avant et pendant la copie : la copie ne peut plus remplir le disque de votre hébergement. Ce guide couvre l’installation, l’assistant de création, la sécurité de l’espace disque, la protection du staging, l’envoi en production, les sauvegardes et le dépannage.

Installation et mise à jour

  1. Téléchargez dfstagingpro-2.0.0.zip depuis votre compte DataFirefly.
  2. Back-office PrestaShop → Modules → Gestionnaire de modules → Téléverser un module, puis envoyez le ZIP.
  3. Ouvrez Paramètres avancés → Staging Pro.

Pour mettre à jour depuis la version 1.x, téléversez simplement le nouveau ZIP. La mise à jour ajoute les nouvelles colonnes, les nouveaux hooks et les réglages par défaut, et retire des anciens journaux les mots de passe HTTP qui y figuraient en clair. Vos staging existants restent listés, avec un badge « 1.x », et restent gérables : actualiser, envoyer en production, annuler, supprimer.

Compatible PrestaShop 8.0 à 9.x. PHP doit pouvoir écrire dans le dossier de la boutique et l’utilisateur MySQL doit avoir les droits CREATE, DROP, ALTER et INSERT, ce qui est le cas d’une installation standard. Aucune dépendance Composer.

Le tableau de bord

La page du module affiche en haut cinq indicateurs : nombre d’environnements, espace utilisé par les staging, espace disque libre, durée de la dernière copie et sauvegardes de push. Les onglets donnent accès aux environnements, à l’assistant de création, aux sauvegardes et aux paramètres.

Chaque environnement est présenté sur une carte : adresse du staging, dossier, préfixe des tables, taille (fichiers et base), date et durée de la dernière copie, badges de protection, identifiant et mot de passe HTTP (masqué, avec boutons Afficher et Copier) et lien d’accès privé. Les actions disponibles sont Ouvrir, Actualiser, Envoyer en production, Annuler le dernier envoi, Journal et Supprimer.

Liste des environnements de staging PrestaShop avec taille, protections, accès et actions
Liste des environnements

Une copie qui a échoué reste visible avec la raison de l’échec, par exemple un manque d’espace disque, et la confirmation que la copie partielle a été supprimée. Le bouton Réessayer relance les pré-vérifications puis la copie.

Créer un staging : l’assistant en 4 étapes

Étape 1 : emplacement

Saisissez un nom (minuscules, chiffres et tirets, par exemple v2). L’adresse du staging s’affiche en direct. Choisissez ensuite :

  • Sous-dossier de votre boutique (recommandé) : le staging est créé dans /staging-nom/, rien à configurer.
  • Dossier et adresse personnalisés : pour un sous-domaine comme staging.example.com, créé d’abord dans votre panneau d’hébergement et pointant vers un dossier vide.
  • Même base de données, préfixe de tables propre (dfs1_, dfs2_…), ou Base de données séparée sur le même serveur, à créer au préalable et à ouvrir à l’utilisateur MySQL de la boutique.
Assistant de nouveau staging : sous-dossier ou sous-domaine, même base ou base distincte
Assistant de nouveau staging

Étape 2 : données et protection

  • Ignorer les données statistiques (coché par défaut) : visites, connexions et journaux ne sont pas copiés, les tables sont créées vides.
  • Ignorer les données clients (RGPD) : clients, adresses, commandes, paniers et messages ne sont pas copiés.
  • Partager les images avec la boutique en ligne : le dossier img/ est lié au lieu d’être copié. Gros gain d’espace, mais une image modifiée sur le staging l’est aussi sur la boutique.
  • Mot de passe HTTP (.htpasswd) (Apache, LiteSpeed), Lien d’accès privé (tous serveurs, nginx compris) et Mode maintenance.
  • Désactiver les modules de paiement en ligne : les modules de paiement en ligne sont désactivés sur le staging. Les moyens hors ligne (virement, chèque, paiement à la livraison) restent disponibles pour passer des commandes de test.
  • Modules sensibles : les modules actifs de la liste (tâches cron, synchronisations ERP ou newsletter, suivi, facturation récurrente) sont proposés à la désactivation, sur le staging uniquement.

Trois protections sont toujours actives : noindex, blocage de tous les e-mails et bandeau STAGING.

Options du staging : données clients, mot de passe, lien privé, paiements et modules sensibles désactivés
Données et protection

Étape 3 : pré-vérifications

Le module analyse votre boutique : les fichiers sont mesurés sans être lus, ce qui prend quelques secondes même pour une grosse boutique, puis la taille de la base est lue dans information_schema. Le rapport affiche :

  • l’espace disque nécessaire et disponible, avec une jauge (taille de la copie, marge de sécurité, espace laissé libre pour la boutique) ;
  • l’espace du disque de la base de données, quand le serveur MySQL est local et mesurable ;
  • la taille estimée (fichiers et base) et, si une copie a déjà été mesurée sur votre boutique, la durée estimée ;
  • les contrôles : nom, droits d’écriture, droits MySQL, limites PHP, extensions, serveur web ;
  • les plus gros dossiers, que vous pouvez exclure d’un clic, et des suggestions pour gagner de la place.
Pré-vérifications avant la copie de staging : espace disque, base de données, limites PHP et taille estimée
Pré-vérifications avant la copie

Étape 4 : copie

Cliquez sur Créer le staging. La copie démarre et sa progression s’affiche sur la carte de l’environnement (voir « Suivre la copie en direct »).

Espace disque : comment le module protège votre boutique

Le staging est créé sur le même disque que votre boutique. Un disque plein peut bloquer la boutique en production : cache, sessions, envois de fichiers, factures. Staging Pro applique donc trois protections.

  1. Avant la copie : l’espace nécessaire est calculé ainsi : taille des fichiers à copier (caches, journaux, sessions, sauvegardes et autres staging exclus) + taille de la base + marge de sécurité (10 %, 50 Mo minimum) + espace toujours laissé libre pour la boutique (500 Mo par défaut). Si l’espace libre ne suffit pas, la copie est refusée avec trois chiffres : nécessaire, disponible, manquant. Le contrôle est refait au démarrage de la copie.
  2. Pendant la copie : l’espace libre est remesuré en continu. La copie s’arrête avant de descendre sous l’espace réservé à la boutique. Chaque écriture est contrôlée : un disque plein, côté fichiers ou côté MySQL, arrête la copie avec un message clair.
  3. Après un échec ou un arrêt : la copie partielle (dossier et tables) est supprimée automatiquement. Rien ne reste sur le disque ni dans la base, et la boutique en production n’est jamais modifiée.
Espace disque insuffisant : copie bloquée avec espace nécessaire, disponible et manquant, et suggestions
Espace disque insuffisant

Quand l’espace manque, le rapport propose des solutions chiffrées : partager les images, ignorer les statistiques ou les données clients, exclure un gros dossier, vider le cache (bouton), supprimer les anciens journaux de var/logs, supprimer d’anciens staging ou d’anciennes sauvegardes de push.

Sur certains hébergements mutualisés, la fonction PHP disk_free_space est désactivée et l’espace libre ne peut pas être mesuré. Le module l’indique clairement, affiche la taille approximative de la copie et vous demande de cocher une confirmation après avoir vérifié l’espace dans votre panneau d’hébergement. Les échecs d’écriture restent détectés et nettoyés.

Suivre la copie en direct

Pendant la copie, la carte de l’environnement affiche :

  • les étapes : pré-vérifications, préparation, fichiers, base de données, URL, protection, vérification ;
  • une barre de progression ;
  • le nombre de fichiers et d’octets copiés ;
  • les tables clonées ;
  • le temps écoulé et le temps restant estimé à partir de l’avancement réel ;
  • les dernières lignes du journal.

Le bouton Arrêter interrompt la copie et supprime la copie partielle.

Progression en direct de la copie de staging : étapes, fichiers, temps écoulé et restant, journal en direct
Progression de la copie en direct

La copie avance par lots de quelques secondes : aucun délai d’expiration, même avec un max_execution_time bas. Si vous fermez la page, la copie se met en pause et reprend à la réouverture du tableau de bord, exactement là où elle s’était arrêtée.

Protection du staging

  • Noindex : en-tête X-Robots-Tag envoyé par PHP sur toutes les pages (fonctionne même sans mod_headers et sous nginx), balise meta noindex et robots.txt.
  • Aucun e-mail ne sort : PS_MAIL_METHOD = 3 et blocage par le module de tout envoi, même si quelqu’un réactive le SMTP sur le staging. Le bandeau du back-office du staging affiche le nombre d’e-mails bloqués.
  • Mot de passe HTTP (utilisateur staging), généré ou choisi, au format APR1 lu par Apache et LiteSpeed. Une auto-vérification à la fin de la copie contrôle que le serveur répond bien 401 sans identifiants.
  • Lien d’accès privé : sans le lien secret, les visiteurs voient une page « staging privé ». Le lien pose un cookie valable 30 jours.
  • Paiements en ligne et modules sensibles désactivés, et bandeau STAGING sur le front et le back-office.

Actualiser, réessayer, supprimer

  • Actualiser : reconstruit le staging depuis l’état actuel de la boutique. Une fenêtre affiche d’abord les pré-vérifications. L’espace libéré par la suppression de l’ancienne copie est pris en compte. Si l’espace manque, l’actualisation n’est pas lancée et la copie actuelle est conservée.
  • Réessayer : relance une copie qui a échoué, après de nouvelles pré-vérifications.
  • Supprimer : supprime le dossier et les tables du staging. Hors du dossier de la boutique, seul un dossier portant le marqueur de l’environnement est supprimé.

Envoyer en production

Le bouton Envoyer en production ouvre la liste des tables du staging, groupées par catégorie : catalogue, contenu et design, modules, clients et commandes, autres. Pour chaque table, vous voyez le nombre de lignes du staging et de la boutique. Une recherche et un filtre « tables différentes » facilitent la sélection.

Envoi des tables choisies du staging vers la production, échange atomique et sauvegarde automatique
Envoi en production

Les tables choisies sont d’abord copiées à part, avec la réécriture des URL du staging vers la boutique. Elles sont ensuite échangées en une seule opération atomique (RENAME TABLE) : la boutique ne voit jamais une table vide ou à moitié remplie. Les tables remplacées sont conservées en sauvegarde (dfbak…). Si l’envoi échoue avant l’échange, les tables temporaires sont supprimées et la boutique n’est pas touchée.

Évitez d’envoyer les tables de clients et de commandes si la boutique a continué à recevoir des commandes depuis la copie : elles remplaceraient les commandes récentes. Les tables critiques (shop_url, configuration, shop, sessions) ne peuvent jamais être envoyées.

Sauvegardes et annulation

L’onglet Sauvegardes liste les sauvegardes créées par les envois, avec leur date, leur nombre de tables, leur taille et l’environnement concerné. Le bouton Annuler le dernier envoi, sur la carte de l’environnement, restaure les tables d’origine. Supprimez les sauvegardes dont vous n’avez plus besoin pour libérer de l’espace dans la base.

Sauvegardes des envois : annuler le dernier envoi ou supprimer les anciennes sauvegardes
Sauvegardes des envois

Journal

Chaque environnement a son journal, dans la langue de l’employé : pré-vérifications, étapes, avertissements, erreurs et nettoyages. Un filtre affiche uniquement les avertissements et les erreurs. Le bouton Télécharger (.txt) exporte le journal complet avec un en-tête utile au support (versions, adresses, espace libre). Les mots de passe n’apparaissent jamais dans le journal.

Journal lisible et téléchargeable d'un environnement de staging
Journal de l’environnement

Paramètres

  • Espace libre toujours conservé pour la boutique en ligne (500 Mo par défaut) : la copie est refusée, ou arrêtée, avant de descendre sous cette valeur.
  • Marge de sécurité sur l’estimation (10 %, 50 Mo minimum).
  • Durée d’un lot (6 secondes par défaut, de 2 à 25).
  • Dossiers à exclure en plus des exclusions automatiques (caches, journaux, sessions, sauvegardes du back-office, autres staging).
  • Modules sensibles proposés à la désactivation sur le staging.
Réglages : espace laissé libre pour la boutique, marge de sécurité, durée des lots, exclusions
Réglages

Staging sans données clients

Avec l’option Ignorer les données clients (RGPD), les tables de clients, commandes, paniers, messages, invités, newsletter et journaux RGPD sont créées vides. Les adresses de fournisseurs, fabricants et entrepôts sont conservées, ainsi que les tables de configuration des commandes (états, modèles de messages, états de retour) et l’ensemble du catalogue. C’est le choix recommandé pour confier un staging à un prestataire. Sur un tel staging, les tables clients et commandes sont retirées de la liste d’envoi et refusées par le serveur : une table vide ne peut jamais écraser la production.

Droits et sécurité

  • Les actions suivent les droits de l’onglet Paramètres avancés → Staging Pro : voir, ajouter (créer), modifier (copier, envoyer, annuler, paramètres) et supprimer. Un employé en lecture seule ne voit ni les mots de passe ni les boutons d’action.
  • Toutes les actions sont bloquées si la boutique courante est elle-même un staging.
  • Les fichiers parameters.php, .env et .htpasswd du staging ne sont pas accessibles depuis le web.

FAQ et dépannage

Que se passe-t-il si mon disque n’a pas assez de place ? La copie est refusée avant de commencer, avec l’espace nécessaire, disponible et manquant, et des solutions pour gagner de la place. Si l’espace disparaît pendant la copie, celle-ci s’arrête avant de remplir le disque et la copie partielle est supprimée automatiquement.

Mon hébergeur désactive disk_free_space, puis-je utiliser le module ? Oui. Le module affiche la taille approximative de la copie et demande une confirmation. Les échecs d’écriture restent détectés et nettoyés.

La copie s’est interrompue (page fermée, coupure réseau). Rouvrez le tableau de bord : la copie reprend là où elle s’était arrêtée.

Mon serveur est sous nginx : le mot de passe HTTP ne fonctionne pas. nginx ignore les fichiers .htaccess. Utilisez le lien d’accès privé, qui fonctionne sur tous les serveurs. L’auto-vérification signale le cas dans le journal.

Le staging peut-il envoyer des e-mails à mes clients ? Non. Les e-mails sont toujours bloqués sur le staging, même si quelqu’un réactive le SMTP.

Puis-je tester une commande sur le staging ? Oui : les paiements en ligne sont désactivés, mais le virement et le chèque restent disponibles.

Après un envoi en production, comment revenir en arrière ? Utilisez Annuler le dernier envoi sur la carte de l’environnement, puis supprimez les anciennes sauvegardes dans l’onglet Sauvegardes.

Mes staging créés en 1.x sont-ils conservés ? Oui. Ils restent listés après la mise à jour et peuvent être actualisés, envoyés en production ou supprimés.

Le staging répond 404 partout sur un hébergement cPanel / LiteSpeed. Mettez le module à jour puis actualisez l’environnement : le mot de passe est généré au format APR1, compatible LiteSpeed, et la page 401 est intégrée au .htaccess.

Historique des versions

2.0.0 (1er novembre 2026)

  • Vérification de l’espace disque avant la copie (fichiers, base, marge, espace réservé à la boutique), surveillance pendant la copie, détection du disque plein côté fichiers et MySQL, nettoyage automatique de la copie partielle.
  • Assistant en 4 étapes avec rapport de pré-vérification, exclusion des plus gros dossiers et suggestions.
  • Progression en direct par étapes, arrêt manuel, reprise après interruption, journal traduit et téléchargeable.
  • Envoi en production atomique, onglet Sauvegardes.
  • Sous-domaine (dossier et adresse personnalisés) et base de données séparée.
  • Lien d’accès privé, noindex envoyé par PHP, e-mails toujours bloqués, modules sensibles désactivés, moyens de paiement hors ligne conservés.
  • Droits vérifiés par action, mots de passe retirés du journal, multiboutique, traductions en 8 langues.

1.1.0 (4 septembre 2026)

  • Option « Sans données clients ».

1.0.1 (3 septembre 2026)

  • Mot de passe HTTP au format APR1-MD5, page 401 intégrée, ErrorDocument réécrit, auto-vérification de fin de copie.

1.0.0 (11 juin 2026)

Première version publique.

Cette page vous a-t-elle été utile ?

Toujours bloqué ? Contactez le support