All FroggShop features, organized by layer

The main plugin loads additional bundles through Shopware. Each bundle registers its services, routes, migrations and configurations, then exposes its features in isolation.

Each bundle contributes its configuration files through an event. The administration controller aggregates this data and presents it in a single FroggShop area.

Migrations call idempotent helpers to insert or update Shopware data without duplicating records or breaking existing environments.

Console commands run through Symfony/Shopware and call FroggShop repositories or services to apply controlled actions.

Markdown pages are organized by bundle and published with MkDocs to serve as a reference for developers, QA and writers.

The theme overrides or extends Shopware templates, exposes global variables and relies on the theme configuration to adapt rendering.

These utility classes can be injected by bundles to avoid duplicating logging, storage or date-handling mechanisms.

Blog entities store the content. Storefront controllers and page loaders build the pages, while commands import or rebuild the SEO data.

Controllers call the Storyblok services, fetch the stories, transform them into storefront output and invalidate the cache on webhooks or synchronizations.

Commands read the Storyblok component structure, write it into versioned files, then can restore it into another target space.

FroggShop decorates the CMS renderer, resolves headless modules, prepares the Twig variables and returns HTML usable in Shopware pages.

An expander detects the tokens in the content, delegates each shortcode to a dedicated handler, then replaces the marker with the final output.

Pagelets fetch the global content, render it through Storyblok and expose it as direct HTML or an ESI fragment depending on the configuration.

The controller receives the submission, reloads the form definition, validates the fields and security checks, then dispatches a Flow event with the cleaned data.

The `/robots.txt` route calls a renderer that assembles the content based on the active configuration and the domain context.

The configured values are read by the storefront or templates to inject the IDs and scripts only when they are active.

Editorial content is enriched with titles, descriptions, aliases and SEO routes. Commands can clean up or regenerate the metadata.

The native route is decorated, the criteria are enriched, the results are combined and returned in a storefront-compatible format.

A controller exposes an analysis interface, saves the judgments and computes quality indicators on the observed results.

A route resolves the manufacturer by slug, loads the related products and applies the SEO templates to produce an indexable page.

A dedicated entity describes the page, its criteria and its status. Services recompute its validity, its URLs and its presence in the sitemap.

The admin creates a permalink from a URL or filters. FroggShop parses the parameters, generates an associated CatalogPage and exposes the public route.

Commands populate a redirect entity from manual input or CSV. A resolver finds the target and applies the redirect during requests.

The installation command creates or updates the Shopware SEO URL templates for the relevant FroggShop routes.

The JSON configuration is interpreted by a service, applied to the relevant products and added to the line items through a cart processor.

Commands or scheduled tasks recompute availability from product/stock/rule data, then store the result in a dedicated entity.

The information is attached to the product through a DAL extension. The admin APIs read/write the entity while respecting the Shopware product version.

Subscribers add filters to the product criteria, a service decides access based on the rules, and the indexes are enriched to filter search as well.

Subscribers watch order transitions and decorations adjust stock operations at the right time.

The API receives the parent product, computes the option combinations and delegates the creation or update of variants to the business service.

Migrations add the fields, then the service reads the product values to provide the badges to templates or integrations.

Pack entities link the pack product to its components. The pack stock is computed from the available stock of the included products.

The price calculator is decorated to add the configured taxes. The cart is then enriched with the applicable additional amounts.

Subscribers inspect the line items and cart context, then apply the configured adjustments before the cart is recomputed.

Stores are stored in the DAL, loaded by storefront controllers and exposed through indexable pages or search endpoints.

Per-product/store stock is read through a repository and exposed to the storefront to show local availability and checkout options.

A customer-store relation is persisted. Routes make it possible to create, read or update it, and a subscriber reloads it at login.

Checkout queries the Store services to verify stock and offer stores compatible with the cart.

Controllers and Store API routes search for relay points, connectors query the carrier APIs, then the choice is saved on the cart or the order.

