DataFirefly Staging Pro — Guide complet

Staging Pro crée une copie complète de votre boutique (fichiers + base de données) dans un sous-dossier protégé de votre hébergement actuel, sans aucun timeout grâce à son moteur de copie par lots. Vous testez modules, thèmes et mises à jour en toute sécurité, puis renvoyez vos modifications en production table par table, avec backup automatique et rollback en un clic. Ce guide couvre l’installation, la création d’un staging, les options de protection, le push vers la production et le rollback.

Installation

1. Téléchargez l’archive dfstagingpro.zip depuis votre compte DataFirefly.
2. Back-office PrestaShop → Modules → Téléverser un module → envoyez le ZIP.
3. À l’installation, le module crée ses tables df_staging_env et df_staging_log, enregistre ses hooks et ajoute l’onglet Paramètres avancés → Staging Pro.

Comment fonctionne le staging

Un environnement de staging est créé dans un sous-dossier à la racine de votre boutique (par exemple /staging-v2/) et utilise un préfixe de tables dédié (par exemple dfs1_) dans la même base de données que la production. Vous n’avez donc besoin ni d’un second serveur, ni d’un nouvel accès MySQL, ni d’une configuration DNS.

Le moteur de copie travaille par lots de quelques secondes puis rend la main, en reprenant exactement où il s’était arrêté : copie des fichiers via une file d’attente persistante, clonage de la base par paquets de lignes. Une boutique de plusieurs gigaoctets se clone ainsi sans erreur, même sur un hébergement mutualisé avec un max_execution_time bas.

Créer un staging

Rendez-vous dans Paramètres avancés → Staging Pro, puis dans le panneau de création :

1. Saisissez un nom (minuscules, chiffres et tirets uniquement, par exemple v2). L’URL du staging sera votre-boutique.com/staging-v2/.
2. Choisissez vos options de protection et de copie (voir ci-dessous).
3. Cliquez sur Créer. La progression s’affiche en direct avec une barre d’avancement.

À la fin du processus, l’URL du staging et, le cas échéant, les identifiants htpasswd s’affichent sur la ligne de l’environnement.

Options de protection et de copie

• Protéger avec .htpasswd : ajoute une authentification HTTP (utilisateur staging). Le mot de passe peut être saisi ou généré automatiquement, puis affiché sur le tableau de bord.
• Désactiver les e-mails : coupe les e-mails sortants du staging (PS_MAIL_METHOD = 3). Aucun risque d’écrire à un vrai client.
• Désactiver les paiements : désactive et déshooke les modules de paiement connus sur le staging.
• Ignorer les statistiques : exclut de la copie les tables volumineuses et non essentielles (connexions, logs, paniers abandonnés…) pour une copie beaucoup plus rapide.
• Sans données clients : crée vides sur le staging les tables de clients, adresses clients, commandes, paniers, messages, invités, newsletter et logs RGPD. Les adresses fournisseurs, fabricants et entrepôts sont conservées, ainsi que les tables de configuration des commandes (états, modèles de messages, états de retour, règles panier). Voir la section dédiée plus bas.
• Symlink du dossier img/ : crée un lien symbolique vers les images au lieu de les copier, pour une énorme économie d’espace disque.
• Mode maintenance : place le staging en maintenance avec votre IP d’administration en liste blanche.

Le moteur de copie par lots

La création d’un staging enchaîne plusieurs étapes, chacune budgétée en temps et reprise automatiquement : préparation, copie des fichiers, clonage de la base de données, réécriture des URLs, configuration et protection, puis finalisation. La réécriture d’URL couvre shop_url, la configuration (y compris les valeurs sérialisées et JSON, traitées sans corruption), ainsi que les contenus CMS, produits, catégories, marques, fournisseurs et magasins.

Rafraîchir, multi-environnements et suppression

• Refresh : reconstruit un staging existant depuis l’état actuel de la production (suppression puis recréation du dossier et du préfixe), en un clic.
• Multi-environnements : créez autant de stagings que nécessaire (v2, hotfix, test-module…), chacun indépendant.
• Suppression : supprime le dossier et les tables d’un environnement de façon budgétée, sans timeout.

Pousser vers la production

Une fois vos tests validés, le bouton Push permet de renvoyer vos modifications en production, table par table :

1. Cliquez sur Push sur la ligne de l’environnement : la liste des tables s’affiche, avec le nombre de lignes de chacune.
2. Cochez précisément les tables à transférer.
3. Confirmez. Avant chaque remplacement, la table de production correspondante est sauvegardée automatiquement par un renommage horodaté vers un préfixe dfbak{horodatage}_.

Les URLs sont réécrites dans le sens staging → production lors du transfert. Les tables critiques (shop_url, configuration, shop, sessions et tables du module) sont protégées et ne peuvent jamais être poussées.

Rollback

Le bouton Rollback restaure la production depuis le dernier backup de push, en un clic. Le module renomme les tables de sauvegarde dfbak…_ pour reprendre leur place d’origine.

Garde-fous et journal

• Toutes les actions sont bloquées si la boutique courante est elle-même un staging, pour éviter les manipulations en cascade.
• Un journal détaillé est disponible par environnement via le bouton Logs.
• Le robots.txt dans un sous-dossier n’étant pas honoré par les moteurs, la vraie protection anti-indexation repose sur l’en-tête X-Robots-Tag et la meta noindex ; l’option .htpasswd reste la protection la plus sûre.

Compatibilité et notes techniques

• PrestaShop 8.0 à 9.x, compatible hébergement mutualisé et multilingue.
• Contrôleur d’administration legacy (pas de contrôleur Symfony) pour la compatibilité PS8/PS9.
• Endpoints AJAX back-office via le 4ᵉ argument de getAdminLink() ; rendu JSON par une méthode dédiée.
• Staging = sous-dossier à la racine + préfixe de tables dfs{id}_ dans la même base MySQL.
• Backups de push horodatés sous le préfixe dfbak{YmdHis}_, à purger après validation.

