DataFirefly Staging Pro — Guide complet
Cloner, tester et pousser en production : installation, création d'un staging, options de protection, push sélectif et rollback pour PrestaShop 8 et 9.
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
- Téléchargez l’archive
dfstagingpro.zipdepuis votre compte DataFirefly. - Back-office PrestaShop → Modules → Téléverser un module → envoyez le ZIP.
- À l’installation, le module crée ses tables
df_staging_envetdf_staging_log, enregistre ses hooks et ajoute l’onglet Paramètres avancés → Staging Pro.
Compatible PrestaShop 8.0 à 9.x. PHP doit pouvoir écrire à la racine de la boutique (création du sous-dossier de staging) et l’utilisateur MySQL doit pouvoir CREATE, DROP et RENAME TABLE — ce qui est le cas d’une installation PrestaShop standard. Aucune dépendance Composer.
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 :
- Saisissez un nom (minuscules, chiffres et tirets uniquement, par exemple
v2). L’URL du staging seravotre-boutique.com/staging-v2/. - Choisissez vos options de protection et de copie (voir ci-dessous).
- 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.
- 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.
Dès sa création, tout staging reçoit automatiquement un en-tête X-Robots-Tag: noindex, une meta noindex et un robots.txt bloquant, ainsi qu’une bannière orange STAGING sur le front-office et dans le back-office. Vos environnements de test ne risquent pas d’être indexés par Google.
L’option symlink img/ partage le dossier d’images avec la production : modifier ou supprimer une image côté staging affecte aussi la boutique en ligne. À réserver aux tests qui ne touchent pas aux images.
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.
Si la page est fermée pendant la création, l’environnement reste en cours et reprend automatiquement la copie à la réouverture du tableau de bord, exactement là où elle s’était arrêtée.
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 :
- Cliquez sur Push sur la ligne de l’environnement : la liste des tables s’affiche, avec le nombre de lignes de chacune.
- Cochez précisément les tables à transférer.
- 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.
Le push modifie votre boutique en production. Le backup automatique protège les tables remplacées, mais vérifiez toujours votre sélection. Évitez de pousser les tables de commandes ou de clients si la production a continué à enregistrer des ventes depuis la création du staging.
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.
Une fois un push validé et stable, supprimez les anciennes tables dfbak* (via phpMyAdmin ou tout client SQL) pour libérer de l’espace dans votre base de données.
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.txtdans un sous-dossier n’étant pas honoré par les moteurs, la vraie protection anti-indexation repose sur l’en-têteX-Robots-Taget la metanoindex; l’option.htpasswdreste 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.
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.