SW Shopware 6 Shopware Intermédiaire

DfPwaPush — Guide complet

Transformer votre boutique Shopware en PWA installable et envoyer des notifications Web Push auto-hébergées (VAPID, sans Firebase ni dépendance Composer) pour Shopware 6.5, 6.6 et 6.7.

Mis à jour Version du module 1.0.2

DfPwaPush combine deux fonctions en un seul plugin Shopware : il transforme votre storefront en Progressive Web App installable (manifest, service worker, page hors-ligne, bannière d’installation) et vous permet de réengager vos clients avec des notifications Web Push entièrement auto-hébergées. Aucun service tiers (ni Firebase, ni OneSignal), aucune dépendance Composer : le chiffrement Web Push (RFC 8291) et la signature VAPID (RFC 8292) sont implémentés nativement avec les extensions OpenSSL et cURL déjà requises par Shopware. Toutes les données d’abonnement restent sur votre serveur. Ce guide couvre l’installation, la configuration PWA et Push, la génération des clés VAPID, la création et l’envoi de campagnes, l’exécution en arrière-plan, ainsi que le dépannage.

Installation

  1. Téléchargez l’archive DfPwaPush-1.0.2.zip depuis votre compte DataFirefly.
  2. Installez-la via Administration → Extensions → Mes extensions → Charger l’extension, ou copiez le dossier décompressé DfPwaPush dans custom/plugins/.
  3. Lancez l’installation et l’activation : 
    bin/console plugin:refresh
bin/console plugin:install --activate DfPwaPush
bin/console cache:clear
  4. À l’installation, le plugin crée ses deux tables (df_push_subscription et df_push_campaign) et enregistre sa ScheduledTask d’envoi.

Compatible Shopware 6.5.x, 6.6.x et 6.7.x sur un seul codebase. Le module d’administration est livré précompilé et le JavaScript du storefront est injecté via Twig : aucun build n’est nécessaire, ni build-administration.sh ni build storefront. Extensions PHP requises : openssl et curl, toutes deux déjà exigées par Shopware. Aucune dépendance Composer supplémentaire.

Prérequis HTTPS

Les service workers et l’API Web Push n’existent que sur une origine sécurisée. Votre boutique doit être servie en HTTPS (seul localhost fait exception en développement). Sur une boutique en HTTP, le plugin reste silencieux côté front et le journalise dans la console du navigateur.

Où trouver le plugin dans l’administration

Après activation, une entrée Campagnes push apparaît dans le menu Marketing de l’administration. C’est là que vous créez, planifiez et suivez vos campagnes. Toute la configuration PWA et Push se fait dans la configuration du plugin, par canal de vente, via Extensions → Mes extensions → DfPwaPush → ⋯ → Configurer.

Si l’entrée de menu n’apparaît pas après une mise à jour, exécutez bin/console assets:install && bin/console cache:clear puis rechargez l’administration avec un rafraîchissement forcé (Ctrl+Shift+R).

Génération des clés VAPID

Le Web Push repose sur une paire de clés VAPID (norme RFC 8292) qui authentifie votre serveur auprès des services de push des navigateurs. Générez-les en une commande :

bin/console df:pwa-push:vapid:generate

Les clés sont écrites directement dans la configuration du plugin. Utilisez l’option --force pour les régénérer. Vous pouvez aussi coller des clés VAPID existantes dans les champs de configuration.

Régénérer les clés VAPID invalide tous les abonnements existants : les navigateurs déjà abonnés ne pourront plus recevoir de notifications et devront se réabonner. Ne le faites qu’en connaissance de cause.

Configuration PWA

La carte PWA de la configuration (réglable par canal de vente) pilote l’installabilité de votre boutique :

  • Activer la PWA : sert le manifest et le service worker.
  • Nom et nom court de l’application : affichés sur l’écran d’accueil une fois installée.
  • Couleur du thème / couleur de fond : par défaut #0f172a pour le thème.
  • Mode d’affichage : standalone, minimal-ui, fullscreen ou browser.
  • Icônes 192 px et 512 px : uploads PNG, indispensables à l’installabilité.
  • Bannière d’installation : active l’invite « Ajouter à l’écran d’accueil ».

Sans les deux icônes 192 px et 512 px renseignées, Chrome ne considère pas le site comme installable et la bannière d’installation ne s’affichera jamais. C’est la cause numéro un d’une PWA qui « ne fait rien » côté front.

Configuration Push

La carte Push contrôle les notifications :

  • Activer le Web Push : active la bannière d’opt-in et les endpoints d’abonnement. Activé par défaut.
  • Clé publique / clé privée VAPID : générées par la commande ci-dessus.
  • Sujet VAPID : une adresse mailto: ou l’URL de votre site.
  • Délai d’opt-in : nombre de secondes avant l’apparition de la bannière d’autorisation (8 par défaut).

Le service worker et les endpoints du storefront

Toutes les ressources PWA sont servies dynamiquement par un contrôleur, ce qui les rend insensibles au passage de webpack à Vite en 6.7 :

  • GET /df-pwa/manifest.json — le manifest PWA, généré par canal de vente.
  • GET /df-pwa/sw.js — le service worker (en-tête Service-Worker-Allowed: / pour contrôler toute l’origine).
  • GET /df-pwa/icon/{192|512} — les icônes PWA.
  • GET /df-pwa/offline — la page de repli hors-ligne, mise en cache par le service worker.
  • POST /df-pwa/subscribe et POST /df-pwa/unsubscribe — enregistrement et suppression d’un abonnement (XHR).

