Frequently asked questions

PIM (Product Information Management) is a plugin for Shopware 6 that drastically speeds up product maintenance — with bulk-edit for 25+ fields, multilingual CSV import, variant generator, AI text generation with ChatGPT and Claude. All directly in the Shopware admin, no ETL tool or third-party system needed.

Shopware 6.5, 6.6 and 6.7 — all three versions are maintained in parallel. Every function is available identically in all three.

No. PIM runs entirely on your Shopware server. No telemetry, no data transfer to Stone & Water. External AI providers (ChatGPT/Claude/DeepL) are only contacted when you actively trigger them — with your own API keys.

Via Shopware Store: search "PIM for Shopware" under Extensions → Store, install, activate. Or manually: download ZIP and upload under My extensions.

PHP 8.2 or newer. Database: MySQL 8 or MariaDB 10.11. Memory: at least 256 MB, 512 MB recommended for large catalogues.

Over 25 fields: master data (name, description, meta data, EAN, manufacturer), prices and tier prices, purchase price gross/net separately, list price/RRP, Omnibus price, base price, product unit, stock and shipping, sales channel visibility, categories, properties, cross-selling, custom fields of all types.

In bulk-edit there are two separate actions: "Set purchase price gross" and "Set purchase price net". You only enter one of the two values — the other is automatically calculated via the product's tax class. Currency and linked status are preserved.

Before every bulk operation a snapshot of the previous values is saved automatically. One-click revert from the audit log rolls everything back. Snapshots are kept for 30 days.

All active filters from the selected preset are shown as readable chips: manufacturer, categories, tags, properties, stock range, price range, weight range, date ranges, visibility, tax class, delivery time, dynamic product groups, sales channel, EAN status, closeout, free shipping and SEO meta status. IDs are resolved to clear names (e.g. sales channel name instead of UUID). "No filters active" is marked with red border as warning.

Translatable bulk fields show a language dropdown as soon as a value is entered. Available for: meta title, meta description, SEO URL (SEO tab), translatable custom fields, and packaging unit (shipping tab). The value is set in the default language AND written to every selected language — one action, multiple languages simultaneously. Deliberately without language selection: product unit / unit of measure (only a reference) and language-independent fields (price, stock, EAN, weight, manufacturer, status, dimensions).

When you filter by a variant field and bulk-edit, you usually only want to touch the filter-matching variants. This toggle keeps the parent untouched — the bulk action follows the filter exactly.

Yes. In one run you can set manufacturer + change tax rate + sales channel visibility + product unit simultaneously — all in one go with a shared snapshot.

No hard maximum. Tested with 10,000 products in one operation. With live progress (counter, phase, ETA) you can always cancel mid-operation.

A dedicated bulk action that transfers fields from the parent to all variants: description, tier prices, cross-selling, images, SEO fields. Useful for values that don't differ between variants.

Three fields: SEO URL (generated, not reversible), tier prices → variants, cross-selling → variants. A warning is shown in the dialog for these.

Yes. One column per language — pattern name_de-DE, name_en-GB. Also custom fields per language (cf_myField_de-DE). On import, language columns are detected automatically and existing translations merged (JSON merge), not overwritten.

Two separate columns: purchasePrice_gross and purchasePrice_net. All combinations possible on import — only gross given (net is calculated via tax class), only net given (gross is calculated), both given (taken 1:1), or use the legacy column purchasePrice (backwards-compatible). The importer also automatically recognises German and English spellings: ek_brutto, einkaufspreis_netto, cost_gross/net.

As separate rows. Variant export is activatable per profile or globally. Parents and variants appear with clearly identifiable productNumber in the same file.

No. On import, parentId and mainVariantId can be resolved via SKU or EAN. UUIDs are not mandatory. Lookup cache prevents duplicate hits.

Instead of a cryptic UUID, the product unit is exported as a readable name ("Litre", "Kilogramm", "Piece"). On import, the name is automatically resolved to the correct Shopware unit ID — Excel-friendly.

No. Custom field JSON is merged, not overwritten. If only one column cf_xy is in your CSV, other custom field entries of the product are untouched.

Up to 10,000 are tested — in just a few minutes. Everything runs via the Shopware sync API in batches with progress bar and ETA.

Yes. During import you see live progress with counter, phase and ETA — and a cancel button. Already imported products stay; the rest is skipped.

The import tab is accessible only to super admins — in addition to the staw_pim.csv_import permission. Non-super-admins don't see the tab.

Practically unlimited. Tested with 100+ variants in under 10 seconds. For very many options, use the live preview to verify the exact count in advance.

A single search at the top of the variant generator filters properties and options simultaneously. Type "red" and all property groups with "red" as an option stay visible, with matches highlighted.

