Spryker Documentation

Upgrade Workflow

Fri, 14 Aug 2026 07:23:47 +0000

Experimental module

The AiDev module is experimental and not stable. There is no backward compatibility promise for this module. We welcome your feedback and contributions as we continue to develop and improve this module.

Availability

The spryker-upgrade skill is available from spryker-sdk/ai-dev version 0.6.4, which ships version 0.4.0 of the spryker-ai-dev-sdk Claude Code plugin.

To update the Claude Code plugin, run /plugin in Claude Code and update spryker-ai-dev-sdk from the spryker-plugins-official marketplace to version 0.4.0 or later. For installation instructions, see Claude Code.

What the skill does

spryker-upgrade upgrades your project’s modules and features to a newer Spryker release. It is built for projects with heavy src/Pyz customization, where the dangerous part of an upgrade is not the code that stops compiling but the code that keeps running while doing nothing.

The skill combines an orchestrated workflow with a set of deterministic detector scripts. Each script is a standalone CLI that runs on host PHP using reflection or static parsing only, with no Spryker bootstrap — so they also work in CI.

Invoke it with “upgrade the project”, “update to the latest release”, or any request to bump spryker-feature/* or spryker/* packages.

Why silent damage is the real problem

Everything a Spryker project overrides fails quietly when core moves. A dead override still loads, a replaced plugin stack still boots, and a stale template still renders. Nothing errors — the customization simply stops taking effect.

The workflow therefore starts with a different question than “which modules changed”. It asks which of your customizations would notice if they stopped working, and whether the upgrade can be verified at all.

The phases

Coverage check — measures your override surface against the tests that cover it, and offers to write characterization tests for the gaps. These must be written before the upgrade; written afterwards they pin the upgraded behavior and can no longer detect that it changed.
Preflight and baselines — records snapshots of overrides and shadowed frontend files, checks for constraint styles that block resolution, and captures pre-existing damage so it is not misattributed to the upgrade.
Constraint resolution — relaxes patch-locked constraints, then resolves conflicts iteratively. Conflicts arrive in waves, each root bump revealing the next transitive layer.
Detection — after Composer completes, runs the detectors that find the silent damage.
Resolution — merges shadowed files, rewires replaced plugin stacks, fixes broken configuration references, and requires a migration guide for every major module bump.

What the detectors find

Detector	Damage it catches
`check-test-coverage.php`	Customizations with no test over them, ranked by risk, with the test type that would catch each gap
`check-vendor-class-replacement.php`	Project files that declare a vendor namespace and replace a core class outright, so the vendor implementation never loads
`check-constraint-style.php`	Patch-locked or exactly pinned constraints that make a feature bump unresolvable
`check-typed-members.php`	Untyped overrides of constants and properties that core has since typed — a fatal on class load that aborts the console itself
`check-dead-overrides.php`	Project methods overriding a vendor method that the new version deleted, so the project logic stops being called
`twig-shadow-map.php`	Shadowed Twig, SCSS, and TypeScript files whose vendor counterparts changed upstream
`merge-shadowed-files.php`	Runs a three-way merge for every shadowed file and sorts the outcomes into clean, identical, conflicted, and removed
`check-plugin-usage.php`	Vendor plugins that are missing or deprecated after the upgrade, and project plugins implementing a removed interface
`check-config-constants.php`	Configuration referencing a vendor constants interface or constant that no longer exists, which breaks bootstrap of every application
`list-major-bumps.php`	Every major module bump, with a documentation search URL, changelog URL, and compare URL per package
`resolve-constraints.php`	Runs Composer, parses root conflicts, raises the constraints the tree demands, and repeats
`unpin-feature-driven-modules.php`	Breaks a cohort deadlock, where a group of modules sharing a dependency must move together

The detectors keep their snapshots and reports in .spryker-upgrade/state/ inside the project, created self-gitignoring on first use.

Order matters

The dependency between the detectors is real. The skill runs them in the correct order — coverage and replacement checks first, then baselines and constraint preflight, then resolution, then post-Composer detection. Running them out of order wastes time on phantom findings.

Run the detectors in CI

Two detectors are cheap enough to gate every pull request, and both catch damage that is otherwise invisible until runtime:

php $UP/check-typed-members.php     # fatals on class load
php $UP/check-plugin-usage.php      # missing plugins

Neither needs a snapshot, a database, or a search backend — only an installed vendor/ directory. Failing the build on exit code 1 turns “the Back Office returns 500 after deploy” into a red pipeline.

For dependency-bumping pull requests, also wrap the change in a snapshot and verify pair for check-dead-overrides.php and twig-shadow-map.php, because those compare against pre-upgrade state and cannot work from a single point in time.

You can also gate check-test-coverage.php in CI, but gate it on a ratchet rather than on zero: fail when a pull request increases the number of untested overrides. New customization then arrives with a test, instead of the project needing a coverage project before anyone can merge.

Known limits

No detector covers Propel schema merges, glossary keys, ACL and navigation for new Back Office routes, or pure behavioral change. Those remain process gates and tests, and the skill marks them as such.

Published migration guides are also sometimes stale or absent, so the skill treats the tag diff, not the guide, as the source of truth.

Requirements

A Spryker project with Composer installed, and host PHP available to run the detector scripts
An AI tool with the SDK’s skills loaded — either through the Claude Code plugin or via ai-dev:setup for another supported tool

spryker-upgrade README — the skill’s own reference in the plugin repository
Skills and Agents — the full reference of every skill and agent
Upgrade and migrate — the manual upgrade and migration guides
Overview — module and ai-dev:setup command

Project Starter Wizard

Fri, 14 Aug 2026 07:23:47 +0000

Experimental module

Availability

The project-starter-wizard skill and the nine setup skills it orchestrates are available from spryker-sdk/ai-dev version 0.6.4, which ships version 0.4.0 of the spryker-ai-dev-sdk Claude Code plugin.

What the skill does

project-starter-wizard turns a fresh, un-booted clone of a Spryker B2B or B2B Marketplace demoshop into your customer project. It asks everything once in a developer interview, records your answers in a resumable state file, and then drives nine specialist skills in the one order that works.

The wizard owns the conversation and the flow — it writes almost nothing itself. Each step delegates to a sibling skill that does the transformation work.

Invoke it at the very start of a new project: “turn this demoshop into our project”, “start the project setup”. It is also the resume entry point — if a previous run left a state file, invoking the skill again skips the interview and continues from the first unfinished step.

The interview

The interview collects nine sections up front so the run needs no further configuration decisions:

Project identity — project name, development domain, and Docker namespace
Namespace — whether to keep Pyz or register a custom namespace
Services — database, search, broker, key-value store, and optional development services
Stores and region
Data mode — adapt, clean, generate, or leave the demo data
Catalog scope
Localization
CI setup
Run mode

The nine steps

Steps 1 to 7 run before the first boot, because each one changes files the boot reads.

Step	Skill	What it does
1	`project-ci-generator`	Rebuilds the inherited product CI into a single lean project pipeline
2	`configure-codebase`	Registers the custom namespace and wires autoload, frontend build, and Codeception. Skipped when the project keeps `Pyz`
3	`brand-project`	Applies the project identity — name, domain, Docker namespace
4	`configure-services`	Writes the chosen engines, development services, and applications into `deploy.dev.yml`
5	`define-stores`	Creates the region and store definitions. Skipped when the data mode is `leave`
6	`project-data`	Adapts, cleans, generates, or leaves the import data
7	`cypress-migration`	Replaces the demoshop test suites with a project-owned Cypress baseline. Last pre-boot step, because it reads the output of steps 1, 3, 4, 5, and 6
8	`boot-and-verify`	First boot and per-store verification, plus the theming half of step 3
9	`translate-content`	Translates storefront content. Runs only when you selected locales to localize

Run modes

You choose the run mode in the interview, and the wizard honors it again on resume:

Autonomous — steps 1 to 9 run as one continuous pass. At a reversible decision point the wizard picks the best option and records it in a decision log.
Supervised — the wizard reports a one-line result and asks “Continue to the next step?” at each step boundary.

Neither mode relaxes the hard stops. A required manual action, any deletion or data wipe, and any step failure all return control to you in both modes.

Run artifacts

The run writes four files into the clone’s own tree under .ai-dev/:

File	Role
`project-setup.md`	The state — interview answers and a step table with per-step status. Resume reads this file
`run.log`	The timeline — step boundaries, conditional skips with their reason, hard stops, and every resume
`decision-log.md`	The rationale — each autonomous decision with its evidence and how to reverse it

What you get at the end

A transformed clone with the project identity and branding, a registered namespace, the chosen services and stores, project-shaped import data, a lean CI pipeline, and a vendored Cypress suite — booted and verified per store by an independent verifier agent, with all changes staged but never committed.

The closing summary flags what still needs a human before go-live, such as a git remote that still points at the demoshop upstream, a still-shipped Spryker logo, or translation debt from locales left as English copies.

Requirements

A fresh, un-booted clone of a Spryker B2B or B2B Marketplace demoshop
An AI tool with the SDK’s skills loaded — either through the Claude Code plugin or via ai-dev:setup for another supported tool

project-starter-wizard README — the skill’s own reference in the plugin repository
Skills and Agents — the full reference of every skill and agent this wizard composes
Customization Workflow — build features on the project once it runs
Overview — module and ai-dev:setup command

Profiler Workflow

Fri, 14 Aug 2026 07:23:47 +0000

Experimental module

Availability

The spryker-profiler skill is available from spryker-sdk/ai-dev version 0.6.4, which ships version 0.4.0 of the spryker-ai-dev-sdk Claude Code plugin.

What the skill does

spryker-profiler turns the Spryker and Symfony WebProfiler into performance numbers you can act on, and explains how to switch profiling on when there is nothing to read.

Spryker records every web request automatically. That history is the cheapest source of truth for performance work: instead of guessing which code is slow, the skill reads what actually ran. It reduces a stored profile to the metrics that matter and prints JSON, so nobody has to scrape the profiler’s HTML or open a browser.

Invoke it when you ask why a page, endpoint, or Back Office screen is slow, want the heaviest request, suspect an N+1 query, need before-and-after evidence that a performance fix worked, or want to know what a request logged, threw, or which controller handled it. It also covers profiler setup — a missing toolbar, a collector showing no data, or enabling profiling for a specific application.

What it can tell you

The I/O counters say how much work a request did:

Metric	Answers
`queries` / `unique` / `duplicates`	How many SQL statements a request ran, and how many were repeats
`redis`	Key-value operations per request
`elasticsearch`	Search calls per request
`zed_requests`	Yves-to-Zed calls — the architecture boundary check
`external_http`	Third-party calls blocking the response
`duration_ms` / `memory_mb`	Wall time and peak memory
`segments`	Queries attributed to a named code path you wrapped

These say why, and whether the numbers are comparable between runs:

Metric	Answers
`logs`	Errors, warnings, and deprecations logged during the request
`audit_log`	Security and compliance events by channel — a separate stream from `logs`
`exception`	What was thrown, with message and status code
`twig`	Template count and render time
`events`	Listeners called synchronously, plus Spryker application events
`http`	Which controller and route handled the request, and where a 3xx redirected to
`session`	Session payload size
`runtime`	Debug mode and Xdebug flags — check these before comparing any timing

A Spryker request records 20 collectors. The skill reads every one that carries request data and maps it onto the fields above. The three it does not read hold no per-request measurements — they are toolbar plumbing and a dump of resolved configuration.

One user action is many profiles

The mistake that most often produces a wrong answer is treating a profile as a user action. A profile is one HTTP request. Clicking Login on the storefront creates six profiles across two applications and two storage directories — and the storefront profile itself reports zero queries, because Yves has no SQL collector by design.

The skill reconstructs the full tree instead. Yves-to-Zed links are exact, because the callee returns its own debug token, which the caller stores. Browser-issued AJAX and ESI sub-requests carry no such link, so those are grouped by time window and flagged as the heuristic they are.

The workflow

If you do not know which page is slow, rank the recorded profiles by a metric to find the outlier.
Reproduce the request, then read the profile and check that its age is seconds — profiles accumulate for days, and without checking you may analyze last week’s request.
If a collector is absent or there are no profiles at all, the skill walks the setup layers that must be enabled.
For a page or user action, read the full trace rather than the entry request alone.
Read the counts, not the milliseconds. Local wall time swings widely for identical work, while I/O counts are stable and are what scales badly in production.
If the counts are high, profile a small and a large entity to see whether the count scales with the data.

An absent collector is not zero

collector: "absent" means the metric was never measured for that application — Yves has no SQL collector, and the Back Office has no Redis collector. Reporting zero queries from an absent collector is a false conclusion. collector: "incompatible" means the collector is recording but an upgrade renamed part of its API, so the data is still available in the browser panel.

Going deeper than counts

Segmented SQL attributes queries to a named code path, turning “this page runs 261 queries” into “the calculator stack runs 180 of them”. Wrap the suspect code and the reader reports it under database.segments:

use Spryker\Shared\Propel\Logger\PropelInMemoryLogger;

PropelInMemoryLogger::startSegment('order-validation');
try {
    $this->validateOrder($orderTransfer);
} finally {
    PropelInMemoryLogger::endSegment();
}

Always use try/finally. The logger is static, so an unclosed segment swallows every later query in the request. Remove segments once you have the answer — they are debugging scaffolding.

A stored profile holds far more than the reader prints, including full SQL text, headers, routing, events, and logger entries. When a question needs something the reader does not expose, the skill extends the script rather than stopping at the available options.

Things that will confuse you

Timings are only comparable at equal runtime. Xdebug inflates wall time several-fold and debug mode disables caches, so a “regression” can be nothing more than a differently configured container.
Each application writes to its own directory. Yves and Glue write to one directory; Zed, the Back Office, the Backend Gateway, and the Merchant Portal write to another. The reader picks the most recently written one, which is often not the one you want.
The index outlives the data. Stored profiles are deleted after two days, but the index is never trimmed, so it can list thousands of requests when only a few dozen files survive. The skill reports how many profiles a ranking actually covered.
external_http: 0 may mean “not instrumented”. External calls appear only if the calling code uses the external HTTP logger trait, so a zero is never proof that a request makes no outbound calls.
Login walls profile the redirect. An unauthenticated request to the Back Office or Merchant Portal records the redirect to the login form, which says nothing about the page you wanted. Reproduce with an authenticated session.
Back Office tables are two requests. The page renders an empty grid and loads its rows through a separate table route, which is usually where the real cost sits. Profile both.
Console commands, queue workers, and cron jobs are never profiled. The WebProfiler is request-scoped. Use Xdebug profiling or explicit timing for those.

When there is no data

Three independent layers must all be in place, and the skill checks each one:

The web profiler is enabled in the project configuration.
The web profiler application plugin is registered for the application you are profiling. Zed alone has four separate stacks — Zed, Back Office, Backend Gateway, and Backend API.
A collector plugin for the metric you want is registered in that application’s WebProfilerDependencyProvider.

After changing any of these, empty the cache and reproduce the request.

Requirements

A running Spryker project (Docker SDK up) with the web profiler enabled
An AI tool with the SDK’s skills loaded — either through the Claude Code plugin or via ai-dev:setup for another supported tool

WebProfiler — why the profiler matters and how to integrate it per application
spryker-profiler README — the skill’s own reference in the plugin repository
Skills and Agents — the full reference of every skill and agent
Overview — module and ai-dev:setup command

Customization Workflow

Fri, 14 Aug 2026 07:23:47 +0000

Experimental module

Availability

The spryker-customization skill ships with the spryker-ai-dev-sdk Claude Code plugin. Version 0.6.4 of spryker-sdk/ai-dev, which ships plugin version 0.4.0, adds the conditional Cypress end-to-end phase described on this page.

What the skill does

spryker-customization is the AI Dev SDK’s orchestrator skill. It takes a feature idea and walks it to a working, committed branch in your Spryker project by delegating focused work to the SDK’s other skills and agents.

You describe what you want in one sentence. From there, spryker-customization invokes the right specialist at each step — for example, spryker-feature-expert to research which Spryker primitives apply, product-requirement-document to write the spec, spryker-refresher to run the post-change commands, spryker-verifier to check the feature against the running app. It stops at a commit gate where you approve the diff before it is saved to git.

You do not write code during the run. You make three decisions: what quality bar you want, whether the plan looks right, and whether the final diff goes in.

Workflow at a glance

Each phase delegates to specific skills (pale yellow) and agents (deep amber) — for example, the spryker-feature-expert agent researches the relevant Spryker domain during planning, and the spryker-verifier agent drives the running storefront and back office to confirm the feature actually works.

What you get at the end

A new branch (ai-customize/<slug>) with the feature implemented
Code in your project layer only — your vendor directory is never edited
A clean refresh — caches, transfers, and frontend builds are all up to date
Per-criterion verification results with real evidence from the running app — what passed, what did not, why
A code-review report against the staged diff
Tests (when you pick the MVP bar)
Cypress end-to-end coverage for the feature (when you pick the MVP bar)
The commit waits for your approval; nothing is pushed

If you wanted a product requirement document too, the skill can produce one — by delegating to product-requirement-document — as a reusable document under resources/plan/PRD/ before the build starts.

Choose your output: PoC or production

You pick one of two bars at the start. The skill asks once and shapes the rest of the run accordingly.

PoC — the fastest path to a feature that works. The orchestrator collapses the implementation into the minimum number of classes, lets values be hardcoded where convenient, sticks to a single locale, and skips test generation. Pick this for demos, sales conversations, and quick experiments.

MVP — production-grade output. The orchestrator uses Spryker’s canonical extension chain (plugin stacks, factory expanders, dependency injection, project-layer transfer and schema XML), covers every configured locale, adds ACL where the feature touches the back office, and writes tests for non-trivial logic. Pick this for code you intend to ship.

Both bars produce a visually integrated feature — new UI elements reuse the project’s atomic design components, never raw HTML pasted onto a styled page.

Cypress end-to-end coverage

Once every acceptance criterion is verified green and any visual sign-offs are done, the workflow runs a Cypress phase. It delegates to the cypress-tests skill, which decides what the feature needs against your project’s existing suite:

Fix a spec the feature broke
Improve assertions that would have missed the change
Add a new spec for the feature

The phase then runs the affected specs and the project’s quality gate rather than the whole suite.

The phase is on by default for the MVP bar and off for PoC, and you can switch it either way at the start. It runs only when the feature is visible on an end-to-end surface and your project has a Cypress suite. A skip is always reported with its reason, never silent.

The phase deliberately runs last, after the self-correction loop has converged, so no spec is written against an implementation still in flux. If a spec goes red because the feature is wrong rather than the test, that is treated as a missed acceptance criterion and feeds back into the self-correction loop.

Where you decide

The skill runs autonomously between three decision points where it pauses for you:

Before planning — you pick PoC or MVP, and which optional phases run (tests, demo screenshots, etc.).
Before any code is written — the orchestrator presents the acceptance criteria, the list of files it intends to edit, and one consolidated round of clarifying questions. Nothing touches the disk until you confirm.
Before the commit — the final diff is staged for you to review. You approve, refuse, or adjust. Branches stay local; pushing is your call.

If verification fails on an acceptance criterion and the skill cannot fix it after a few tries, it surfaces what was attempted and asks you how to proceed rather than silently giving up.

Requirements

A running Spryker project (Docker SDK up) with the AI Dev SDK installed
An AI tool with the SDK’s skills loaded — either through the Claude Code plugin or via ai-dev:setup for another supported tool

spryker-customization README — the skill’s own reference in the plugin repository
Skills and Agents — the full reference of every skill and agent this orchestrator composes
Overview — module and ai-dev:setup command
Claude Code — how to install the SDK for Claude Code

Bugfix Workflow

Fri, 14 Aug 2026 07:23:47 +0000

Experimental module

Availability

The spryker-bugfix skill is available from spryker-sdk/ai-dev version 0.6.4, which ships version 0.4.0 of the spryker-ai-dev-sdk Claude Code plugin. Version 0.6.4 also adds the conditional Cypress end-to-end phase described on this page.

What the skill does

spryker-bugfix takes a bug and drives it to a committed, validated, QA-accepted fix on a bugfix/* branch. In Autonomous mode it goes all the way to a pushed draft pull request with a remote CI watch loop.

The skill is an orchestrator. It runs a fixed sequence of stages and delegates the work of each stage to another SDK skill or agent — it writes no product code itself.

Invoke it whenever you have a bug symptom and expect a delivered fix: “fix this bug”, “fix ticket XY-1122”, “this is broken, reproduce and fix it”. It is not the right skill for a single isolated step, a new feature, a refactor without a symptom, or an investigation-only request.

Two ways in — the ticket is optional

Bug context can come from either or both of:

A ticket from any tracker — a Jira key, a GitHub issue URL or number, or any other service
A free-text description of the symptom with technical hints

A ticket is never required. When a ticket exists and its integration is reachable, the skill pulls it for extra context; otherwise it works entirely from your description, and the branch name, commit message, and pull request title fall back to no-ticket.

The stages

Stage	What happens	Delegates to
Intake	Mode, context, and pull request preference; sets up the run directory	—
Branch	Safety gate — refuses to continue on a dirty tree or a stale base	—
Reproduce	Confirms the symptom in the running application	`spryker-runtime`, `spryker-docs-research`
Root cause	Finds why it happens. Loop re-entry point	`ai-runtime-debugging`, `spryker-runtime`
Fix	Applies the minimal fix and re-runs the reproduction	—
Functional tests	Adds or updates Codeception tests	`codecept-functional`
Static validation	Runs static analysis over the changed code	`static-validation`
Code review	Gate — blocks on a blocker or major finding	`code-review`
QA	Gate — four-bucket coverage against the running application	`spryker-qa-coverage`
Cypress E2E	Conditional — fixes, improves, or adds an end-to-end spec for the bug	`cypress-tests`
Final verification	Confirms the symptom is gone in the running application	`spryker-verifier`, `spryker-runtime`
Commit	Always commits; push and pull request depend on your mode and channel	—
Report	Outcome, root cause, decisions, gate results, and log paths	—

The verification loop

Code review, QA, final verification, and remote CI are gates. A failure in any of them draws from one shared attempt counter and loops back to the root cause stage to re-investigate, then forward through the full chain again.

The hard stop is three attempts. Beyond that the run stops and reports — nothing is pushed, and no pull request is marked ready with a known-broken state.

A Cypress failure that indicts the fix rather than the test joins the same loop.

Modes

Collaborative — the skill stops at the important decision points and before any push, so you can review.
Autonomous — after the single intake step the skill runs unattended to a pushed draft pull request. Every fork is a logged decision rather than a question. The only hard stops are a dirty or stale base branch and the attempt budget.

Pull request delivery

At intake the skill asks whether to open a pull request and through which channel, then probes what is actually available:

gh — the GitHub CLI
mcp — a connected forge MCP server for GitHub, GitLab, Bitbucket, or another host
git-only — pushes a branch without opening a pull request
none — local only

The GitHub CLI is never assumed. If the chosen channel cannot open a pull request, the skill degrades to a clean terminal state — it commits, pushes where possible, and hands over the command to create the pull request yourself.

Run artifacts

Every file the run produces lives in one folder per bug under .ai-dev/spryker-bugfix/<bugfix-id>/, which survives loopbacks and scheduled wake-ups:

File	Role
`run.log`	The timeline — one line per stage boundary, every loopback, and every gate verdict
`decisions.md`	The rationale — critical decisions, open questions, and risks
`repro-notes.md`	The reproduction scenario in full
`<stage>-attempt<N>.log`	Bulk output per gate — tests, static analysis, review, verification, and CI logs
`watch-state.md`	The handoff the remote CI watch loop re-reads on each wake-up

Requirements

A running Spryker project (Docker SDK up) with the AI Dev SDK installed
An AI tool with the SDK’s skills loaded — either through the Claude Code plugin or via ai-dev:setup for another supported tool

spryker-bugfix README — the skill’s own reference in the plugin repository
Skills and Agents — the full reference of every skill and agent this orchestrator composes
Customization Workflow — the same orchestration shape for building new features
Overview — module and ai-dev:setup command

Implement Publish and Synchronization

Fri, 14 Aug 2026 05:58:44 +0000

Usually in order to publish some data to the frontend from your database, you need to create a module that will handle those actions. Usual recommendation is to create a module that will handle the *Publish* and *Synchronize* processes. The module will contain the code that will handle the events, prepare data, and synchronize it to the frontend. All required steps are described in this article. ## 1. Create a base module We recommend putting a `Publish & Synchronization` related code in a separate module. A module usually represents one database or domain entity. For example `StoreStorage` module will populate storage with `Store` data and also with data from related tables like `StoreContext`. You can create a module with a few options: - Create a module manually. For details, see [Create a module](/docs/dg/dev/backend-development/extend-spryker/create-modules). - Use Spryks for creating a module. For details, see [Spryks](/docs/dg/dev/sdks/sdk/spryks/spryks). - Use an [AI coding assistant](/docs/dg/dev/ai/ai-dev/ai-dev-overview.html) to create a module. You can ask the AI agent to use this document as a reference. {% info_block infoBox "Naming convention"%} In the Spryker packages, you can find modules that sync data to the *Storage* or *Search* database. The module name is usually suffixed with `Storage` or `Search`. For example, `GlossaryStorage` or `CmsPageSearch`. This is not a hard requirement, but we recommend following this convention to make it easier to understand the purpose of the module. {% endinfo_block %} At least a basic files structure of the module should be ready after this step. ## 2. Enable required behaviors To automatically trigger events for the *Publish* and *Synchronize* processes, you need to enable the *Event* behavior in your Propel model. This behavior is used to trigger events when an entity is created, updated, or deleted. Without this behavior, you will have to trigger events manually. Let's say you want to have stores data available in Storage. You need to enable the *Event* behavior for `spy_store` table in your Propel model XML schema file. ```xml

``` The `parameter` element specifies when events should be triggered. It has four attributes: - `name`: the parameter name. It must be unique in your Propel model. - `column`: the column that needs to be updated to trigger an event. To track all columns, use the *** (asterisk) symbol. - `value`: a value to compare. - `operator`: the comparison operator. You can use any PHP comparison operators (===, ==, !=, !==, <, >, <=, >=, <>) for this purpose. The *value* and *operator* attributes are optional. You can use them to filter changes based on certain criteria. The following example triggers an event only if the value of the `quantity` column is `0`: ```xml ``` The following example triggers an event when the value of any column is less than or equals 10: ```php ``` Initializes the Propel ORM database layer: ```bash console propel:install ``` Now `create`, `update` and `delete` events will be triggered automatically when you do those actions with Propel entities. {% info_block infoBox "Info"%} ```php $storeEntity = SpyStoreQuery::create()->findOne(); $storeEntity->setName('Silpo'); $storeEntity->save(); ``` {% endinfo_block %} This actions will trigger the `Entity.spy_store.update` event, which can be used to publish data. `Entity.{table_name}.{action}` is a naming convention for the Publish events. The `{table_name}` part is the name of the Propel table that triggers the event, and `{action}` is one of the following actions: create, update, or delete. In the Spryker packages you can find that such events are defined in the shared `Config` class of the module. For example, the `\Spryker\Shared\StoreStorage\StoreStorageConfig` class can be created to define the events for the `spy_store` table. ```php /** * Specification: * - Represents spy_store entity creation event. * * @api * * @var string */ public const ENTITY_SPY_STORE_CREATE = 'Entity.spy_store.create'; /** * Specification: * - Represents spy_store entity change event. * * @api * * @var string */ public const ENTITY_SPY_STORE_UPDATE = 'Entity.spy_store.update'; /** * Specification: * - Represents spy_store entity deletion event. * * @api * * @var string */ public const ENTITY_SPY_STORE_DELETE = 'Entity.spy_store.delete'; ``` This is not a mandatory step, but it is a good idea to define event names in the code once and use it later. ## 3. Create a new storage or search table The next step is to create a database table, that is used as a mirror for the corresponding *Storage* or *Search* data. This table is used to store records that will be later synced into Storage or Search database. {% info_block infoBox "Naming convention"%} As a naming convention, it's recommended to append `_storage` to the end of the table name if it's synchronized with storage database (for example Redis), and `_search` if it's synchronized with search database (for example Elasticsearch). {% endinfo_block %} All mirror tables must implement the *Synchronization* behavior, that is used to synchronize data to *Storage* or *Search*. Also, the table must populate foreign keys necessary to backtrack the Propel entities. This is how a storage table for store entity can look. The *Synchronization* behavior will add a `data` and `key` columns automatically, so you don't need to define them in the table definition, but you still can do it if you want to specify the column type or other parameters. Also any fields that might be required for the synchronization process can be added to the table definition. ```xml

