Toutes les fonctionnalités FroggShop, rangées par socle

Le plugin principal charge des bundles additionnels via Shopware. Chaque bundle enregistre ses services, routes, migrations et configurations, puis expose ses fonctionnalités de manière isolée.

Chaque bundle contribue ses fichiers de configuration via un événement. Le controller d'administration agrège ces données et les présente dans une zone FroggShop unique.

Les migrations appellent des helpers idempotents pour insérer ou mettre à jour des données Shopware sans dupliquer les enregistrements ni casser les environnements existants.

Les commandes console s'exécutent via Symfony/Shopware et appellent les repositories ou services FroggShop pour appliquer des actions contrôlées.

Les pages Markdown sont organisées par bundle et publiées via MkDocs pour servir de référence aux développeurs, QA et rédacteurs.

Le thème surcharge ou étend les templates Shopware, expose des variables globales et s'appuie sur la configuration thème pour adapter le rendu.

Ces classes utilitaires sont injectables par les bundles pour éviter de dupliquer les mécanismes de log, stockage ou manipulation de dates.

Des entités blog stockent les contenus. Les controllers storefront et page loaders construisent les pages, tandis que les commandes importent ou reconstruisent les données SEO.

Les controllers appellent les services Storyblok, récupèrent les stories, les transforment en rendu storefront et invalident le cache lors des webhooks ou synchronisations.

Des commandes lisent la structure des composants Storyblok, l'écrivent dans des fichiers versionnés puis peuvent la restaurer dans un autre espace cible.

FroggShop décore le renderer CMS, résout les modules headless, prépare les variables Twig et retourne du HTML exploitable dans les pages Shopware.

Un expander détecte les tokens dans le contenu, délègue chaque shortcode à un handler dédié puis remplace le marqueur par le rendu final.

Des pagelets récupèrent les contenus globaux, les rendent via Storyblok et les exposent en HTML direct ou en fragment ESI selon la configuration.

Le controller reçoit la soumission, recharge la définition du formulaire, valide les champs et sécurités, puis dispatch un événement Flow avec les données nettoyées.

La route `/robots.txt` appelle un renderer qui assemble le contenu selon la configuration active et le contexte de domaine.

Les valeurs configurées sont lues par le storefront ou les templates pour injecter les identifiants et scripts uniquement quand ils sont actifs.

Les contenus éditoriaux sont enrichis avec titres, descriptions, aliases et routes SEO. Des commandes peuvent nettoyer ou régénérer les métadonnées.

La route native est décorée, les critères sont enrichis, les résultats sont combinés puis retournés dans un format compatible storefront.

Un controller expose une interface d'analyse, sauvegarde les jugements et calcule des indicateurs de qualité sur les résultats observés.

Une route résout le fabricant par slug, charge les produits associés et applique les templates SEO pour produire une page indexable.

Une entité dédiée décrit la page, ses critères et son statut. Des services recalculent sa validité, ses URLs et sa présence dans le sitemap.

L'admin crée un permalink depuis une URL ou des filtres. FroggShop parse les paramètres, génère une page CatalogPage associée et expose la route publique.

Les commandes alimentent une entité redirect depuis saisie ou CSV. Un resolver retrouve la cible et applique la redirection lors des requêtes.

La commande d'installation crée ou met à jour les templates SEO URL Shopware pour les routes FroggShop concernées.

La configuration JSON est interprétée par un service, appliquée aux produits concernés et ajoutée aux line items via cart processor.

Les commandes ou scheduled tasks recalculent la disponibilité à partir des données produit/stock/règles, puis stockent le résultat dans une entité dédiée.

L'information est attachée au produit via extension DAL. Les APIs admin lisent/écrivent l'entité en respectant la version produit Shopware.

Des subscribers ajoutent des filtres aux critères produit, un service décide l'accès selon les règles et les index sont enrichis pour filtrer aussi la recherche.

Des subscribers surveillent les transitions de commande et des décorations ajustent les opérations de stock au moment opportun.

L'API reçoit le produit parent, calcule les combinaisons d'options et délègue la création ou mise à jour des variantes au service métier.

Les migrations ajoutent les champs, puis le service lit les valeurs produit pour fournir les badges aux templates ou intégrations.

Les entités Pack relient le produit pack à ses composants. Le stock du pack est calculé depuis les stocks disponibles des produits inclus.

Le calculateur de prix est décoré pour ajouter les taxes configurées. Le panier est ensuite enrichi avec les montants additionnels applicables.

Les subscribers inspectent les line items et le contexte panier, puis appliquent les ajustements configurés avant le recalcul du panier.

Les magasins sont stockés en DAL, chargés par des controllers storefront et exposés via pages indexables ou endpoints de recherche.

Les stocks par produit/magasin sont lus via repository et exposés au storefront pour afficher disponibilité locale et options checkout.

Une relation client-magasin est persistée. Des routes permettent de la créer, la lire ou la modifier, et un subscriber la recharge au login.

Le checkout interroge les services Store pour vérifier les stocks et proposer les magasins compatibles avec le panier.