SKU and variant name patterns shown as separate accordions. Collapsed they show the current pattern as a chip; expanded an input plus clickable variable chips appear. Click a chip to insert directly.

It shows all variants of a product in a table: one axis the first property, the other the second. Price and stock per cell directly editable. Column configuration switchable, property sorting via drag-and-drop.

{number}, {parentName}, {option1}–{optionN}, {group1}–{groupN}, {counter}, {counter:03}.

In "Safe" mode (recommended) variants with open orders are not deleted, only deactivated. Data stays for accounting. In "Complete" mode all are deleted — careful.

Anthropic Claude (Haiku 4.5, Sonnet 4.6, Opus 4.6 / 4.7) and OpenAI ChatGPT (GPT-4o Mini, GPT-4o, GPT-4.1 Mini, GPT-4.1). Both usable in parallel, with provider selection per generation. Plus DeepL for pure translations.

Yes. Create keys at console.anthropic.com or platform.openai.com and enter them in PIM under Config Matrix → Translations. Keys are stored encrypted and used server-side only — they never leave the browser.

Description (HTML), meta title (max 60 chars), meta description (max 155 chars), keywords. Individually or together, for one product or via bulk-edit for many.

You, directly with the provider. Stone & Water charges no additional fees or margins.

Per call PIM shows estimated tokens and costs in €. Configurable bulk limits. Threshold confirmation dialog at €5 by default.

Yes. When both are active, the generator modal lets you pick the provider per call — Claude for demanding descriptions, ChatGPT for fast meta data.

Professional, Casual-modern, Premium/Luxury, Technical, Emotional. Default per shop in the config matrix, override per operation.

The central control of the plugin. Seven tabs: visible listing columns, editable bulk fields, active languages, variant default patterns, AI provider config, CSV export settings, visible Quickview fields.

The order of sections in the product detail view (master data, prices, media, SEO, …) and in the variant modal can be freely set via drag-and-drop. Sections without active fields are hidden automatically.

Both SEO generators support per-sales-channel patterns: step 1 its own token pattern, step 2 its own Twig pattern. Shop patterns are a list with pencil (edit) and trash (remove). Shops without their own pattern use the default pattern. Details in the FAQ section "SEO URL system".

Yes, both generators process parent and variants. Inherited fields are resolved from the parent product (incl. translated customFields with inheritance). The tokens {options}, {properties} and {tags} deliver language-translated values — patterns like {mainCategoryPath}/{name}-{options} produce unique URLs per variant.

Via drag & drop: in master data and the variant view, the images section has a drop zone (below the images). Drop files or click for the file dialog — uploads go to the Shopware media library (product folder) and are assigned immediately, with progress display. The first image automatically becomes the cover if none is set.

An image uploaded to a variant becomes the variant's own image and overrides the inherited one. Removing the own image restores inheritance from the main product — both stay possible at any time.

An approval status that editors can set themselves — signalling to the team that someone's currently working on the product. In parallel to approve/reject/submit. Visible as badge + button in the detail view, as filter and indigo indicator in the product list and in the approval statistics.

Assigned categories are shown as removable chips below the category tree (small × to remove) — visible at a glance, without searching the tree.

Feed Generator, CSV import/export and create product sit in their own row above the search — on all viewport sizes. The search field keeps its full width. The price column is sortable by clicking the header (server-side), and the manufacturer filter loads all manufacturers paginated (no more 500 cap).

When creating a new product, the first tax rate from the system is automatically preselected (sorted by position ASC). Gross/net calculations work immediately.

Save with empty required fields: a modal opens listing all errors. Clicking an error jumps to the section — it expands, the field is highlighted with an indigo outline.

A compact modal directly from the listing — shows master data, prices (gross/net incl. purchase price gross+net separately), stock, SEO and description for direct editing. The modal header shows the variant name large in front and the SKU behind it — same as the master variant view. All input fields uniform with 42 px height. "Expand all / collapse all" button in the header. Sections configurable, hidden without active fields.

Stock, price, EAN, manufacturer number, weight and active toggle directly in the row — also for variants. After save the value is verified; if Shopware discards it, a warning appears.

A feed delivers your product data under a unique, tokenised URL — automatically updated, no manual export. Typical recipients: Google Shopping, idealo, Billiger.de, ERP systems or analytics pipelines.

At the top of the Feeds tab there's the "Create feed from template / profile" selector. You either pick a built-in template (master data, prices & stock, SEO, images, variants, full export) or your own saved export profile. One click → profile is created, feed activated, token generated, URL immediately retrievable.

All feeds as a compact accordion list. Per row you see: name, status pill ("feed active" / "no feed"), feed URL preview, filter template chip, product count chip (live from the catalogue), pencil icon for editing and trash icon for deleting. Clicking the row reliably opens and closes the editor (chevron on the right rotates).

