DfPreorder SW — Guide complet

Shopware ne propose nativement aucune fonction « Prévenez-moi quand c’est de nouveau en stock ». DfPreorder SW comble ce manque : sur chaque fiche produit en rupture, un formulaire d’inscription apparaît automatiquement, et le client reçoit une alerte par e-mail — dans sa propre langue — dès que le produit revient. Le plugin ajoute aussi un mode précommande léger (badge et date d’expédition prévue) et un module d’administration pour suivre les inscriptions. Un seul et même ZIP s’installe sur Shopware 6.5, 6.6 et 6.7. Ce guide couvre l’installation, la compilation des assets, le worker et la tâche planifiée, la configuration, l’usage storefront, le mode précommande, les e-mails, la Store API, la conformité RGPD et le dépannage.

Comment fonctionne la détection du retour en stock

DfPreorder détecte les réapprovisionnements de deux façons complémentaires, qui convergent vers un même traitement idempotent — vos clients sont donc toujours prévenus, jamais deux fois :

• En temps réel : un abonné écoute l’écriture des produits et réagit dès que le stock ou le stock disponible change.
• Balayage planifié : une tâche planifiée s’exécute toutes les 15 minutes et rattrape les mises à jour de stock effectuées en SQL direct — typiquement la décrémentation du stock disponible au passage d’une commande, ou un import ERP, qui ne déclenchent pas d’événement applicatif.

Le formulaire de liste d’attente s’affiche sur une fiche produit lorsque deux conditions sont réunies : le produit est en mode « épuisé masque la disponibilité » (closeout) et son stock disponible est tombé à zéro.

Installation

1. Téléchargez l’archive DfPreorder-v1.0.0.zip depuis votre compte DataFirefly.
2. Copiez le dossier décompressé DfPreorder dans custom/plugins/, ou installez le ZIP via Administration → Extensions → Mes extensions → Charger l’extension.
3. Installez et activez le plugin :

   bin/console plugin:refresh
   bin/console plugin:install --activate DfPreorder

4. Compilez les assets du storefront et de l’administration (étape indispensable, aucun dist n’est fourni) :

   ./bin/build-storefront.sh
   ./bin/build-administration.sh

5. Videz le cache :

   bin/console cache:clear

À l’installation, le plugin crée la table df_stock_notification, le jeu de champs personnalisés df_preorder sur l’entité produit, deux modèles d’e-mail et la tâche planifiée. À la désinstallation sans conservation des données, tout est supprimé.

Worker et tâche planifiée

Pour que les e-mails partent réellement, deux mécanismes doivent tourner — ce qui est généralement déjà le cas en production via l’admin-worker, systemd ou cron :

• Le worker Messenger, qui consomme le message asynchrone de réapprovisionnement et envoie les e-mails ;
• Le planificateur de tâches, qui déclenche le balayage de sécurité toutes les 15 minutes.

bin/console messenger:consume async --time-limit=60
bin/console scheduled-task:run

Configuration

Ouvrez Extensions → Mes extensions → DataFirefly Précommande & Liste d’attente → ⋯ → Configurer. Toutes les options sont réglables par canal de vente grâce au sélecteur natif en haut de la page.

• Activer la liste d’attente : interrupteur principal. Affiche le formulaire sur les fiches en rupture.
• Double opt-in : exige une confirmation par e-mail avant d’activer l’inscription (recommandé pour le RGPD). Désactivé par défaut.
• Autoriser les invités : si désactivé, seuls les clients connectés peuvent s’inscrire.
• Supprimer l’inscription après notification : minimisation des données — l’adresse e-mail est effacée une fois l’alerte envoyée. Si désactivé, l’inscription est conservée avec le statut « notifié ».
• Notifications par lot : nombre maximal d’e-mails envoyés par exécution (worker ou balayage). 100 par défaut.
• Afficher le badge précommande : active l’affichage du badge et de la date d’expédition sur les produits configurés en précommande.

La liste d’attente côté storefront

Lorsqu’un produit est en rupture (closeout + stock disponible à zéro), le formulaire « Être averti du retour en stock » s’affiche automatiquement sous le bouton d’achat. Le client saisit son e-mail (pré-rempli s’il est connecté) et valide.

• La soumission se fait en AJAX avec un repli complet sans JavaScript (message flash + redirection).
• Un champ honeypot invisible filtre les robots.
• Si le double opt-in est activé, un e-mail de confirmation est envoyé ; l’inscription ne devient active qu’après le clic sur le lien de confirmation.
• Chaque e-mail peut contenir un lien de désinscription en un clic.