Staging sans données clients

L’option Sans données clients, disponible depuis la version 1.1.0, crée le staging sans aucune donnée personnelle. Les tables concernées sont bien créées, avec leur structure exacte, mais restent vides. C’est le choix recommandé pour confier un staging à un prestataire externe, pour un test de thème ou de module qui ne touche pas au tunnel de commande, et pour limiter la surface RGPD de vos environnements de test.

Ce qui n’est pas copié

• Clients, groupes de clients, fils de discussion et messages du SAV, sessions clients, invités et statistiques de connexion.
• Commandes et toute la famille associée : détails, historique, factures, paiements, transporteurs, règles panier appliquées, avoirs et retours.
• Paniers, produits des paniers, listes d’envies, messages, inscriptions à la newsletter, logs RGPD et logs de mails.
• Adresses des clients : la table address est copiée avec un filtre, seules les lignes rattachées à un client sont écartées.

Ce qui est conservé

• Adresses de fournisseurs, fabricants, entrepôts et magasins.
• Tables de configuration des commandes : états de commande et leurs traductions, modèles de messages, états de retour, types d’avoirs.
• Règles panier, bons de réduction, transporteurs, taxes et l’ensemble du catalogue.
• Employés du back-office : vous vous connectez au staging avec vos identifiants habituels.

Authentification HTTP et hébergements cPanel / LiteSpeed

Depuis la version 1.0.1, le fichier .htpasswd est généré au format APR1-MD5 (celui de la commande htpasswd -m), lu par Apache, LiteSpeed et nginx. La version 1.0.0 utilisait bcrypt, que LiteSpeed (très courant derrière cPanel, par exemple chez o2switch) ne sait pas lire : le staging répondait alors 404 sur toutes ses pages.

Le bloc de protection ajoute aussi une page d’erreur 401 inline. Sur cPanel, l’erreur 401 est redirigée globalement vers /401.shtml, une page qui n’existe pas dans PrestaShop : la sous-requête tombe dans le dispatcher de la production et renvoie sa page 404, si bien que le navigateur n’affiche jamais la boîte de connexion. La page inline court-circuite cette redirection.

Enfin, la ligne ErrorDocument 404 du .htaccess copié est réécrite vers le sous-dossier de staging : une erreur sur le staging affiche la page 404 du staging, et non celle de la production.

Auto-vérification à la création

À la fin de la configuration, le module envoie une requête HEAD sur le robots.txt du staging, avec les identifiants si la protection est active, puis sans identifiants pour vérifier que le serveur répond bien 401. Le résultat est consigné dans les logs de l’environnement :

• 200 avec identifiants et 401 sans : tout est en ordre.
• Le serveur refuse le bloc d’authentification : le module retire le bloc et le .htpasswd, désactive l’option et affiche « Ready with warning » sur la ligne de l’environnement. Le staging est alors accessible sans mot de passe ; activez le mode maintenance.
• Code 0 : le serveur ne peut pas s’appeler lui-même (requêtes sortantes bloquées). Ouvrez l’URL du staging manuellement.

FAQ et dépannage

Le module fonctionne-t-il sur un hébergement mutualisé ? Oui. Le moteur de copie par lots avec reprise automatique évite tout timeout, quel que soit le max_execution_time du serveur.

La création s’est interrompue, que faire ? Rouvrez le tableau de bord Staging Pro : l’environnement reprend automatiquement la copie là où elle s’était arrêtée.

Le staging peut-il envoyer des e-mails à mes clients ? Non si l’option « Désactiver les e-mails » est active (recommandé) : les e-mails sortants sont coupés sur le staging.

Après un push, comment annuler ? Utilisez le bouton Rollback, qui restaure le dernier backup automatique. Pensez ensuite à purger les tables dfbak* obsolètes.

Puis-je créer plusieurs stagings en même temps ? Oui, le nombre d’environnements est illimité et chacun est totalement indépendant.

Le staging répond 404 partout, ou la boîte de connexion ne s’affiche pas ? C’est le symptôme corrigé en 1.0.1 sur les hébergements cPanel / LiteSpeed. Mettez le module à jour puis relancez un Refresh de l’environnement ; consultez la section « Authentification HTTP et hébergements cPanel / LiteSpeed » ci-dessus.

Puis-je créer un staging sans les données de mes clients ? Oui, cochez « Sans données clients » à la création. Voir la section « Staging sans données clients » ci-dessus.

Historique des versions

1.1.0 (4 septembre 2026)

• Nouvelle option « Sans données clients » : clients, adresses clients, commandes, paniers, messages, invités, newsletter et logs RGPD créés vides sur le staging.
• Adresses fournisseurs, fabricants et entrepôts conservées, ainsi que les tables de configuration des commandes.
• Garde-fou de push : ces tables sont retirées de la liste et refusées côté serveur sur un staging créé sans données clients.

1.0.1 (3 septembre 2026)

• Protection htpasswd : hash généré en APR1-MD5, compatible Apache et LiteSpeed (bcrypt était rejeté sur certains hébergements cPanel, rendant le staging inaccessible).
• Boîte de connexion HTTP : page 401 inline, pour les hébergements qui redirigent les erreurs 401 vers une page inexistante.
• Ligne ErrorDocument du .htaccess réécrite vers le sous-dossier de staging.
• Auto-vérification à la fin de la création : contrôle HTTP du staging, retrait automatique de la protection si le serveur la refuse et avertissement dans le dashboard.

1.0.0 (11 juin 2026)

Première version publique.