Yes. The expanded editor has a name field. The name must be unique — collisions with existing feeds or built-in profiles are rejected. The active profile, count chip and editor state automatically move to the new name.

Via the trash icon on the right of the row. A confirmation dialog appears. The delete button reacts separately from clicking the row — so you don't accidentally open the editor when deleting.

Yes. Feeds are decoupled from the source profile via an own storage key (exportFeeds). You can create any number of feeds for the same profile — e.g. a "Master data" profile as basis for multiple feeds with different filter templates per sales channel or target market.

In the feed editor you pick a saved filter template. The criteria that can be mapped reliably server-side are applied: active status, stock, manufacturer, category, sales channel. These are applied by the FeedExportService directly in the CSV/XML (incl. variant inheritance to the main article).

Quality/completeness criteria from the filter template (e.g. "missing images", "incomplete meta data", "no description", "SEO score < X") are deliberately not applied — these evaluations are calculated live in the listing and cannot be reliably mapped server-side in the feed context. If the feed silently applied them, your ERP would receive a distorted product set. With the clear separation, you know exactly: filter template defines which products, the feed delivers those products.

Each feed row has a product count chip. This value is determined live from the catalogue (via the filter template criteria) and updates when you pick a different filter template.

Existing feeds that were attached to the export profile are automatically migrated into the new list on first load. Existing feed URLs in your ERP, Google Shopping account or at price comparison portals remain valid — no re-configuration required.

XML, CSV, TSV and JSON. URL format: https://your-shop.com/staw-pim/feed/{token}.xml (and corresponding other extensions).

Feed URLs are tokenised and not publicly indexable (no entry in sitemap.xml, noindex header). Without the token, nothing is visible. The token can be regenerated by one click anytime — the old URL then becomes invalid.

Very — the feed is purpose-built for large catalogues. Four performance layers work together: (1) DBAL streaming in 2,000-batches (data is emitted row by row via PHP generator, no full memory load). (2) Keyset pagination on the product number instead of LIMIT/OFFSET (stays linearly fast, even on deep pages). (3) gzip compression with ~80–90 % reduction on text CSVs. (4) File mode with pre-generated file every 15 min. This way even catalogues with tens of thousands of products run through without memory issues.

Yes, automatically. If the client sends Accept-Encoding: gzip (all modern ERP/crawler/browser clients do), the response is server-side compressed via gzencode() and delivered with Content-Encoding: gzip + Vary: Accept-Encoding. Feed CSVs typically compress by 80–90 % — a 50 MB CSV is transferred as ~5–10 MB. The client decompresses transparently.

Live on request: Feed is generated directly from the database on every request. Always up-to-date, suitable for infrequent polling or smaller catalogues. File: A scheduled task pre-generates the file (every 15 min, atomically written), and the controller serves the ready file. No DB load, very fast response — ideal for ERPs that poll every few minutes. If the cron file doesn't exist yet, the controller automatically falls back to live generation.

Yes. The storefront feed route sets allow_maintenance, plus an early kernel subscriber answers feed requests before Shopware's storefront machinery kicks in. Google Merchant and ERP polling keep running during deployments and maintenance windows — instead of receiving a redirect page.

In addition to the storefront URL, there's the domain-independent route /api/staw-pim/export/<token>.csv (no login). Useful when the storefront URL redirects — e.g. with language-path domains or redirects. The alternative URL is shown in the feed settings.

Two steps with a custom field as bridge: step 1 "Generate URL in custom field" resolves a token pattern (e.g. {mainCategoryPath}/{name}) variant- and language-accurately and writes it to the per-shop field staw_pim_canonical_<shop>. Step 2 "Generate SEO URLs" sets a Twig pattern as Shopware's native SEO template per sales channel and reindexes through Shopware — the URLs come from the custom field and survive every reindex.

Directly written seo_url rows can be overwritten by Shopware's own indexer with the default URL on the next run. The two-step system sets the pattern as Shopware's own template — Shopware then generates the URLs itself from the custom field, fresh on every reindex. The URLs are permanently stable.

Typical Twig pattern: {% if staw_url_product_detail %}{{ staw_url_product_detail|raw }}{% else %}{{ product.customFields.staw_pim_canonical_shop|raw }}{% endif %} — migrated products keep their existing URL from the custom field, new products use the field filled by step 1. The migrated field is checked strictly in the current language, without translation inheritance.

Only if you want. The "Only generate missing SEO URLs" option leaves existing ones untouched. Changed paths remain as 301 redirects ("Keep old URLs as 301" option). For a complete rebuild there's "Remove all product URLs (reset)" — deletes all URLs of the selected channels/languages incl. Shopware's global detail URLs and rebuilds fresh.

