Common Store Review Errors

These errors apply to all extensions submitted to the Shopware Store (plugins and apps).

Composer and bootstrap issues

Missing or invalid composer.json

Typical causes:

• composer.json missing.
• Technical name mismatch between Store and composer.json.
• Wrong extra.shopware-plugin-class.
• The extension archive has an incorrect ZIP structure.

Check:

• The Store technical name, plugin base class, archive root and Composer metadata identify the same extension. The Composer package name uses the vendor/package format; it is not the plugin technical name.
• extra.shopware-plugin-class points to the correct bootstrap class.
• Namespace matches exactly (case-sensitive).
• Archive contains correct root folder structure.

For example, if extra.shopware-plugin-class is Acme\Example\AcmeExample, the declared class, namespace and autoload mapping must resolve that exact name. Changing the class name without updating the metadata breaks discovery.

Extension Meta Information – Explanation of the properties

Missing bootstrap class

Common causes include:

• Wrong ZIP structure.
• A typo.
• Case-sensitive filename mismatch.
• Namespace mismatch.

composer.lock Problems

Rules:

• composer.lock must NOT be included in the archive.
• Lock file must match composer.json before packaging.
• Run composer update if lock is outdated.

Dependency and version errors

Missing Shopware packages

Declare the Shopware packages your plugin actually uses. For example, a plugin using Storefront classes needs shopware/storefront as well as shopware/core. Do not add a Storefront dependency to an extension that does not use it.

This example declares support for the 6.7 release line:

{
  "require": {
    "shopware/core": "~6.7.0",
    "shopware/storefront": "~6.7.0"
  }
}

Adapt the range to the versions you have tested; this example is not a fixed Store version requirement. ~6.7.0 allows patches within 6.7, while ^6.7 also admits later 6.x minor versions. An exact constraint such as 6.7.0.0 excludes subsequent patches. Avoid unbounded constraints that advertise compatibility with versions you have not verified. See Composer version constraints.

Classes or APIs unavailable on a supported version

A class, service, method, Twig block or Administration component available in a recent patch may be absent from an earlier version allowed by your constraints. Test both the oldest declared version and the newest supported stable version, including relevant intermediate API changes. Either implement and test a compatible fallback or raise the minimum version to the first release that supports the feature.

Do not lower minimum-stability to fix a missing dependency or incorrect compatibility range. If you intentionally test a prerelease, keep that separate from the compatibility you advertise for a stable release.

Code & Static Analysis Errors

Forbidden Statements

Blocked:

• die
• exit
• var_dump

Invalid method usage

You might see Call to static method *jsonEncode() on an unknown class*. Shopware always uses json_encode() exclusively; there is no fallback.

Remove dead code

Remove out-commented code from your source code. Ensure there are no unused classes or files.

Cross-Domain Messaging

Ensure that cross-document messages are sent to the intended domain. Unrestricted messaging will be rejected.

Link: OWASP Web Security Testing Guide

Cookie and security issues

Cookies must be set securely, and non-essential cookies must integrate with the Cookie Consent Manager. Registration alone does not prevent tracking before consent; see Consent behavior. For permissions, ownership, input validation and credentials, see Security and permissions.

Packaging errors and unauthorized files and folders

Inspect the ZIP you will submit, not only the source checkout. Remove development-only files, temporary artifacts and unused resources from that release archive. Keep your tests and development tooling in your source repository.

Retain files needed to run or review the extension, including readable JavaScript sources and dependency manifests needed to rebuild them. For example, a package.json declaring an imported JavaScript library has a different purpose from an unused development manifest. Keep required production build manifests and the checksum.json generated by release tooling; distinguish them from development caches. Usage documentation and changelogs are not unused artifacts merely because they are Markdown files.

The following are common development or temporary artifacts to remove when present in the release archive:

• ./tests
• .DS_Store
• .editorconfig
• .eslintrc.js
• .git
• .github
• .gitignore
• .gitkeep
• .gitlab-ci.yml
• .gitpod.Dockerfile
• .gitpod.yml
• .phar
• .php-cs-fixer.cache
• .php-cs-fixer.dist.php
• .php_cs.cache
• .php_cs.dist
• .prettierrc
• .stylelintrc
• .stylelintrc.js
• .sw-zip-blacklist
• .tar
• .tar.gz
• .travis.yml
• .zip
• .zipignore
• ISSUE_TEMPLATE.md
• Makefile
• Thumbs.db
• __MACOSX
• auth.json
• bitbucket-pipelines.yml
• build.sh
• composer.lock
• eslint.config.js
• grumphp.yml
• package-lock.json
• phpdoc.dist.xml
• phpstan-baseline.neon
• phpstan.neon
• phpstan.neon.dist
• phpunit.sh
• phpunit.xml.dist
• phpunitx.xml
• psalm.xml
• rector.php
• shell.nix
• stylelint.config.js
• webpack.config.js

After rebuilding, verify that the shipped Administration and Storefront bundles reflect the source changes and that obsolete chunks are removed. A source fix does not resolve a problem still present in the compiled assets.