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 fonctionnalites de maniere isolee.

Chaque bundle contribue ses fichiers de configuration via un evenement. Le controller d'administration agrege ces donnees et les presente dans une zone FroggShop unique.

Les migrations appellent des helpers idempotents pour inserer ou mettre a jour des donnees Shopware sans dupliquer les enregistrements ni casser les environnements existants.

Les commandes console s'executent via Symfony/Shopware et appellent les repositories ou services FroggShop pour appliquer des actions controlees.

Les pages Markdown sont organisees par bundle et publiees via MkDocs pour servir de reference aux developpeurs, QA et redacteurs.

Le theme surcharge ou etend les templates Shopware, expose des variables globales et s'appuie sur la configuration theme pour adapter le rendu.

Ces classes utilitaires sont injectables par les bundles pour eviter de dupliquer les mecanismes de log, stockage ou manipulation de dates.

Des entites blog stockent les contenus. Les controllers storefront et page loaders construisent les pages, tandis que les commandes importent ou reconstruisent les donnees SEO.

Les controllers appellent les services Storyblok, recuperent 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'ecrivent dans des fichiers versionnes puis peuvent la restaurer dans un autre espace cible.

FroggShop decore le renderer CMS, resout les modules headless, prepare les variables Twig et retourne du HTML exploitable dans les pages Shopware.

Un expander detecte les tokens dans le contenu, delegue chaque shortcode a un handler dedie puis remplace le marqueur par le rendu final.

Des pagelets recuperent les contenus globaux, les rendent via Storyblok et les exposent en HTML direct ou en fragment ESI selon la configuration.

Le controller recoit la soumission, recharge la definition du formulaire, valide les champs et securites, puis dispatch un evenement Flow avec les donnees nettoyees.

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

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

Les contenus editoriaux sont enrichis avec titres, descriptions, aliases et routes SEO. Des commandes peuvent nettoyer ou regenerer les metadonnees.

La route native est decoree, les criteres sont enrichis, les resultats sont combines puis retournes dans un format compatible storefront.

Un controller expose une interface d'analyse, sauvegarde les jugements et calcule des indicateurs de qualite sur les resultats observes.

Une route resout le fabricant par slug, charge les produits associes et applique les templates SEO pour produire une page indexable.

Une entite dediee decrit la page, ses criteres et son statut. Des services recalculent sa validite, ses URLs et sa presence dans le sitemap.

L'admin cree un permalink depuis une URL ou des filtres. FroggShop parse les parametres, genere une page CatalogPage associee et expose la route publique.

Les commandes alimentent une entite redirect depuis saisie ou CSV. Un resolver retrouve la cible et applique la redirection lors des requetes.

La commande d'installation cree ou met a jour les templates SEO URL Shopware pour les routes FroggShop concernees.

La configuration JSON est interpretee par un service, appliquee aux produits concernes et ajoutee aux line items via cart processor.

Les commandes ou scheduled tasks recalculent la disponibilite a partir des donnees produit/stock/regles, puis stockent le resultat dans une entite dediee.

L'information est attachee au produit via extension DAL. Les APIs admin lisent/ecrivent l'entite en respectant la version produit Shopware.

Des subscribers ajoutent des filtres aux criteres produit, un service decide l'acces selon les regles et les index sont enrichis pour filtrer aussi la recherche.

Des subscribers surveillent les transitions de commande et des decorations ajustent les operations de stock au moment opportun.

L'API recoit le produit parent, calcule les combinaisons d'options et delegue la creation ou mise a jour des variantes au service metier.

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

Les entites Pack relient le produit pack a ses composants. Le stock du pack est calcule depuis les stocks disponibles des produits inclus.

Le calculateur de prix est decore pour ajouter les taxes configurees. Le panier est ensuite enrichi avec les montants additionnels applicables.

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

Les magasins sont stockes en DAL, charges par des controllers storefront et exposes via pages indexables ou endpoints de recherche.

Les stocks par produit/magasin sont lus via repository et exposes au storefront pour afficher disponibilite locale et options checkout.

Une relation client-magasin est persistee. Des routes permettent de la creer, la lire ou la modifier, et un subscriber la recharge au login.

Le checkout interroge les services Store pour verifier 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 coordonnees ou coordonnees en code postal, puis ces donnees servent aux recherches transporteur.