Le service worker met la page hors-ligne en cache à l’installation, sert un repli pour les navigations en échec, et affiche les notifications reçues via l’événement push avec redirection au clic vers l’URL de la campagne.

Créer et envoyer une campagne

  1. Rendez-vous dans Marketing → Campagnes push → Créer une campagne.
  2. Renseignez le titre, le message, et éventuellement une URL cible et une icône.
  3. Restreignez si besoin la campagne à un canal de vente (sinon tous les abonnés sont ciblés).
  4. Soit vous définissez une date de planification et enregistrez, soit vous cliquez sur Envoyer maintenant.

« Envoyer maintenant » place la campagne en file immédiate (statut scheduled avec une date d’envoi à l’instant présent) ; la tâche planifiée la prend en charge dans les minutes qui suivent. Une campagne passe par les statuts draft → scheduled → sending → sent (ou failed), et la fiche affiche les compteurs d’envois réussis et d’échecs.

Envoi en arrière-plan : ScheduledTask et CLI

L’envoi des campagnes est assuré par la ScheduledTask df_pwa_push.send_campaigns, exécutée toutes les 300 secondes. Elle récupère les campagnes planifiées arrivées à échéance et les envoie par lots. Vous pouvez aussi déclencher l’envoi manuellement :

bin/console df:pwa-push:send

Comme toute ScheduledTask Shopware, l’envoi dépend d’un worker actif. Assurez-vous qu’un consumer Messenger tourne (bin/console messenger:consume) ou que le scheduler Shopware est déclenché régulièrement, sinon les campagnes planifiées ne partiront pas.

Web Push natif, sans dépendance

DfPwaPush implémente la pile Web Push complète en PHP pur, sans bibliothèque externe :

  • VAPID / ES256 (RFC 8292) : génération de clés P-256 via OpenSSL et signature JWT ES256 pour authentifier le serveur.
  • Chiffrement aes128gcm (RFC 8291) : ECDH éphémère, dérivation HKDF et chiffrement AES-128-GCM du message pour chaque abonné.
  • Envoi parallèle via curl_multi par lots, avec gestion des codes de retour des services de push.

L’implémentation est validée octet par octet contre le vecteur de test officiel du RFC 8291, ce qui garantit l’interopérabilité avec Chrome, Firefox, Edge et Safari.

Nettoyage automatique des abonnements

Quand un service de push répond qu’un abonnement n’existe plus (codes HTTP 404 ou 410), l’abonnement correspondant est automatiquement désactivé. Les abonnements qui échouent de façon répétée (5 échecs consécutifs) sont eux aussi désactivés. Votre base d’abonnés reste ainsi propre sans intervention.

Compatibilité iOS et Safari

Sur iOS, le Web Push exige iOS 16.4 ou supérieur et que la PWA soit installée sur l’écran d’accueil : Safari ne délivre pas de notifications push à un simple onglet. Le plugin gère ce cas proprement — la bannière d’opt-in n’apparaît que lorsque l’API Push est réellement disponible, donc aucune fausse promesse n’est faite à vos visiteurs iOS.

FAQ et dépannage

L’installation par ZIP échoue avec « package minishlink/web-push manquant ». Cette erreur concernait les versions antérieures. Depuis la 1.0.1, le Web Push est natif et le plugin n’a plus aucune dépendance Composer : la version actuelle s’installe sur n’importe quel hébergement, y compris mutualisé.

Rien n’apparaît pour créer des campagnes dans le back-office. Le module d’administration est précompilé depuis la 1.0.1. Après mise à jour, lancez bin/console assets:install && bin/console cache:clear et rechargez l’administration en forçant le cache (Ctrl+Shift+R). L’entrée se trouve sous Marketing → Campagnes push.

L’URL /df-pwa/manifest.json renvoie une erreur 500. Corrigé en 1.0.2 : la méthode setTwig() du contrôleur parent a été supprimée en Shopware 6.7, ce qui faisait échouer toutes les routes /df-pwa/*. Mettez à jour vers la 1.0.2 ou une version ultérieure.

Rien ne se passe sur le storefront. Ouvrez la console du navigateur : le plugin journalise chaque décision avec le préfixe [DfPwaPush] (service worker enregistré ou non, clé VAPID manquante, permission refusée, iOS sans PWA installée…). Vérifiez aussi que la boutique est en HTTPS.

La bannière d’installation PWA ne s’affiche pas. Chrome n’émet l’événement beforeinstallprompt que si le site est installable, ce qui exige les icônes 192 px et 512 px renseignées dans la configuration et un service worker actif. Sans icônes, pas de bannière.

La bannière de notifications ne s’affiche pas. Vérifiez que les clés VAPID sont générées, que le Web Push est activé, et que l’utilisateur n’a pas déjà refusé les notifications. La console affichera la raison exacte.

Que se passe-t-il à la désinstallation ? Avec l’option de suppression des données, les tables df_push_subscription et df_push_campaign sont supprimées. Sans cette option, elles sont conservées pour préserver vos abonnés et l’historique de campagnes.

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

Toujours bloqué ? Contactez le support