Mode précommande

Le plugin crée un groupe de champs personnalisés Précommande sur l’entité produit. Ouvrez un produit dans Catalogues → Produits, onglet Spécifications → Champs personnalisés, groupe Précommande :

• Activer la précommande : interrupteur d’activation pour ce produit.
• Date d’expédition prévue : la date affichée dans le badge.
• Note de précommande : texte libre affiché sous le badge.

Quand la précommande est activée et que le badge est autorisé dans la configuration, un badge ambre s’affiche au-dessus du bouton d’achat avec la date d’expédition prévue. Le rendu est isolé dans le template du buy-widget et reste surchargeable.

E-mails et traductions

Deux modèles d’e-mail sont créés à l’installation et traduits en cinq langues — français, anglais, allemand, espagnol et italien :

• Retour en stock (df_preorder.back_in_stock) : variables productName, productUrl et l’objet product complet.
• Confirmation d’inscription (df_preorder.double_opt_in) : ajoute la variable confirmUrl.

Chaque client est notifié dans la langue de la boutique au moment de son inscription : le plugin reconstruit un contexte de langue propre au souscripteur pour résoudre le nom du produit traduit et le bon modèle. L’URL du produit est résolue via l’URL SEO canonique du canal et de la langue concernés.

Les modèles restent entièrement éditables dans Paramètres → E-mails → Modèles d’e-mail. Recherchez « retour en stock » ou « back in stock » pour les retrouver.

Module d’administration

Le menu Marketing → Liste d’attente & Précommande liste toutes les inscriptions : adresse e-mail, produit, statut (en attente / confirmé / notifié), date d’inscription et date de notification. La suppression en masse est disponible, utile pour purger manuellement d’anciennes inscriptions.

Store API (headless / mobile)

Pour les boutiques headless ou les applications mobiles, un point d’entrée Store API permet d’inscrire un client à la liste d’attente :

POST /store-api/df-waitlist/subscribe
Content-Type: application/json
sw-access-key: <votre-clé-d-accès>

{
  "productId": "0189a1b2c3d4...",
  "email": "client@example.com"
}

Une requête valide renvoie une réponse de succès ; un identifiant produit ou un e-mail invalide renvoie une erreur 400. Les mêmes règles de configuration s’appliquent (double opt-in, autorisation des invités, etc.).

Conformité RGPD

• Les adresses e-mail sont collectées uniquement pour la notification demandée.
• Le double opt-in optionnel enregistre un consentement explicite.
• Le comportement par défaut supprime la donnée personnelle dès l’alerte envoyée.
• Un lien de désinscription en un clic peut être inséré dans les modèles d’e-mail.
• La désinstallation avec suppression des données efface la table, les modèles, les champs personnalisés et la configuration.

Compatibilité 6.5 → 6.7 et dépannage

Le formulaire ne s’affiche pas sur un produit en rupture. Vérifiez que l’option « Activer la liste d’attente » est cochée pour le bon canal de vente, que le produit est bien en mode closeout, et que son stock disponible est à zéro. Videz le cache après toute modification de configuration.

Les inscriptions sont enregistrées mais aucun e-mail ne part. Le worker Messenger et/ou le planificateur de tâches ne tournent pas. Lancez-les manuellement pour tester (voir la section Worker), puis assurez-vous qu’ils s’exécutent en continu en production.

Erreur de service mail à l’activation sur Shopware 6.7. La classe de service mail abstraite a été remplacée par une classe concrète en 6.7. Le plugin gère cette différence automatiquement via un compiler pass qui crée l’alias adéquat ; un simple cache:clear recompile le conteneur si l’erreur subsiste après une mise à jour.

L’e-mail part dans la mauvaise langue. La langue retenue est celle du canal de vente au moment de l’inscription. Vérifiez que le canal concerné a bien la langue attendue et que le modèle d’e-mail dispose d’une traduction pour cette langue.

Des e-mails semblent envoyés en double. Cela ne devrait pas arriver : le traitement est idempotent et marque (ou supprime) chaque inscription après envoi. Si vous l’observez, vérifiez que vous n’exécutez pas plusieurs workers concurrents sans la configuration de transport adéquate.

Que se passe-t-il à la désinstallation ? Avec l’option de suppression des données, la table df_stock_notification, les deux modèles d’e-mail, le jeu de champs df_preorder, la tâche planifiée et la configuration sont supprimés. Sans cette option, tout est conservé pour une réinstallation ultérieure.