In the modal, channels are grouped by shop — each channel card with its languages as an accordion below (initially collapsed, nothing preselected). Per group "select/deselect all" with counter, plus a global "select all" button. Per channel, badges show the product count (only products actually visible in the channel) and the missing-URL count.

Both. The preview picks sample products visible in the channel whose pattern resolves — up to three real example URLs. The dry-run runs the complete process without writing — with colour-coded result cards: new = green, change = blue, skipped = grey, warning = amber, error = red.

The number of products whose pattern outputs nothing — e.g. because neither the migration field nor the canonical field is filled. Makes it immediately clear why nothing was written for those products. Safety net: if the canonical field yields an empty result during final generation, the URL falls back to the product name instead of producing an empty path.

Paths already taken (also by other routes like a category with the same slug) are cleanly skipped and reported as "path already taken elsewhere" — no duplicate-key abort. Conflicts are shown with product numbers instead of internal IDs. Important: the same URL in different shops is not a conflict — uniqueness applies per shop + language. Fix: make the pattern more unique, e.g. {mainCategoryPath}/{name}-{options}.

The tokens {options}, {properties} and {tags} deliver the respective values translated per language. A pattern like {mainCategoryPath}/{name}-{options} produces a unique URL per variant and language. Variants resolve their per-channel canonical field incl. inheritance from the parent.

Fallback chain: requested language → parent language → system. Empty or inherited translations are skipped. Applies to token and Twig generation — an English URL no longer gets a German product name just because the English translation was empty.

Umlauts and special characters are converted (ä→ae, ß→ss, "&"/spaces → separator) — also in static pattern text like a literal "für/". Slashes and dots are preserved — category paths with "/" and .html suffixes pass through unchanged. Shopware's SEO escaper would normally slugify slashes to "-" — path fields therefore automatically get |raw injected. Preview and server generation behave identically.

No, the editor explicitly warns against it — Shopware slugifies the Twig output and strips the token braces in the process. Recommendation: either a pure Twig pattern or a pure token pattern. The editor has a live Twig syntax check: invalid Twig is flagged in red and save is blocked.

Yes, for both generators: step 1 can get its own token pattern per sales channel, step 2 its own Twig pattern. Shop patterns are a list — edit via pencil, remove via trash, "Add pattern for shop" opens the editor modal. Shops without their own pattern use the default pattern.

{mainCategoryPath} uses the main category of the respective sales channel. If none is set, the fallback deterministically prefers the deepest assigned category (longest path) instead of an arbitrary one. With an empty category.path column (indexer backlog after imports), the ancestor chain is reconstructed via parent_id.

Yes. Channel counts run via set-based aggregate queries, product lists via index-friendly UNIONs instead of OR self-joins — the dialogs open without delay, generation progresses normally even with tens of thousands of products (chunked, no timeout). Progress bar with percentage.

Yes. Browser-native virtualisation via content-visibility: auto ensures smooth scrolling. Server-side filtering, lazy-loading of variants, bulk operations in batches with progress.

Three levers: (1) product writes use Shopware's async queue indexing instead of synchronous in-request indexing, (2) the write batch size was raised from 10 to 25, (3) approval and audit-log requests are batched (one batch every 600 ms or one request per 200 products instead of one per product). Configurable via bulkIndexingBehavior (queue / disable / sync).

No. Imports use queue indexing by default — only the imported products are reindexed asynchronously. The previous full-catalogue reindex after every import is gone (only runs with importIndexingMode = 'disable').

The plugin keeps a session error log: the last 50 errors are in window._stawPimErrLog (browser console). Previously silent error paths — audit flush, batch approvals, snapshot loading — now log failures. Ideal for hosting without log access.

No. The plugin runs entirely on your Shopware server. No telemetry. Audit log and snapshots are stored in your Shopware database.

Seven granular ACL permissions: viewer, editor, csv_export, csv_import, variant_generator, ai_textgen, config. Plus additional super-admin restriction for the import tab.

Stored encrypted in the database, used server-side only. They never leave the browser. Connection test verifies server-side against the provider.

Under PIM → Audit Log. Every bulk operation, every CSV import, every snapshot action with user, timestamp and before/after values.

Standard license via the Shopware Store. Updates also delivered via the Store automatically.

Updates within the same major version are free. Stone & Water continuously extends the plugin with features that emerge from real maintenance workflows.

Usually 1–2 business days. For critical bugs there's a hotfix outside the regular release cycle.

Yes, please do. Via the feature request form. Most concrete wishes land in the plugin within a few weeks.

Email to pim@stoneandwater.online or via the contact form. We happily extend the documentation for questions about the docs.