Les controllers et routes Store API recherchent les relais, les connecteurs interrogent les APIs transporteur, puis le choix est sauvegarde sur le panier ou la commande.

Les endpoints convertissent code postal en coordonnées ou coordonnées en code postal, puis ces données servent aux recherches transporteur.

La probe exécute des contrôles simples sur les connecteurs ou endpoints transporteurs et remonte un statut au healthcheck global.

Le controller reçoit la saisie utilisateur, interroge le provider configure et renvoie des suggestions normalisées au formulaire storefront.

Les subscribers enrichissent ou modifient les contraintes de validation Shopware selon la configuration active et le contexte client.

La commande lance l'import, les messages traitent les données en arrière-plan et les entités postal city/zip code sont alimentées.

Un controller intercepte la route concernée et retourne une redirection vers l'étape checkout souhaitée.

Les controllers sauvegardent le choix d'adresse dans le panier ou le contexte, puis le subscriber le réapplique lors de la confirmation.

FroggShop décore le controller natif, exécute sa logique ou la complète, puis retourne une réponse compatible avec Shopware.

La route `OrderRoute` est décorée. Les commandes chargées sont complétées par un builder qui organisé livraisons, line items et données additionnelles.

Les providers importent ou exposent leurs avis via une interface commune. Le service central normalise les données et maintient les agrégats.

Le controller charge les avis par type et identifiant d'entité, applique les filtres puis retourne un rendu ou une réponse exploitable.

Les commandes manipulent les repositories d'avis pour supprimer les données ciblées ou insérer des fixtures de test.

Le provider lit la configuration Avis Garantis, récupère ou transforme les avis puis les injecte dans le modèle générique FroggShop.

Le provider natif est décoré pour ajouter les cookies configurés avant affichage de la modale ou lecture des préférences.

Le controller reçoit l'état du consentement, ajoute les informations de contexte et écrit un log dédié pour audit ou diagnostic.

Un endpoint génère un token via master token. Un second endpoint valide ce token, connecte le client cible et trace l'action.

Les commandes lisent les templates depuis la base ou les fichiers, puis les exportent ou réinjectent selon l'opération demandée.

Le mode dump redirige ou stocke les emails générés pour permettre leur inspection sans envoi réel aux destinataires.

Le subscriber écoute les événements mail, extrait sujet, destinataires et contexte, puis écrit les informations dans le canal de log dédié.

Chaque fournisseur OAuth dispose de sa configuration et d'un service dédié. Le controller OAuth orchestre la redirection, le retour fournisseur, l'association au client Shopware et la création des données OAuth rattachées au compte.

Le service Google OAuth valide le retour fournisseur, récupère l'identité externe, puis crée ou associe le client Shopware via l'entité de liaison OAuth.

Le service Apple récupère les clés Apple, vérifie le token d'identité, extrait les données utiles et les associe au compte Shopware comme les autres providers OAuth.

Lors d'une connexion OAuth, le plugin recherche une association existante ou en crée une nouvelle. Des events permettent de personnaliser l'association et les traitements post-login.

La route d'inscription Shopware est décorée afin d'autoriser ou compléter les informations requises pour un compte OAuth sans mot de passe saisi par l'utilisateur.

Les templates utilisent l'extension Twig pour récupérer les providers actifs, construire les URLs de connexion et afficher les boutons adaptés au thème.

Au checkout, Cawl crée une session de tokenisation, affiche le widget carte, valide le token côté serveur, crée le paiement puis finalise la transaction selon le retour API ou webhook.

Le widget Monext est embarqué dans le checkout et expose ses moyens de paiement ; le retour de transaction pilote la finalisation de la commande Shopware.

Le plugin Mollie est branché au checkout Shopware et délègue à Mollie le rendu des moyens de paiement et le suivi du statut de la transaction.

Le montant de la carte cadeau est déduit du panier ; le reliquat déclenche un second moyen de paiement pour finaliser la commande.

Le plugin PayPal officiel ajoute ses méthodes de paiement au checkout Shopware et gère le paiement comptant comme le paiement fractionné.

Le plugin Stripe officiel est branché au checkout et délègue à Stripe l'encaissement, le 3DS et le suivi du statut de paiement.

Les responses reçoivent des tags de cache. Les fragments ESI isolent les zones dynamiques, et les commandes ou subscribers invalident uniquement les contenus impactés.

Un subscriber et une policy identifient les routes compatibles, préservent les messages utilisateur et limitent les effets de bord du cache sur la session.

La configuration de state machine décrit les transitions attendues. Les commandes simulent ou vérifient que les chemins critiques restent applicables.

La configuration d'infrastructure et d'environnement isole l'admin sur un host spécifique, ce qui facilite filtrage, routage et durcissement.

La route de login Shopware est décorée pour exécuter des contrôles supplémentaires avant ou après l'authentification standard.

Le controller appelle un service de probes, exécute chaque contrôle activé et retourne un statut global détaillé pour supervision.

Des commandes, subscribers ou messages détectent les médias éligibles, génèrent les variantes WebP et enregistrent le lien avec les thumbnails.

Les URLs média sont adaptées selon la configuration CDN. Les purges sont déclenchées par commande ou événement de modification/suppression.