The endpoints convert a postal code into coordinates or coordinates into a postal code, then this data is used for carrier searches.

The probe runs simple checks on the carrier connectors or endpoints and reports a status to the global healthcheck.

The controller receives the user input, queries the configured provider and returns normalized suggestions to the storefront form.

Subscribers enrich or modify the Shopware validation constraints based on the active configuration and the customer context.

The command starts the import, the messages process the data in the background, and the postal city/zip code entities are populated.

A controller intercepts the route and returns a redirect to the desired checkout step.

The controllers save the address choice in the cart or context, then the subscriber reapplies it at confirmation.

FroggShop decorates the native controller, runs or extends its logic, then returns a Shopware-compatible response.

The `OrderRoute` is decorated. The loaded orders are completed by a builder that organizes deliveries, line items and additional data.

Providers import or expose their reviews through a common interface. The central service normalizes the data and maintains the aggregates.

The controller loads the reviews by entity type and ID, applies the filters and returns a usable rendering or response.

Commands operate on the review repositories to delete targeted data or insert test fixtures.

The provider reads the Avis Garantis configuration, fetches or transforms the reviews, then injects them into the generic FroggShop model.

The native provider is decorated to add the configured cookies before the modal is shown or the preferences are read.

The controller receives the consent state, adds context information and writes a dedicated log for audit or diagnostics.

One endpoint generates a token using a master token. A second endpoint validates that token, logs in the target customer and records the action.

The commands read the templates from the database or files, then export or reinject them depending on the requested operation.

Dump mode redirects or stores the generated emails to allow inspection without actually sending them to recipients.

The subscriber listens to email events, extracts subject, recipients and context, then writes the information to the dedicated log channel.

Each OAuth provider has its own configuration and a dedicated service. The OAuth controller orchestrates the redirect, the provider callback, the association with the Shopware customer and the creation of the OAuth data attached to the account.

The Google OAuth service validates the provider callback, retrieves the external identity, then creates or links the Shopware customer through the OAuth link entity.

The Apple service fetches the Apple keys, verifies the identity token, extracts the useful data and associates it with the Shopware account like the other OAuth providers.

On an OAuth sign-in, the plugin looks for an existing association or creates a new one. Events make it possible to customize the association and post-login processing.

The Shopware registration route is decorated to allow or complete the information required for an OAuth account without a user-entered password.

Templates use the Twig extension to fetch the active providers, build the sign-in URLs and display buttons matching the theme.

At checkout, Cawl creates a tokenization session, displays the card widget, validates the token server-side, creates the payment, then finalizes the transaction based on the API or webhook response.

The Monext widget is embedded in checkout and exposes its payment methods; the transaction response drives the finalization of the Shopware order.

The Mollie plugin is wired into the Shopware checkout and delegates the rendering of payment methods and transaction status tracking to Mollie.

The gift card amount is deducted from the cart; the remaining balance triggers a second payment method to complete the order.

The official PayPal plugin adds its payment methods to the Shopware checkout and handles both one-off and installment payments.

The official Stripe plugin is wired into checkout and delegates capture, 3DS and payment status tracking to Stripe.

Responses receive cache tags. ESI fragments isolate the dynamic areas, and commands or subscribers invalidate only the affected content.

A subscriber and a policy identify the compatible routes, preserve the user messages and limit the cache's side effects on the session.

The state machine configuration describes the expected transitions. Commands simulate or verify that the critical paths remain applicable.

The infrastructure and environment configuration isolates the admin on a specific host, which eases filtering, routing and hardening.

The Shopware login route is decorated to run additional checks before or after standard authentication.

The controller calls a probe service, runs each enabled check and returns a detailed global status for supervision.

Commands, subscribers or messages detect eligible media, generate the WebP variants and record the link with the thumbnails.

Media URLs are adapted based on the CDN configuration. Purges are triggered by command or by a modification/deletion event.