Shopware / FroggShop features

A configuration defines the information to display on the relevant products. This information can be carried into the basket where the journey provides for it.

Authorised users manually judge the results they examine. These judgements feed metrics and a history for comparing analyses; access and storage must be assessed before the tool is made available. This is not a merchant dashboard available by default.

The page identifies a brand or manufacturer and brings together its products. Its URL and SEO elements support publication; the content to add is defined as part of the project.

Displayed availability combines product data, stock and the selected sales rules. It is updated at the intervals planned for the project.

The team defines grouping properties and additional criteria. Segments select products by properties or from those already assigned to a dynamic product group; this selection does not recalculate the dynamic group’s criteria.

Reviews are imported or retrieved from configured providers, then brought together in a common format. The shop displays them according to the chosen rules, including on the relevant product pages.

Rules define which products are visible in the relevant journeys. They apply to product listings, product pages and search results included in the scope.

A future release date identifies a pre-order. The display depends on availability settings and the theme; purchases remain subject to the product’s sales and quantity conditions.

As the customer types, the configured address services offer suggestions. Selecting one fills in the corresponding fields; an address without a suitable suggestion requires manual entry.

The customer account organises the products and deliveries for each order. It presents available additional information to help customers find their purchase details.

The customer selects an active login provider and signs in with it. On return, the identity data is checked and matched to the shop account according to the chosen rules.

The customer enters card details in the hosted form and completes additional payment verification if required. Notifications are checked and reconciled with the transaction; activation depends on the contract and access to the provider.

Payment processing checks the basket, amount and currency before order creation, then reconciles transaction notifications. Going live depends on sales channel configuration.

A temporary link provides a check on the imported account holder. The customer supplies the information needed to complete access activation.

The supported non-transactional information stays associated with the basket. When the customer resumes, the journey restores these elements, such as a comment, without treating them as payment confirmation.

Forms check data according to the customer context and defined rules. These checks take account of constraints in the systems with which information is exchanged.

Shop forms are extended with the expected fields. Input rules and messages shown to customers are adapted to the chosen journey.

Additional checks apply to login and passwords. They extend Shopware authentication according to the controls enabled.

Stores have dedicated pages in the storefront. A search helps customers find locations using the information provided.

Stock linked to each store supplies local availability information. It also supports nearby store searches and collection journeys when these are enabled.

The blog brings together categories, authors, lists and blog post pages with pagination. Content can come from Storyblok or a migration of existing content, with the necessary redirects for old URLs.

The team inserts the placeholders provided for the project’s components into the content. The store replaces them with the corresponding block, such as a product display.

The form uses the fields defined in Storyblok and validates the data on submission. After the configured checks, validated data is passed to the intended business process, for example for a contact request.

The team organises reusable content blocks, assigns them to products and chooses their display order. A size guide can be shared, while a block designed for product-specific adaptation provides advice for an individual product.

Incoming ranks are checked before being applied to the configured contexts and sorting. If the context cannot be resolved, the store uses the configured fallback sorting, then native sorting if necessary.

IDs and scripts are managed according to the project settings. Their triggering in relation to consent must be checked for each tool before publication.

Settings for enabled features are grouped in the Shopware administration. Teams apply the parameters needed for the sales channel and the project’s business rules.

Teams manage the criteria, publication status and URL of each relevant page. Its inclusion in the search engine sitemap follows the chosen publication rules.

Additional references and logistics information are associated with products. Synchronisation with third-party tools is provided for when included in the project scope.

Teams select references and assign options to them. The tool links them to a parent, creating one if needed, and adjusts content inheritance; local variant descriptions and cross-selling data are reset.

Temporary access allows the customer journey to be reproduced. This access is restricted to authorised people, checked and tracked to govern its use.

Templates, headers and footers can be exported to retain their versions. They are then reimported into the intended environment to apply the chosen content.

A new dataset is checked before replacing the active version. The previous version can be restored; data volumes and journeys must be validated in the target environment.

The project defines which stages should trigger a stock movement. Changes are applied at those stages to follow the chosen business process.

Configured taxes are linked to the products they apply to. They are included in the amounts calculated in the basket according to the chosen rules.

Formats and lengths are checked in the relevant forms and exchanges. Rules follow the constraints of the company’s enterprise resource planning system, or ERP, selected for the project.

The output uses the first applicable provider that returns non-empty content, in priority order, without merging content. The configuration-based provider reads the sales channel’s directives; the file actually served must be checked on each relevant domain.

SEO information is managed alongside content and its publication rules. It can be rebuilt during planned site changes.

Old URLs are mapped to their new destinations. These mappings can be imported in bulk after validation, particularly during a redesign.

URL patterns are configured for brand pages and catalogue selections. They apply to the journeys enabled for the project.

The team chooses which filter groups to expose as crawlable links. Depending on the configuration, a link leads to an active filtered page or a native filtered URL, without replacing the usual filter behaviour.

Content is stored temporarily to avoid rebuilding it on every visit. After a change, affected pages or areas are refreshed according to the defined publication rules.

Optimised variants are generated for eligible media. They are associated with store images without changing how the library is managed.

A content delivery network, or CDN, serves media when the project uses one. Its cached copies are refreshed after the changes covered by the configuration.

The declaration provider extends the Shopware manager with sample cookies and groups to adapt in code. It is not a ready-to-use merchant cookie inventory; actual cookies, their purposes and script blocking after refusal or withdrawal must be checked for the project.

Consent choices are logged with their context. Retention follows the audit policy and periods defined for the project.

Monitoring checks the configuration and connection of enabled pickup point services. It helps diagnose unavailability without ensuring continuous carrier availability.

Expected order transitions are described for the project. Validation procedures check that they remain applicable after changes.

Checks query enabled resources, services and integrations. They report a status that monitoring teams can use.

Operations begin with a diagnostic analysis of media cleanup candidates. They check candidates again before intervention and protect media still in use by default.

Diagnostic tools inspect application health, services and authorised processing queues. Access remains read-only within the defined scope.

The project enables modules relevant to the catalogue, journeys and operations. Their settings are adapted to the selected scope and required integrations.

Migration helpers prepare the defined data and settings. Default settings check for existing values, while some page creation helpers generate new identifiers; duplicate prevention and recovery after failure must be checked for each migration before rerunning it.

The theme provides shared displays and settings for store pages. The project adapts them to the selected content, components and uses.

Administration can be served on a separate domain when the architecture supports it. Associated access and security rules are defined for the project.