La probe execute des controles simples sur les connecteurs ou endpoints transporteurs et remonte un statut au healthcheck global.

Le controller recoit la saisie utilisateur, interroge le provider configure et renvoie des suggestions normalisees 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 donnees en arriere-plan et les entites postal city/zip code sont alimentees.

Un controller intercepte la route concernee et retourne une redirection vers l'etape checkout souhaitee.

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

FroggShop decore le controller natif, execute sa logique ou la complete, puis retourne une reponse compatible avec Shopware.

La route `OrderRoute` est decoree. Les commandes chargees sont completees par un builder qui organise livraisons, line items et donnees additionnelles.

Les providers importent ou exposent leurs avis via une interface commune. Le service central normalise les donnees et maintient les agregats.

Le controller charge les avis par type et identifiant d'entite, applique les filtres puis retourne un rendu ou une reponse exploitable.

Les commandes manipulent les repositories d'avis pour supprimer les donnees ciblees ou inserer des fixtures de test.

Le provider lit la configuration Avis Garantis, recupere ou transforme les avis puis les injecte dans le modele generique FroggShop.

Le provider natif est decore pour ajouter les cookies configures avant affichage de la modale ou lecture des preferences.

Le controller recoit l'etat du consentement, ajoute les informations de contexte et ecrit un log dedie pour audit ou diagnostic.

Un endpoint genere 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 reinjectent selon l'operation demandee.

Le mode dump redirige ou stocke les emails generes pour permettre leur inspection sans envoi reel aux destinataires.

Le subscriber ecoute les evenements mail, extrait sujet, destinataires et contexte, puis ecrit les informations dans le canal de log dedie.

Chaque fournisseur OAuth dispose de sa configuration et d'un service dedie. Le controller OAuth orchestre la redirection, le retour fournisseur, l'association au client Shopware et la creation des donnees OAuth rattachees au compte.

Le service Google OAuth valide le retour fournisseur, recupere l'identite externe, puis cree ou associe le client Shopware via l'entite de liaison OAuth.

Le service Apple recupere les cles Apple, verifie le token d'identite, extrait les donnees 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 cree une nouvelle. Des events permettent de personnaliser l'association et les traitements post-login.

La route d'inscription Shopware est decoree afin d'autoriser ou completer les informations requises pour un compte OAuth sans mot de passe saisi par l'utilisateur.

Les templates utilisent l'extension Twig pour recuperer les providers actifs, construire les URLs de connexion et afficher les boutons adaptes au theme.

Au checkout, Cawl cree une session de tokenisation, affiche le widget carte, valide le token cote serveur, cree le paiement puis finalise la transaction selon le retour API ou webhook.

Un subscriber charge une session `hostedTokenization`, ajoute une extension a la page Shopware et le JavaScript initialise le tokenizer Cawl dans le conteneur du template.

Le `CawlCardHandler` valide le token, cree la commande, appelle l'API Cawl, redirige vers le 3DS si requis puis finalise la transaction a partir du statut de paiement.

Le controller valide la signature HMAC, transmet l'evenement au handler, retrouve le payment token, capture automatiquement si le montant est correct et applique les transitions de transaction Shopware.

Les tokens stockent les identifiants de tokenisation, autorisation, capture et transaction. Les webhooks les relisent pour appliquer les changements d'etat au bon paiement.

Chaque phase du paiement ecrit un contexte structure. Les erreurs de configuration, validation, montant ou webhook sont tracees pour exploitation locale ou ELK.

Les services Cawl lisent la system config au runtime pour construire le client API, verifier les signatures et choisir les URLs selon l'environnement.

Les responses recoivent des tags de cache. Les fragments ESI isolent les zones dynamiques, et les commandes ou subscribers invalident uniquement les contenus impactes.

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

La configuration de state machine decrit les transitions attendues. Les commandes simulent ou verifient que les chemins critiques restent applicables.

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

La route de login Shopware est decoree pour executer des controles supplementaires avant ou apres l'authentification standard.

Le controller appelle un service de probes, execute chaque controle active et retourne un statut global detaille pour supervision.

Des commandes, subscribers ou messages detectent les medias eligibles, generent les variantes WebP et enregistrent le lien avec les thumbnails.

Les URLs media sont adaptees selon la configuration CDN. Les purges sont declenchees par commande ou evenement de modification/suppression.