``` Let's also take a look at the example of a search table: ```xml

``` The *Synchronization* behavior added by the above schema files adds a column that stores the actual data to synchronize to Storage or Search (in JSON format). The column name is *data*. Synchronization behavior parameters: - `resource`— specifies the Storage or Search namespace to synchronize with. - `store`— specifies whether it's necessary to specify a store for an entity. - `locale`— specifies whether it's necessary to specify a locale for an entity. - `key_suffix_column`— specifies the name of the column that will be appended to the Redis or Elasticsearch key to make the key unique. If this parameter is omitted, then all entities will be stored under the same key. - `queue_group`— specifies the queue group for synchronization. - `params`— specifies search parameters (Search only). - `queue_pool`— specifies the queue pool name for synchronization. If store is not required for the entity, then this parameter must be set to a string with the pool name. If store is required, then this parameter must be omitted. Make sure that after required tables are created, you run the `propel:install` command to create the tables in the database. ## 4. Create required plugins After all required tables are in place, we need to add some code that will move data from the main table to the `_storage` or `_search` one. And the code that will send data from those table to actual Storage or Search databases. To implement the *Publish* and *Synchronize* process, you need to create a few plugins. The plugins are used to handle events, prepare data, and synchronize it to the frontend. You need at least two plugins: one for handling the *Publish* events and another one for synchronizing data to the frontend. ### 4.1 Create a Publisher plugin A Publisher plugin is used to handle the *Publish* events. It is a plugin that implements the `Spryker\Zed\PublisherExtension\Dependency\Plugin\PublisherPluginInterface` interface and contains the `handleBulk` method. The method accepts an array of event transfers and an event name. The `handleBulk` method is meant to be called in order to prepare the data for the storage or search tables and save it in the *Storage* or *Search* database tables. The `getSubscribedEvents` defines the events that the plugin listens to. ```php class StoreWritePublisherPlugin extends AbstractPlugin implements PublisherPluginInterface { /** * {@inheritDoc} * - Gets Store ids from event transfers. * - Publishes store data to storage table. * * @api * * @param array<\Generated\Shared\Transfer\EventEntityTransfer> $transfers * @param string $eventName * * @return void */ public function handleBulk(array $transfers, $eventName): void { $this->getFacade()->writeCollectionByStoreEvents($transfers); } /** * {@inheritDoc} * * @api * * @return array */ public function getSubscribedEvents(): array { return [ StoreStorageConfig::ENTITY_SPY_STORE_UPDATE, StoreStorageConfig::ENTITY_SPY_STORE_CREATE, ]; } } ``` This plugin must be registered in the `\Pyz\Zed\Publisher\PublisherDependencyProvider::getPublisherPlugins()` method. The plugins are listening to the default publish queue, which is defined in the `\Pyz\Zed\Publisher\PublisherConfig::getPublishQueueName()` method. Custom queue names can be set by providing a key as a queue name in the `\Pyz\Zed\Publisher\PublisherDependencyProvider::getPublisherPlugins()` method. For example ```php protected function getPublisherPlugins(): array { return [ ... PublishAndSynchronizeHealthCheckConfig::PUBLISH_PUBLISH_AND_SYNCHRONIZE_HEALTH_CHECK => [ new PublishAndSynchronizeHealthCheckStorageWritePublisherPlugin(), new PublishAndSynchronizeHealthCheckSearchWritePublisherPlugin(), ], ... ]; } ``` In addition `\Spryker\Zed\PublisherExtension\Dependency\Plugin\PublisherTriggerPluginInterface` can be implemented. It will be used by `publish:trigger-events` command in order to go through all entities in entity table and trigger events for them. This is useful when you need to re-publish all data, for example, after changing the mapping or if some data was lost in the Storage or Search database. ```php class StorePublisherTriggerPlugin extends AbstractPlugin implements PublisherTriggerPluginInterface { /** * @uses \Orm\Zed\Store\Persistence\Map\SpyStoreTableMap::COL_ID_STORE * * @var string */ protected const COL_ID_STORE = 'spy_store.id_store'; /** * {@inheritDoc} * * @api * * @param int $offset * @param int $limit * * @return array<\Spryker\Shared\Kernel\Transfer\AbstractTransfer> */ public function getData(int $offset, int $limit): array { $storeCriteriaTransfer = (new StoreCriteriaTransfer()) ->setPagination( (new PaginationTransfer()) ->setLimit($limit) ->setOffset($offset), ); return $this->getFactory() ->getStoreFacade() ->getStoreCollection($storeCriteriaTransfer) ->getStores() ->getArrayCopy(); } /** * {@inheritDoc} * * @api * * @return string */ public function getResourceName(): string { return StoreStorageConfig::STORE_RESOURCE_NAME; } /** * {@inheritDoc} * * @api * * @return string */ public function getEventName(): string { return StoreStorageConfig::STORE_PUBLISH_WRITE; } /** * {@inheritDoc} * * @api * * @return string|null */ public function getIdColumnName(): ?string { return static::COL_ID_STORE; } } ``` ### 4.2 Create a Synchronization plugin A Synchronization plugin is used to synchronize data to the frontend. It is a plugin that implements the `\Spryker\Zed\SynchronizationExtension\Dependency\Plugin\SynchronizationDataBulkRepositoryPluginInterface` interface and contains the `getData` method. The method accepts an offset, limit, and an array of IDs and returns an array of `SynchronizationDataTransfer` objects. Those objects will be used to synchronize data to the frontend as they contain data from _storage or _search tables. ```php class StoreSynchronizationDataPlugin extends AbstractPlugin implements SynchronizationDataBulkRepositoryPluginInterface { /** * Specification: * - Returns the resource name of the storage or search module * * @api * * @return string */ public function getResourceName(): string { return StoreStorageConfig::STORE_RESOURCE_NAME; } /** * Specification: * - Returns true if this entity has multi-store concept * * @api * * @return bool */ public function hasStore(): bool { return false; } /** * Specification: * - Returns SynchronizationDataTransfer[] according to provided offset, limit and ids. * * @api * * @param int $offset * @param int $limit * @param array $ids * * @return array<\Generated\Shared\Transfer\SynchronizationDataTransfer> */ public function getData(int $offset, int $limit, array $ids = []): array { return $this->getFacade()->getStoreStorageSynchronizationDataTransfers( $this->createStoreStorageCriteriaTransfer($offset, $limit, $ids), ); } /** * Specification: * - Returns array of configuration parameter which needed for Redis or Elasticsearch * * @api * * @return array */ public function getParams(): array { return []; } /** * Specification: * - Returns synchronization queue name * * @api * * @return string */ public function getQueueName(): string { return StoreStorageConfig::STORE_SYNC_STORAGE_QUEUE; } /** * Specification: * - Returns synchronization queue pool name for broadcasting messages * * @api * * @return string|null */ public function getSynchronizationQueuePoolName(): ?string { return $this->getFactory() ->getConfig() ->getStoreSynchronizationPoolName(); } } ``` If the entity is store related - `hasStore()` method must return `true`, otherwise `getSynchronizationQueuePoolName()` need to return a string with the pool name. It should be the same as is provided in table definition [queue_pool](#create-a-new storage-or-search-table) of Synchronization behavior. Below you can see an example of the code that provides data for the `getData()` method. Data taken from the Storage table and mapped to the `SynchronizationDataTransfer` object.: ```php public function getStoreStorageSynchronizationDataTransfers(StoreStorageCriteriaTransfer $storeStorageCriteriaTransfer): array { $storeStorageQuery = $this->getFactory()->createStoreStorageQuery(); $storeStorageConditionsTransfer = $storeStorageCriteriaTransfer->getStoreStorageConditions(); if ($storeStorageConditionsTransfer && $storeStorageConditionsTransfer->getStoreIds()) { $storeStorageQuery->filterByFkStore_In($storeStorageConditionsTransfer->getStoreIds()); } $paginationTransfer = $storeStorageCriteriaTransfer->getPagination(); if ($paginationTransfer) { $storeStorageQuery = $this->preparePagination($storeStorageQuery, $paginationTransfer); } $storeStorageEntities = $storeStorageQuery->find(); $synchronizationDataTransfers = []; foreach ($storeStorageEntities as $storeStorageEntity) { /** @var string $data */ $data = $storeStorageEntity->getData(); $synchronizationDataTransfers[] = (new SynchronizationDataTransfer()) ->setData($data) ->setKey($storeStorageEntity->getKey()); } return $synchronizationDataTransfers; } ``` ## 5. Configure Publish & Synchronization queues If you want to use separate queues for your entity you need to configure it by providing a key as a queue name in `Pyz\Zed\Publisher\PublisherDependencyProvider::getPublisherPlugins()` as mentioned before and also in the `Pyz\Zed\Queue\QueueDependencyProvider::getProcessorMessagePlugins()` by setting message and sync processors. To deliver the prepared data to the frontend, you need to configure synchronization queues in order. This can be also done in `Pyz\Zed\Queue\QueueDependencyProvider::getProcessorMessagePlugins()`. Spryker implemented two generic synchronization message processor plugins for synchronizing data to the frontend: - `Spryker\Zed\Synchronization\Communication\Plugin\Queue\SynchronizationStorageQueueMessageProcessorPlugin` for synchronizing data to Redis, and - `Spryker\Zed\Synchronization\Communication\Plugin\Queue\SynchronizationSearchQueueMessageProcessorPlugin` for synchronizing data to Elasticsearch. {% info_block infoBox "Naming convention"%} As a naming convention, names of queues that synchronize data to Redis start with *sync.storage.*, and names of queues that synchronize data to Elasticsearch start with *sync.search.*. {% endinfo_block %} Error queue is created automatically by adding error suffix to the queue name. For example, if the queue name is `sync.storage.product`, then the error queue name is `sync.storage.product.error`. ```php class QueueDependencyProvider extends SprykerDependencyProvider { /** * @param \Spryker\Zed\Kernel\Container $container * * @return array<\Spryker\Zed\Queue\Dependency\Plugin\QueueMessageProcessorPluginInterface> */ protected function getProcessorMessagePlugins(Container $container): array // phpcs:ignore SlevomatCodingStandard.Functions.UnusedParameter { return [ EventConstants::EVENT_QUEUE => new EventQueueMessageProcessorPlugin(), EventConstants::EVENT_QUEUE_RETRY => new EventRetryQueueMessageProcessorPlugin(), PublisherConfig::PUBLISH_QUEUE => new EventQueueMessageProcessorPlugin(), PublisherConfig::PUBLISH_RETRY_QUEUE => new EventRetryQueueMessageProcessorPlugin(), StoreStorageConfig::STORE_SYNC_STORAGE_QUEUE => new SynchronizationStorageQueueMessageProcessorPlugin(), ]; } } ``` As you can see, for the Store entity, the `Spryker\Shared\StoreStorage\StoreStorageConfig::STORE_SYNC_STORAGE_QUEUE` queue is used for synchronizing data to Redis. The queue name is defined in the `Spryker\Shared\StoreStorage\StoreStorageConfig` class. For the publishing we are using the default publish queue, which is defined in the `Spryker\Shared\Publisher\PublisherConfig::PUBLISH_QUEUE` constant. But it also can use a separate queue for publishing data, if you provide a key as a queue name in the `Pyz\Zed\Publisher\PublisherDependencyProvider::getPublisherPlugins()` method. ## 6. Validate the implementation To validate the implementation, you can update a Propel entity in the Back Office and check if the data is published to the *Storage* or *Search* databases. If any errors occur during the process, you can check the error queue in the RabbitMQ management UI. The error queue is created automatically by adding an `error` suffix to the queue name. For the Search you can check this [document](/docs/pbc/all/search/latest/base-shop/tutorials-and-howtos/configure-a-search-query.html) to get more info how you can work with data that you just sync. For the Storage on the other hand, you can check this [document](/docs/dg/dev/backend-development/client/use-and-configure-redis-as-a-key-value-storage) to learn more.

Release notes 202606.0

Fri, 14 Aug 2026 05:50:58 +0000

Spryker Cloud Commerce OS is an end-to-end solution for digital commerce. This document contains a business-level description of new features and improvements. For information about installing Spryker, see [Getting started guide](/docs/dg/dev/development-getting-started-guide). ## B2B Business-Ready Commerce Experiences ### Recurring Orders {% include badge.html type="early-access,feature" %} Recurring Orders let buyers create cadence-based repeat purchases during checkout and execute them automatically on a defined schedule. The feature includes controls for confirmations and approvals, as well as review and recovery flows for basket changes, price changes, or ERP-related issues. **Key capabilities:** - Create recurring order schedules such as weekly, bi-weekly, or monthly - Support buyer-controlled confirmations, skips, modifications - Detect basket drift, price drift, and ERP errors with clear recovery flows **Business benefits:** - Reduces manual effort for repeat procurement - Helps prevent missed or delayed replenishment orders - Increases trust through controlled automation, governance, and auditability **Documentation:** - [Recurring Orders Feature Overview](/docs/pbc/all/order-experience-management/latest/base-shop/feature-overviews/recurring-orders-feature-overview.html) - [Install Recurring Orders](/docs/pbc/all/order-experience-management/latest/base-shop/install-and-upgrade/install-features/install-the-recurring-orders-feature) ### Budget & Cost Centers {% include badge.html type="feature" %} Budget & Cost Centers introduces native purchasing controls for departmental or project-based spending in B2B commerce. Companies can manage budgets and cost centers directly in Spryker to support compliant, auditable, and policy-driven purchasing workflows. **Key capabilities:** - Define and manage cost centers for purchasing activities - Enforce budgets directly within procurement workflows - Align spend controls with existing approval processes **Business benefits:** - Reduces overspending risk through built-in budget enforcement - Improves financial transparency across teams and projects - Streamlines procurement with consistent spend governance in one system **Documentation:** - [Purchasing Control Feature Overview](/docs/pbc/all/cart-and-checkout/latest/base-shop/feature-overviews/purchasing-control-feature-overview) - [Install Purchasing Control](/docs/pbc/all/cart-and-checkout/latest/base-shop/install-and-upgrade/install-features/install-the-purchasing-control-feature) ### New Spryker Design System Storefront We extended the Spryker design system across key storefront pages, including product listing, product detail, and cart pages. This creates a more consistent and modern buyer experience while giving teams reusable components for faster delivery. **Key capabilities:** - Design system applied across the product details page - New reusable components such as cart entries, pagination, and quantity selectors - Storybook documentation for reference and reuse **Business benefits:** - Improves buyer trust with a more polished storefront experience - Reduces future implementation and QA effort through reusable patterns - Strengthens Spryker's out-of-the-box storefront for demos and evaluations

### Search Statistics & Google Analytics {% include badge.html type="feature" %} Search Statistics brings native search analytics to the Back Office for customers using ElasticSearch. Business users can review frequent searches and zero-result searches to better understand buyer behavior and optimize product discovery. **Key capabilities:** - View top frequent searches and top zero-result searches in the Back Office - Filter analytics by time period and review detailed search data - Export search statistics to Google Analytics for further analysis and sharing **Business benefits:** - Reduces the need for custom project-specific search analytics implementations - Helps teams improve search relevance, synonyms, and catalog quality based on real data - Identifies search gaps that can negatively affect discoverability and conversion **Documentation:** - [Search Statistics Feature Overview](/docs/pbc/all/miscellaneous/latest/third-party-integrations/marketing-and-conversion/analytics/google-analytics/search-statistics) - [Install Search Statistics](/docs/pbc/all/miscellaneous/latest/third-party-integrations/marketing-and-conversion/analytics/google-analytics/install-search-statistics) ### Back Office usability improvements {% include badge.html type="improvement" %} We improved several Back Office interactions to make administration tasks clearer and less error-prone. This covers block and slot assignment validation. **Key capabilities:** - Restores validation feedback when saving block and slot assignments - Fixes missing menu highlight on the View Merchant page in the Back Office **Business benefits:** - Improves clarity during Back Office administration - Helps business users navigate merchant management more easily **Releases:** - [No validation errors when saving block + slot assignment](https://api.release.spryker.com/release-group/6509) ### PunchOut support in the Back Office {% include badge.html type="improvement" %} PunchOut support in the Back Office makes PunchOut integrations easier to configure and manage with a more low-code approach. Building on Spryker's native support for common PunchOut flows and cXML/OCI compatibility, this update adds a dedicated PunchOut section with relevant fields and configuration support. This helps solution teams deliver integrations with less custom development effort. **Key capabilities:** - Adds a dedicated PunchOut section in the Back Office - Supports configuration of relevant PunchOut integration fields in a more low-code way - Complements native cXML, OCI, and core PunchOut message handling capabilities **Business benefits:** - Reduces bespoke development effort for PunchOut integrations - Makes implementations more repeatable and faster across projects - Simplifies setup and maintenance for customers and implementation partners

**Documentation:** - [PunchOut Gateway](/docs/pbc/all/punchout-gateway/punchout-gateway.html) ### PunchCommerce Punchout Connector {% include badge.html type="feature" %} The PunchCommerce Punchout Connector extends Spryker's support for complex PunchOut scenarios through a partner integration. It is designed for use cases that require multiple eProcurement connectors and document handling beyond Spryker's native capabilities. This helps customers address more advanced procurement integration requirements. **Key capabilities:** - Connects Spryker with PunchCommerce for advanced PunchOut scenarios - Supports use cases with multiple eProcurement connectors - Adds support for document-handling requirements not covered by native capabilities **Business benefits:** - Broadens PunchOut coverage for more complex B2B procurement scenarios - Reduces the need for bespoke implementations in advanced projects - Expands ecosystem support through a specialized partner solution **Documentation:** - [https://gitlab.netzdirektion.de/packages/punchcommerce-spryker-module](https://gitlab.netzdirektion.de/packages/punchcommerce-spryker-module) ## Connected, and AI-Enabled Platform ### AI Dev SDK: AI-Assisted Customization for Spryker Projects {% include badge.html type="early-access" %} The AI Dev SDK helps teams customize Spryker projects faster and with less manual effort. It supports developers in generating quick proofs of concept and MVP customizations that follow Spryker's patterns and project conventions, with developers staying in control at each approval point. This helps teams validate ideas faster, keep customization quality more consistent, and lower the manual effort each one takes.

**Key capabilities:** - Orchestrates the full Spryker customization workflow, from research and planning through code generation, testing, and verification, with self-correction when issues are detected and developer approval at key checkpoints - Automates the technical work needed after every code change, including database migrations, cache rebuilds, and frontend builds - Offers two quality levels: quick PoC for validating ideas fast, and MVP for delivering code that follows Spryker's canonical patterns and project conventions **Business benefits:** - Speeds up delivery of Spryker customizations, whether a quick proof of concept or an MVP-grade build. - Reduces development effort and catches issues against Spryker and project standards earlier. - Lowers the cost of experimentation — quick PoCs make it cheap to validate an idea before investing in a full implementation. **Documentation:** - [AI Dev SDK Skills and Agents](/docs/dg/dev/ai/ai-dev/ai-dev-skills-and-agents.html) - [AI Dev SDK Customization Workflow](/docs/dg/dev/ai/ai-dev/ai-dev-customization-workflow.html) - [Claude Code](/docs/dg/dev/ai/ai-dev/ai-dev-claude-code.html) ### AI Commerce: Smart CMS for AI-assisted content creation {% include badge.html type="early-access" %} Smart CMS brings AI assistance directly into the CMS page and block creation in the Back Office. Content editors and business users can generate structured text content in-flow instead of writing or copying content manually. This reduces the effort required to create and update commerce content experiences at scale. {% include carousel.html images=" https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202606/bo_smart_cms_1.png||:: https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202606/bo_smart_cms_2.png||:: https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202606/bo_smart_cms_3.png||" %} **Key capabilities:** - Generates CMS page and block content directly in the Back Office authoring flow - Accepts source attachments, such as documents with customer questions, to generate structured content like FAQ pages - Understands Spryker-specific content items so generated content fits existing content structures **Business benefits:** - Reduces manual effort for routine content creation and updates - Improves productivity for content editors and business admins - Helps scale content operations more efficiently as content needs grow **Documentation:** - [Smart CMS Content Assistant](/docs/pbc/all/ai-commerce/latest/smart-cms-content-assistant) - [Install Smart CMS Content Assistant](/docs/dg/dev/ai/ai-commerce/content-assistant/install-smart-cms-content-assistant#prerequisites) ### AI Foundation: Back Office AI Configuration {% include badge.html type="early-access" %} AI Foundation now includes a unified configuration experience in the Back Office for managing AI providers, models, prompts, and feature-specific behavior. This gives business and operational users a clearer, more consistent way to activate and control AI-powered capabilities, including switching AI vendors or models on the fly, without developer involvement or redeployment. {% include carousel.html images=" https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202606/bo_ai_configuration_1.png||:: https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202606/bo_ai_configuration_2.png||" %} **Key capabilities:** - Centralizes AI provider and credential management in one configuration area - Supports feature-level enablement and control of AI behavior, including AI vendor, model, and prompt configuration, with no code changes or deployments required - Provides an extensible foundation designed to support additional AI-powered features over time **Business benefits:** - Simplifies setup and onboarding for AI-powered features - Gives merchants more control over AI behavior, output quality, and governance - Reduces configuration errors and repetitive administrative work **Documentation:** - [Configure multiple AI providers for AI Commerce](/docs/dg/dev/ai/ai-commerce/configure-multiple-ai-providers) ### AI Foundation: Back Office AI Cost Estimator {% include badge.html type="early-access" %} The AI Cost Estimator adds estimated AI cost visibility to the AI Audit Logs in the Back Office. Admins can configure model pricing once and then see estimated costs per interaction, total estimated spend, and breakdowns by provider and model. This makes it easier to understand the cost of individual AI-powered commerce features and make informed decisions about their value and continued use. {% include carousel.html images=" https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202606/bo_ai_cost_estimator_1.png||:: https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202606/bo_ai_cost_estimator_2.png||" %} **Key capabilities:** - Shows estimated cost per AI interaction in the Audit Logs page - Provides total estimated cost and provider and model-level cost breakdowns based on active filters - Uses customer-configured provider and model prices, including support for multiple currencies **Business benefits:** - Improves visibility into AI operating costs across commerce features - Supports better governance and value assessment of AI capabilities - Reduces manual work previously needed to estimate AI spend from token usage **Documentation:** - [AI Audit Logs & Cost Estimations](/docs/dg/dev/ai/ai-foundation/ai-foundation-audit-logs) ### GLUE REST API migration to API Platform {% include badge.html type="feature" %} Spryker has modernized its internal GLUE REST API infrastructure by migrating it to API Platform. This change is backward compatible for existing API clients, while making APIs easier to maintain, extend, and evolve internally. It also improves the foundation for delivering new endpoints and capabilities faster. **Key capabilities:** - Keeps existing external API contracts unchanged for current clients and consumers - Replaces custom internal API infrastructure with API Platform - Enables more standardized API generation, validation, and documentation **Business benefits:** - Accelerates API delivery and reduces development effort for new endpoints - Improves maintainability and extensibility of the API layer - Supports more consistent and predictable machine-to-machine integrations **Documentation:** - [API Strategy](/docs/integrations/spryker-api/getting-started-with-apis/api-strategy.html) - [Spryker API roadmap and adoption](/docs/integrations/spryker-api/getting-started-with-apis/api-roadmap-and-adoption#whats-on-the-roadmap.html) - [Storefront API B2B Demo Shop reference](/docs/integrations/spryker-api/storefront-api/api-references/storefront-api-b2b-demo-shop-reference.html) ### Backend API added to the Spryker API Strategy {% include badge.html type="feature" %} Spryker extended its API strategy to cover the Backend API, the application for administrative and system-to-system integrations. The strategy now documents the API types available under the Backend API—starting with the Back Office API you can build on today—and the types planned on the roadmap, all built on API Platform integration. As with the rest of the strategy, existing Glue Backend APIs remain fully supported with no End-of-Life and no forced migration. **Key capabilities:** - Documents the Backend API application and its API types, and clarifies that the Backend API application is distinct from the Back Office API type - Back Office API is available today for administrator-level and trusted internal integrations - Roadmap types documented for planning: Merchant API, Merchant Data Exchange API, Data Exchange API, and Async Event API - Guidance for choosing a Backend API type by caller and data-flow shape—record-by-record, bulk, or event-driven **Business benefits:** - Gives a clear, forward-looking view of backend integration options across administration, merchant, data exchange, and events - Protects existing Glue Backend API investments with a no-End-of-Life, no-forced-migration commitment - Speeds up planning for ERP, PIM, OMS, and marketplace integrations with consistent guidance **Documentation:** - [Spryker API Strategy](/docs/integrations/spryker-api/getting-started-with-apis/api-strategy.html) - [Spryker API roadmap and adoption](/docs/integrations/spryker-api/getting-started-with-apis/api-roadmap-and-adoption.html) ## Efficient and Flexible Cloud Foundation ### Propel 2.0 LTS {% include badge.html type="improvement" %} This work includes advancing Propel toward a stable release and increasing active maintenance. **Documentation:** - [PropelORM](https://github.com/propelorm/Propel2/releases/tag/2.0.0) ### Maintenance and service updates {% include badge.html type="improvement" %} We rolled out regular maintenance and service updates across cloud components to keep environments secure, stable, and maintainable. This includes updates to core services and supporting infrastructure components. These changes help reduce operational risk and technical debt over time. **Key capabilities:** - Updates core services and infrastructure components such as Nginx 1.30, and Docker images - Improves long-term maintainability of cloud services - Updated multiple dependencies **Business benefits:** - Improves system reliability and operational resilience - Updates `shell-quote` to a patched version addressing a critical shell injection vulnerability. - Upgrades `symfony/runtime` to address unsafe request argument handling. - Upgrades `symfony/monolog-bridge` to address unauthenticated log listener exposure. **Documentation:** - [Docker Images](/docs/about/all/releases/image-releases/spryker-php/release-notes-spryker-php-20260608.html) ### Key-Value Storage Optimization for Dynamic Store Mode {% include badge.html type="improvement" %} We optimized key-value storage usage for Dynamic Store Mode to reduce duplicated data across store and locale combinations. This improvement lowers Valkey/Redis memory consumption and key volume while keeping the solution backward compatible and opt-in. It is especially valuable for deployments with multiple stores and locales. **Key capabilities:** - Reduces duplicated product abstract and URL storage data in Dynamic Store Mode - Keeps compatibility with existing storage formats and supports gradual adoption - Provides an opt-in configuration and migration path for controlled rollout **Business benefits:** - Improves scalability for multi-store and multi-locale setups - Helps delay or avoid costly cache instance size increases **Documentation:** - [KV Storage Deduplication](/docs/dg/dev/guidelines/performance-guidelines/kv-storage-deduplication.html) ### Queue processing resilience and worker behavior {% include badge.html type="improvement" %} We improved queue processing behavior to reduce the risk of blocked or stalled message handling. The update addresses long-running worker processes, retry queue handling, and premature worker exits while messages are still waiting. **Key capabilities:** - Improves handling of long-running or stuck queue worker child processes - Prevents failed messages from being lost when no retry queue exists - Ensures `queue:worker:start --stop-when-empty` behaves more reliably **Business benefits:** - Reduces the risk of blocked publish and processing pipelines - Improves operational stability for queue-based workloads - Helps teams recover from processing failures more predictably **Documentation:** - [Publish and synchronization (queue and event performance)](/docs/dg/dev/guidelines/performance-guidelines/keeping-dependencies-updated#publish-and-synchronization-queue-and-event-performance) - [Enable queue worker wait limit](/docs/dg/dev/guidelines/performance-guidelines/general-performance-guidelines#enable-queue-worker-wait-limit) ### Cloud security improvements {% include badge.html type="improvement" %} We delivered a set of cloud security improvements to strengthen infrastructure protection and reduce unnecessary access paths. These updates address container-to-instance access risks, improve IAM controls, and support more secure cloud operations. They also include compatibility adjustments for newer managed service defaults. **Key capabilities:** - Tightens IAM policy controls to prevent overly broad administrative permissions in customer PaaS accounts - Adds compatibility handling for MariaDB 11.8 secure transport defaults in infrastructure templates **Business benefits:** - Reduces the risk of unauthorized access to cloud resources and secrets - Improves security posture across customer environments - Helps maintain secure operations as infrastructure components evolve ### RDS Auditability Extensions {% include badge.html type="feature" %} We have introduced advanced activity tracking for database operations to enhance security governance and accountability across your environments. This update provides clear visibility into data modifications and structural changes within your live production systems. **Key capabilities:** - Monitors and records database operations performed in production environments - Securely retains activity logs for a rolling two-year period to satisfy standard corporate compliance and security policies. **Business benefits:** - Provides complete transparency into exactly who executed which database operation, ensuring robust compliance and clear user accountability - Enhances Security Auditing: Simplifies the detection of potential application exploits—such as SQL injections—by tracking critical service account behaviors ### Persistent Jenkins Configuration {% include badge.html type="improvement" %} We have updated our cloud automation storage model to significantly improve platform stability. This enhancement ensures that your custom adjustments are safely preserved during routine platform updates and security maintenance. **Key capabilities:** - Permanently safeguards all manually created configurations and fine-tunings across system upgrades and server restarts - Unlocks continuous, automated operating system upgrades and critical infrastructure patching to keep your system completely protected **Business benefits:** - Eliminates the risk of losing bespoke operational settings, removing the need for costly and repetitive manual reconfiguration work - Enhances your overall security posture by allowing the seamless deployment of critical patches without disrupting business continuity ### Customer authentication and session handling {% include badge.html type="improvement" %} We fixed issues affecting customer authentication and session behavior in edge cases. These changes improve reliability for API authentication and login flows. **Key capabilities:** - Prevents unintended API authentication behavior related to `spy_customer.registered = NULL` - Improves error handling for invalid JWT tokens in warehouse token requests - Avoids false-positive WAF blocking caused by specific patterns that are not malicious. **Business benefits:** - Improves trust in authentication flows - Reduces login-related support cases - Helps secure customer access scenarios more consistently **Documentation:** - [spy_customer.registered=NULL allows API auth](https://api.release.spryker.com/release-group/6618) - [Adjusted Quote data and UI fixes](https://api.release.spryker.com/release-group/6621) - [Added optional base64 encoding for gateway](https://api.release.spryker.com/release-group/6633) ### Voucher code tracking and order display accuracy in the Back Office {% include badge.html type="improvement" %} We fixed issues with orders that use multiple voucher-code discounts. The Back Office now shows the correct voucher code for each applied discount, and usage counters are updated correctly for all voucher codes used in an order. **Key capabilities:** - Displays the actual voucher code used for each discount in the Back Office order overview. - Correctly increments usage counters for all voucher codes applied to an order. - Supports orders with multiple non-exclusive voucher-based discounts more accurately. **Business benefits:** - Improves trust in discount reporting and order auditability. - Reduces manual verification effort for merchandising and support teams. - Ensures voucher campaign performance is tracked correctly. **Release:** - [Multiple voucher codes on order](https://api.release.spryker.com/release-group/6640) ### Product and catalog experience improvements {% include badge.html type="improvement" %} We improved several product-related experiences in the Back Office and storefront to make catalog management and shopping journeys more reliable. The update covers product images in Zed, product readiness visibility, replacement product rendering, and marketplace product offer handling in carts. **Key capabilities:** - Restores product concrete image visibility in the Back Office **Business benefits:** - Gives business users clearer product status information - Reduces confusion during catalog maintenance in the Back Office - Improves cart accuracy for marketplace shopping scenarios **Documentation:** - [Show Product Concrete images in Zed](https://api.release.spryker.com/release-group/6501) ### Storefront performance, search, and content management improvements {% include badge.html type="improvement" %} We improved storefront performance, search reliability, content management efficiency, and product data consistency to deliver faster customer experiences, more accurate search results, and better scalability across high-volume environments. **Key capabilities:** - Improves checkout and customer-facing page performance by reducing unnecessary backend requests and eliminating Redis bottlenecks for large datasets. - Enhances product data publishing and search indexing to keep Storage and Search synchronized with catalog changes across multi-store and multi-locale environments. - Generates search index mappings correctly for advanced analyzer and multi-field configurations. - Optimizes CMS page version history loading for better Back Office performance when managing long-lived content. - Preserves locale selection across storefront, configurator, agent emulation, and authentication flows for a more consistent user experience. **Business benefits:** - Delivers faster storefront and checkout experiences, even at scale. - Improves search accuracy and product data consistency across channels. - Enhances Back Office productivity for content managers. - Reduces backend load and improves platform scalability. - Provides a more consistent localized shopping experience for customers and support agents. **Documentation and Releases:** - [Cart page and checkout for large carts](/docs/dg/dev/guidelines/performance-guidelines/keeping-dependencies-updated#cart-page-and-checkout-for-large-carts-100-items) - [Adjusted reading shipment type uuids on Checkout](https://api.release.spryker.com/release-group/5736) - [Added child fields to index map](https://api.release.spryker.com/release-group/6616) - [CMS page versions query for the form loads too much data](https://api.release.spryker.com/release-group/6630) - [Remediate error in spryker/category >= 5.23.0](https://api.release.spryker.com/release-group/6452) - [Remove Concrete Product on deactivation](https://api.release.spryker.com/release-group/6500) - [Remove product concrete from the search index](https://api.release.spryker.com/release-group/6574) - [Locale selection preserved when navigating in the Storefront](https://api.release.spryker.com/release-group/6521) - [Performance improvements to the checkout](https://api.release.spryker.com/release-group/6479)

Release notes 202410.0

Fri, 14 Aug 2026 05:50:58 +0000

### Business benefits - Streamline commission management through automated calculation and application, reducing manual effort and errors. - Adapt commission structures to evolving business needs seamlessly, supporting marketplace growth and expansion. - Connect with third-party systems to generate invoices and facilitate payouts, ensuring operational efficiency and financial accuracy. ### Documentation [Marketplace Merchant Commission feature overview](/docs/pbc/all/merchant-management/latest/marketplace/marketplace-merchant-commission-feature-overview.html) ## Business intelligence powered by Amazon QuickSight {% include badge.html type="feature" %} Amazon QuickSight is a business analytics tool integrated directly into the Back Office. This feature enables users to visualize data, create customizable dashboards, and perform deep analytics on sales, product performance, customer behaviors, and marketplace KPIs. By leveraging analytics, you can unlock new monetization opportunities and make more informed business decisions. ![analytics-dashboard](https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202410.0.md/analytics-dashboard.png) ### Business benefits - Immediate access to data analytics with editing, sharing, and viewing tools integrated directly into the Back Office. - With high customizability and numerous editing and sharing options, you can tailor your analyses to focus on the most important data. - Support for multiple data sources lets you aggregate data analysis across various systems and use just one tool for all your BI needs. ![analytics-analysis](https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202410.0.md/analytics-analysis.png) ### Documentation [Amazon QuickSight](/docs/pbc/all/business-intelligence/latest/amazon-quicksight-third-party-integration/amazon-quicksight.html) ## Variants section in the Merchant Portal {% include badge.html type="feature" %} The new Variants section in Merchant Portal streamlines the management of concrete products. You can now view, sort, filter, and bulk-edit concrete products belonging to different abstract products. ![mp-variants](https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202410.0.md/mp-variants.png) ### Business benefits - Reduces the complexity of managing concrete products - Improves operational efficiency ### Documentation - [Edit marketplace concrete products](/docs/pbc/all/product-information-management/latest/marketplace/manage-in-the-merchant-portal/concrete-products/edit-marketplace-concrete-products.html) - [Install the Merchant Portal - Marketplace Product feature](/docs/pbc/all/merchant-management/latest/marketplace/install-and-upgrade/install-features/install-the-merchant-portal-marketplace-product-feature.html) ## AI Features {% include badge.html type="early-access" %} {% include badge.html type="feature" %} AI-powered features implemented by connecting to third-party APIs: - Visual search: Enables users to search across the product catalog by uploading an image. - Product category suggestions: Automates product categorization in the Back Office. - Product translation: Automates the translation of product information in the Back Office. - Generation of product image alt text: Generates alt text for product images in the Back Office to improve accessibility and SEO. ### Business benefits - Offload routine tasks to AI. - Speed up your workflows. ### AI prerequisites The AI features leverage Open AI and are provided under the following conditions: - ChatGPT Plus, Team, or Enterprise license from OpenAI is required. - Provided as an Early Access release. Early Access releases are subject to specific legal terms. They're unsupported and don't provide production-ready SLAs. They can also be deprecated without a General Availability Release. Nevertheless, we welcome feedback from early adopters on these cutting-edge, exploratory features. - Available as an opt-in and are not automatically integrated into the core product with this release. - Projects take full responsibility for using AI. ### Documentation - [Smart Product Management](/docs/pbc/all/product-information-management/latest/base-shop/third-party-integrations/smart-product-management/smart-product-management) - [Visual Search powered by OpenAI](/docs/pbc/all/search/latest/base-shop/third-party-integrations/visual-search-powered-by-openai/install-visual-search-powered-by-openai) ## Payone ACP app update {% include badge.html type="feature" %} The Payone app now supports more payment methods. On top of credit card and Paypal, we have added the following payment methods: - Prepayment: Order items are shipped after the customer provides a payment receipt. - Klarna: As a leading global payments and shopping service, Krana supports direct payments, pay-after-delivery options, and installment plans. For customers, these options are a seamless one-click purchase experience that empowers them to pay when and how they choose. ### Business benefits - Increases customer satisfaction by providing more payment methods and options. - Configure your Order Management System to capture payments based on your specific business logic. - Feel secure that the payments follow international standards through fraud prevention and integrated risk management. ### Documentation [Payone ACP app](/docs/pbc/all/payment-service-provider/{{site.version}}/base-shop/third-party-integrations/payone/app-composition-platform-integration/payone-acp-app.html) ### Technical prerequisites [Install prerequisites and enable ACP](/docs/dg/dev/acp/install-prerequisites-and-enable-acp.html) ## Stripe ACP app for Marketplace {% include badge.html type="feature" %} The Stripe ACP app now fully supports the marketplace business model with the following options: - Marketplace or admin onboarding: Admin is onboarded and configures the Stripe ACP app. - Merchant onboarding and KYC: Each merchant is onboarded into the Marketplace and submits a KYC with Stripe. - Customer payment collection: Collects funds from customers through various payment methods, like credit cards, digital wallets, or bank transfers. - Authorization and processing: Authorization from the customer's bank or payment provider ensures that the funds are available and the transaction is legitimate. - Payment reconciliation: Confirmed payments and refunds are ingested through an API: payment and refund confirmations, pay-in reports, settlement funds. Funds are reconciled, including splits between 1P and 3P. - Seamless merchant payout: When directed, funds are released to the merchant, leveraging the preconfigured billing cycle rules, order status, and commission rules. This is often in near real-time. The capability can also connect with the Spryker Commission Engine to apply commissions. - Merchants withdraw funds: Merchants can transfer earnings into a local bank account in preferred currency. - Optimized payment flow: Redirect customers to a Stripe Elements page or integrate and customize it accordingly through a headless solution. ### Business benefits - Reach global markets: One payment provider covers 135 currencies, 45+ countries, 100+ payment methods accessible. - Increase conversion: Accelerate checkout. Calculated 10.5% revenue uplift with the use of Stripe Elements. ### Documentation [Stripe](/docs/pbc/all/payment-service-provider/latest/base-shop/third-party-integrations/stripe/stripe.html) ### Technical prerequisites [Install prerequisites and enable ACP](/docs/dg/dev/acp/install-prerequisites-and-enable-acp.html) ## Spryker GPTs {% include badge.html type="early-access" %} {% include badge.html type="feature" %} Spryker GPTs powered by OpenAI LLMs help developers automate crucial areas of software development: quality and performance. These GPTs increase developer efficiency without sacrificing high standards in QA and performance benchmarking: - Spryker DevQA Assistant: Assists in DevQA tasks by providing comprehensive QA checklists and insights into feature and module mappings and dependencies. - Spryker Cypress E2E Assistant: Assists with integration and use of the Cypress E2E testing framework; provides guidance, best practices, and real examples. - Spryker K6 Performance Assistant: Assists with generating K6 performance test scripts from provided API endpoints. ### Business benefits - Automate or accelerate repetitive tasks related to quality assurance and performance. - Achieve high-quality results while freeing up developer resources to pursue higher-value tasks for your business. ### AI prerequisites These GPTs leverage Open AI and are provided under the following conditions: - ChatGPT Plus, Team, or Enterprise license from OpenAI is required. - Provided as an Early Access release . Early Access releases are subject to specific legal terms. They're unsupported and don't provide production-ready SLAs. They can also be deprecated without a General Availability Release. Nevertheless, we welcome feedback from early adopters on these cutting-edge, exploratory features. - Available as an opt-in and are not automatically integrated into the core product with this release. - Projects take full responsibility for using AI. ### Documentation These GPTs have since been retired. For current AI-assisted development tooling, see the [AI Dev SDK](/docs/dg/dev/ai/ai-dev/ai-dev-overview.html). ## Audit logs {% include badge.html type="feature" %} Audit logs improve security monitoring and transparency by letting you track all security actions performed by users in all applications: Storefront, Back Office, Merchant Portal, and Glue API. Audit logs cover login related activities, including agent assist impersonation sessions. ![audit-logs](https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202410.0.md/audit-logs.png) ### Business benefits - Enhanced security monitoring: Track and review key user actions, such as login and password changes, across all platform areas. - Compliance support: Automatic deletion schedules let you comply with legal and data privacy standards. - Customizable logging: Adjust logging preferences to focus on specific events or applications, ensuring relevant activities are tracked. - Improved accountability: Tracking security-related user activities promotes accountability and transparency across the platform. ### Documentation - [Audit logs](/docs/dg/dev/backend-development/audit-logs/audit-logs.html) - [Working with logs](/docs/ca/dev/monitoring/working-with-logs.html) ## Dynamic Multistore {% include badge.html type="feature" %} Previously in early access, Dynamic Multistore is integrated into the core product in this release. Dynamic Multistore is an enhanced version of the multi-store capability. This feature enables Back Office users to create new stores without engineering support or having to redeploy the application. With this feature, multiple stores can also operate under the same domain. ![dynamic-multistore](https://spryker.s3.eu-central-1.amazonaws.com/docs/pbc/all/dynamic-multistore/dynamic-multistore.md/managing-stores.png) ### Business benefits - Empowers you to make changes faster. - Provides flexibility in managing stores. - Reduces complexity. ### Documentation - [Dynamic Multistore feature overview](/docs/pbc/all/dynamic-multistore/latest/base-shop/dynamic-multistore-feature-overview.html) - [Install Dynamic Multistore](/docs/pbc/all/dynamic-multistore/latest/base-shop/install-and-upgrade/install-features/install-dynamic-multistore.html) ## Product Comparison {% include badge.html type="feature" %} Product comparison enables customers to easily compare products on mobile and desktop devices. Customers can make more informed purchase decisions by viewing side-by-side comparisons of key product specifications and attributes. ![compare-products-page](https://spryker.s3.eu-central-1.amazonaws.com/docs/pbc/all/product-information-management/base-shop/feature-overviews/product-comparison-feature-overview.md/compare-products-page.png) ### Business benefits - Increases conversion rates and customer satisfaction - Reduces the likelihood of returns ### Documentation - [Product Comparison feature overview](/docs/pbc/all/product-information-management/latest/base-shop/feature-overviews/product-comparison-feature-overview.html) - [Install the Product Comparison feature](/docs/pbc/all/product-information-management/latest/base-shop/install-and-upgrade/install-features/install-the-product-comparison-feature.html) ## Dynamic Cart {% include badge.html type="feature" %} Dynamic cart improves user experience by providing instant, smooth, and uninterrupted feedback to cart changes. Based on AJAX, dynamic cart is updated without a reload for actions like adjusting item quantity, removing an item, or redeeming a discount code. Cart and shopping list widgets in the header also show changes without a page reload.

### Business benefits - Enhanced user experience: Making changes in cart without reloading the page allows for an uninterrupted shopping experience. This leads to higher satisfaction and smoother interactions, especially on mobile devices. - Increased cart conversion rates: Eliminating page reloads reduces friction in the shopping journey, resulting in higher conversion rates and ultimately driving revenue growth. ### Documentation [Dynamic cart overview](/docs/pbc/all/cart-and-checkout/latest/base-shop/feature-overviews/cart-feature-overview/dynamic-cart-overview.html) ## Discount condition: number of orders {% include badge.html type="improvement" %} Discounts can now be applied based on the total number of order a customer placed. Using the `customer-order-count` discount condition, you can define how many orders a customer should have placed to qualify for the discount. ![discount-condition](https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202410.0.md/discount-condition.png) ### Business benefits - Personalized promotions: Enable tailored discounts based on customers' order history, improving engagement with new and returning customers. - Boost customer acquisition: Offer specific discounts to first-time buyers, encouraging new customer sign-ups and conversions. - Strengthen customer retention: Reward repeat buyers with discounts, fostering loyalty and increasing the likelihood of future purchases. ### Documentation [Decision rules: Attributes and operators](/docs/pbc/all/discount-management/latest/base-shop/manage-in-the-back-office/create-discounts.html#decision-rules-attributes-and-operators) [Install the Promotions & Discounts + Order Management feature](/docs/pbc/all/discount-management/latest/base-shop/install-and-upgrade/install-features/install-the-promotions-and-discounts-order-managemet-feature.html) ## Category tree improvements {% include badge.html type="improvement" %} This update introduces the following UX improvements to the Category Tree in the Storefront: - Collapsible categories: Customers can now expand and collapse categories, making it easier to navigate product categories. - Hidden empty categories: Categories with no available products are automatically hidden, providing a cleaner and more focused shopping experience. ![category-tree](https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202410.0.md/category-tree.png) ### Business benefits Customers make faster buying decisions based on better navigation and more focused content delivery. ## Multi-value product attributes {% include badge.html type="improvement" %} This feature enables product attributes to have multiple values. For example, a "Charging" attribute could have the following values: - MagSafe - Qi2 - Qi ![back-office-multi-value-attribute](https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202410.0.md/back-office-multi-value-attribute.png) Such attributes are displayed with all of their values across the platform, including search, filtering, and product details pages. ![storefront-multi-value-attribute](https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202410.0.md/storefront-multi-value-product-attribute.png) ### Business benefits - Customers get a complete picture of products by all values being presented per attribute. - Enhanced product filtering: Customers can search and filter products based on multiple attribute values and combinations, enabling them to find products faster and with specific requirements. - Efficient data management: Back Office users can organize complex products more efficiently. ## Documentation [Create product attributes](/docs/pbc/all/product-information-management/latest/base-shop/manage-in-the-back-office/attributes/create-product-attributes.html) ## View Merchant page in the Back Office {% include badge.html type="improvement" %} Back Office users can now view all relevant merchant information at a glance without entering the edit mode. Merchant details are consolidated into one comprehensive page, streamlining the process of accessing and reviewing merchant data. ![view-merchant-page](https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202410.0.md/view-merchant-page.png) ### Business benefits - Simplifies data review processes by consolidating key merchant information in a single, non-editable page. - Eliminates accidental changes when viewing merchant information. ## Back Office accessibility improvements {% include badge.html type="improvement" %} Back Office is now more accessible to everyone, enabling all types of users to interact and navigate the system. We have implemented the following accessibility improvements: - Navigation: Users can navigate drawer content and content behind drawers using the **Tab** key. - Keyboard control: Users can interact with form elements and links using the keyboard. - Colors and contrast: Improved color contrast and added text as an alternative source of information besides color. ## Improved management of user roles in the Back Office {% include badge.html type="improvement" %} Back Office areas and actions are now predefined. When managing access of user roles, you can select areas and actions instead of manually entering them. ### Business benefits - Simplifies the management of user access. - Reduces the risk of errors when providing and restricting access. ## Publish and Synchronize configuration and optimization {% include badge.html type="improvement" %} Publish and Sync (P\&S) process has been improved as follows: - Performance optimization through direct sync: Synchronization queues can be enabled and disabled on the project level. When disabled, synchronization proceeds directly to the synchronize step without intermediate queuing, resulting in faster and more streamlined system performance. - Custom queue chunk size configuration: Developers can define custom message chunk sizes per queue. This allows for fine-tuned control over how many messages are processed per queue, like publishing, synchronization, or data import. The docs provide detailed guidance on when to increase or decrease chunk sizes for improved performance. - Improved event logger behavior: The event logger now consumes less resources. - System health check notifications for P\&S limits: Provides developers with notifications when processed data is reaching system limits. Notifications are sent in the following cases: - A worker exceeds 75% of its available memory. - Event message size surpasses 256KB: this protects the message broker. - The size of a request during entity publishing exceeds 1MB: this ensures compatibility with persistence capabilities. ### Business benefits - More fine-tuned control over the system. - Optimized performance through flexibility. - Processing time reduced. - Get more actionable insights into system behavior. - Prevent performance issues and system overload by proactively addressing potential bottlenecks. ### Documentation - [Publish and Synchronization](/docs/dg/dev/backend-development/data-manipulation/data-publishing/publish-and-synchronization.html) - [Queue](/docs/dg/dev/backend-development/data-manipulation/queue/queue.html) ## Tech update {% include badge.html type="improvement" %} The following components have been updated to ensure compatibility with the latest technologies and optimize performance: - PHP 8.3 is now supported; support for PHP 8.1 is discontinued. - Jenkins has been upgraded to the latest LTS version. All new cloud environments are now deployed with this version by default. For local development, the new version of Jenkins requires Docker SDK version 1.61.0 or higher. - Improved Jenkins' resource management by adding SWAP memory on the infrastructure level. This addresses memory-related issues causing job failures and instability. - The Angular framework has been updated to version 17, providing faster performance and smaller asset sizes for the merchant portal. - PHPStan has been upgraded to version 1.10, significantly improving code analysis speed. ### Business benefits - Reduced security risks - Reduced maintenance efforts - Scaling and more reliable operation ### Documentation - [Supported versions of PHP](/docs/dg/dev/supported-versions-of-php.html) - [PHPStan](/docs/dg/dev/sdks/sdk/development-tools/phpstan.html) - [Upgrade to Angular 17](/docs/dg/dev/upgrade-and-migrate/upgrade-to-angular-17.html) ## Stripe metadata {% include badge.html type="improvement" %} Spryker projects running the Stripe ACP app can now send custom metadata to Stripe. ### Documentation [Sending additional data to Stripe](/docs/pbc/all/payment-service-provider/latest/base-shop/third-party-integrations/stripe/project-guidelines-for-stripe/sending-additional-data-to-stripe) ## Developer guides {% include badge.html type="improvement" %} The following updated and new developer guides have been released: - Guides for [developing standalone modules](https://docs.spryker.com/docs/dg/dev/developing-standalone-modules/developing-standalone-modules.html) show how to create reusable packages and contribute to the community. - A guide on [AI coding assistants](https://docs.spryker.com/docs/dg/dev/ai-coding-assistants.html) offers insights into how engineers can improve and optimize their workflows with AI. - [Project development guidelines](https://docs.spryker.com/docs/dg/dev/guidelines/project-development-guidelines.html) have been refreshed, providing clarification on shortcuts and sharing tips and tricks for simplifying development processes. ## Community Contributions {% include badge.html type="improvement" %} This release introduces performance optimizations, bug fixes, and feature improvements contributed by the external community. These improvements address issues like memory consumption in product publishing, slow page searches, and various bug fixes. - Performance improvements: - Static cache for concrete product images in P\&S improves efficiency with multiple locales. - Reduced memory usage in abstract product publishing with many stores, locales, and concretes. - Removed redundant `getStoreAndLocaleKey` calls. - Less SQL queries are issued by preventing empty queries. - General improvements: - Added a flag to cache the OMS definition. - Improved the sorting behavior in the Merchant Portal - Bug fixes and other minor improvements Big thanks for your valuable contributions!

Post-Installation Configuration

Fri, 14 Aug 2026 05:50:58 +0000

This document provides guidance on advanced configuration and customization of your Spryker project after completing the initial setup. These steps help you optimize and adapt the Demo Shop to your specific project needs. ## Automate this configuration with the AI Dev SDK Most of the work on this page — services, stores, and import data — is covered by AI Dev SDK skills. Each skill reads what your project actually contains rather than applying a template, and reports what it plans to change before changing it. | Skill | What it does | Reference | |-------|--------------|-----------| | `configure-services` | Changes what infrastructure the project runs on, or builds a new environment deploy file. Makes surgical edits to the keys it owns, leaving neighboring deploy file blocks untouched | [README](https://github.com/spryker-sdk/ai-dev/blob/master/plugins/spryker-ai-dev-sdk/skills/configure-services/README.md) | | `define-stores` | Creates or redefines a project's stores and region. Clears the hardcoded store and locale literals that otherwise abort the boot | [README](https://github.com/spryker-sdk/ai-dev/blob/master/plugins/spryker-ai-dev-sdk/skills/define-stores/README.md) | | `project-data` | Populates, reshapes, reduces, cleans up, or removes the project's import data — one skill for every `data/import` change | [README](https://github.com/spryker-sdk/ai-dev/blob/master/plugins/spryker-ai-dev-sdk/skills/project-data/README.md) | | `spryker-import-tools` | Reads, filters, edits, and validates data import CSV files and manifests. Reliable where shell tools corrupt multi-line quoted fields, and catches boot-aborting data in seconds | [README](https://github.com/spryker-sdk/ai-dev/blob/master/plugins/spryker-ai-dev-sdk/skills/spryker-import-tools/README.md) | | `curate-golive-data` | Makes the data the project keeps production-safe before go-live — placeholder tax rates, Spryker CDN imagery, and demo accounts | [README](https://github.com/spryker-sdk/ai-dev/blob/master/plugins/spryker-ai-dev-sdk/skills/curate-golive-data/README.md) | If you are setting up a new project, the [Project Starter Wizard](/docs/dg/dev/ai/ai-dev/ai-dev-project-starter-wizard.html) runs these skills in order from a single interview. Run them individually when you are configuring a project that already exists. For the full list of skills and agents, see [Skills and Agents](/docs/dg/dev/ai/ai-dev/ai-dev-skills-and-agents.html). The rest of this document describes the same configuration manually. ## Manage modules A Spryker module is a single-function unit that has well-defined dependencies and can be updated independently. [Composer](/docs/dg/dev/set-up-spryker-locally/manage-dependencies-with-composer.html) is used for installing and managing module dependencies. To define your strategy when implementing updates, learn about our [module and feature release process](/docs/about/all/releases/product-and-code-releases.html). To learn about the module versioning approach in Spryker, see [Semantic Versioning: Major vs. Minor vs. Patch Release](/docs/dg/dev/architecture/module-api/semantic-versioning-major-vs.-minor-vs.-patch-release.html). ## Clean up modules 1. Go through the modules that came with the Demo Shop you've installed. 2. Come up with the list of modules you actually need. 3. Remove unnecessary modules by following module upgrade guides in a backwards fashion. ## Configure services 1. Define how to manage the settings in the configuration files with [Configuration management](/docs/dg/dev/backend-development/data-manipulation/configuration-management.html). 2. [Configure services](/docs/dg/dev/integrate-and-configure/configure-services.html). 3. [Configure Elasticsearch](/docs/pbc/all/search/{{site.version}}/base-shop/tutorials-and-howtos/configure-elasticsearch.html). 4. [Configure queue](/docs/dg/dev/backend-development/data-manipulation/queue/queue.html). 5. [Configure stores](/docs/dg/dev/internationalization-and-multi-store/set-up-multiple-stores.html#configure-stores). 6. [Set up cronjobs](/docs/dg/dev/backend-development/cronjobs/cronjobs.html). The `configure-services` skill applies steps 2 to 4 to your deploy file. ## Clean up store configuration The `define-stores` skill performs this cleanup, including the hardcoded store and locale literals that are easy to miss and that abort the boot when left behind. If you chose to start with one store, clean up the configuration of the unneeded stores in the following files: - `config/install/*` - `data/import/*` - `deploy.dev.yml` - `config_default.php` - `src/SprykerConfig/CodeBucketConfig.php` ## Clean up data import The `project-data` skill performs this cleanup, and `spryker-import-tools` edits and validates the CSV files themselves. - In `data/import`, remove the files of the unneeded stores. - Change the default config in `DataImportConfig::getDefaultYamlConfigPath()`. - Define the needed stores in `CodeBucketConfig::getCodeBuckets()`. ## Prepare for go-live Before go-live, replace the demo values the Demo Shop ships with — placeholder tax rates, Spryker CDN imagery, and demo customer accounts. The `curate-golive-data` skill finds and resolves them.

Development tools

Fri, 14 Aug 2026 05:50:58 +0000

Spryker provides a comprehensive suite of development tools that cover every aspect of the development lifecycle—from debugging and performance profiling to code quality assurance and AI-assisted development. These integrated tools ensure developers have everything needed to build, maintain, and scale high-quality e-commerce applications efficiently.

Why development tools are essential

Modern e-commerce development demands robust tooling to manage complexity, ensure code quality, and maintain high performance. Quality development tools provide:

Faster debugging: Identify and fix issues quickly with proper debugging and profiling tools
Code quality: Maintain high standards through automated static analysis and architectural validation
Performance optimization: Profile application performance and identify bottlenecks before they reach production
Developer productivity: Accelerate development with AI-assisted coding and automated quality checks
Upgradability: Ensure your project follows best practices, making upgrades smoother and less risky
Team consistency: Enforce coding standards and architectural patterns across the entire development team

Without proper development tools, projects accumulate technical debt, suffer from performance issues, and become increasingly difficult to maintain and upgrade.

Spryker’s complete development toolkit

Spryker provides an integrated ecosystem of development tools, eliminating the need to search for, evaluate, and configure third-party solutions. All tools are pre-configured to work seamlessly with Spryker’s architecture and development workflow.

Debugging tools

Xdebug integration

Spryker includes Xdebug support for interactive debugging and profiling:

Step-through debugging: Set breakpoints, inspect variables, and trace code execution
Performance profiling: Identify slow functions and performance bottlenecks

Documentation:

Performance profiling tools

WebProfiler

WebProfiler is available for all Spryker application layers:

Web Profiler Widget for Yves - Storefront profiling
Web Profiler for Backend Gateway - API Gateway profiling
Web Profiler for Zed - Back Office profiling

Code quality tools

Spryker provides a complete suite of code quality tools tailored to e-commerce development and Spryker’s architecture:

PHPStan - Static analysis

PHPStan performs type checking and code analysis to catch bugs before runtime:

Type safety validation
Dead code detection
Incorrect method calls identification
Configuration: Pre-configured for Spryker projects at level 6

PHPStan documentation

Code Sniffer - Code style enforcement

Ensures consistent code formatting and adherence to coding standards:

PSR-12 compliance
Spryker-specific coding standards
Automatic code style fixing capabilities
IDE integration for real-time feedback

Code Sniffer documentation

Architecture Sniffer project ruleset - Project-specific validation

Validates that the code follows Spryker’s project architectural patterns and conventions:

Layer separation enforcement
Project-specific architectural patterns
Custom business logic validation
Integration pattern compliance

Architecture Sniffer documentation

Evaluator - Upgradability and compatibility checks

Validates project compatibility with Spryker core and checks upgrade readiness:

Core module compatibility validation
Deprecated feature detection
Breaking change identification
Upgrade path recommendations

Evaluator tool documentation

AI-assisted development tools

Spryker embraces AI technology to accelerate development and improve code quality:

AI Dev Tool

Advanced AI development capabilities integrated into the development workflow:

Intelligent code suggestions
Architectural pattern guidance
Automated refactoring recommendations
Context-aware documentation

AI Dev Tool documentation

Integrated development workflow

All Spryker development tools work together seamlessly:

Write code with AI Assistant guidance
Debug issues using Xdebug integration
Profile performance with WebProfiler
Validate quality with Code Sniffer, PHPStan, and Architecture Sniffers
Check upgradability with Evaluator
Run in CI with automated validation pipelines

This integrated approach ensures consistent quality across the entire development process.

Best practices

To maximize the value of development tools:

Run tools locally: Catch issues before pushing to CI
Configure IDE integration: Get real-time feedback while coding
Use WebProfiler proactively: Profile performance during development, not just when issues arise
Review Evaluator output regularly: Stay informed about upgrade compatibility
Leverage AI tools: Speed up development with AI-assisted code generation
Enforce in CI: Make quality checks mandatory in pull request pipelines
Update regularly: Keep development tools up-to-date to benefit from new features and improvements

Spryker provides everything developers need to build, maintain, and scale world-class e-commerce applications—no additional tooling required.

Spryker Documentation

Upgrade Workflow

Availability

What the skill does

Why silent damage is the real problem

The phases

What the detectors find

Run the detectors in CI

Known limits

Requirements

Related

Project Starter Wizard

Availability

What the skill does

The interview

The nine steps

Run modes

Run artifacts

What you get at the end

Requirements

Related

Profiler Workflow

Availability

What the skill does

What it can tell you

One user action is many profiles

The workflow

Going deeper than counts

Things that will confuse you

When there is no data

Requirements

Related

Customization Workflow

Availability

What the skill does

Workflow at a glance

What you get at the end

Choose your output: PoC or production

Cypress end-to-end coverage

Where you decide

Requirements

Related

Bugfix Workflow

Availability

What the skill does

Two ways in — the ticket is optional

The stages

The verification loop

Modes

Pull request delivery

Run artifacts

Requirements

Related

Implement Publish and Synchronization

Release notes 202606.0

Release notes 202410.0

Post-Installation Configuration

Development tools

Why development tools are essential

Spryker’s complete development toolkit

Debugging tools

Performance profiling tools

Code quality tools

AI-assisted development tools

Integrated development workflow

Best practices