A CLI tool for managing plugins in the Shopware Community Store.
npm install -g scs-commander
Clone this repository and install it using
npm install && npm link.
You can set your Shopware Community Store username and password in an environment configuration in your user's home directory (
~/.scs-commander). This file is optional, so you can still pass the username via
-u to each command and enter your password when asked. Also, even if
~/.scs-commander exists and contains a username, you can overwrite it by passing the '-u' argument to the command.
Additionally you can set an optional HTTP webhook endpoint in the configuration file as well. This will call the endpoint upon a successful release. The URL supports basic auth and might look like this:
.scs-commander.dist for further info.
scs-commander list -u <your_username>
You can sort the results by passing option
-s <sort_field>. The available sort fields are
shopwareCompatibility. By default only active plugins are listed. If you wish to list all plugins of the account pass
scs-commander description -u <your_username> -p <technical_plugin_name> -l <locale> [--backup] [--patch] <path_to_description_file>
By default this command reads the file from the provided path and uses its content to update the plugin description in the community store. If you wish to review the resulting changes first and manually confirm them, pass
--patch. You can also pass
--backup to back up the current description in the local file system.
Remark: You can only upload plugin
.zip files, which contain a valid
plugin.json file next to the plugin
Bootstrap.php (see shopwareLabs/plugin-info for more info).
scs-commander upload -u <your_username> <path_to_plugin_zip_file>
By default, this command automatically requests a review of the uploaded plugin version, which causes the binary to be released automatically. If you only want to upload the binary, pass the
If set, the HTTP endpoint will get called after a successful release.
Note: Releasing a plugin binary makes only sense when providing a changelog for all available languages, since Shopware requires a changelog of at least 20 characters per supported language. The changelog is parsed either directly from a
CHANGELOG.md file that must be contained in the
.zip file. The benefit of using a separate
CHANGELOG.md file is readability, which is why defining a changelog in the
plugin.json file is not supported. Currently the changelog parser supports only a simple structure:
## <version_0> ### <language_A, e.g. 'de'> The changelog content of 'version_0' in 'language_A'. Can contain any markdown except for '##' and '###' headlines. ### <language_B, e.g. 'en'> The changelog content of 'version_0' in 'language_B'. ## <version_1> ### <language_A, e.g. 'de'> The changelog content of 'version_1' in 'language_A'. [...]
Any whitespace/newlines leading or trailing a changelog for a version/language is trimmed and the remaining content is compiled to HTML, which is used as the changelog in the store. This makes it easy to add lists, links and simple formatting (bold, italic etc.) to your plugin changelogs in the community store (and it looks nice in your GitHub repositories too). The order of versions or languages within a version is arbitrary.
scs-commander changelog -l <language, e.g. "en"> <path_to_plugin_zip_file>
You can also get complied HTML (which is the same as used by the
upload command) by setting
--html. If no
language is provided, the english changelog is returned.
scs-commander compatibility -u <your_username> -p <technical_plugin_name> --min-version <shopware_version_string>
scs-commander dump-plugin -u <your_username> -p <technical_plugin_name> [-f <FORMAT>]
Currently the only supported output format is