What shop owners needto know aboutShopware plugin development

Basics

What does Shopware plugin development actually involve?

Shopware plugin development involves writing an extension that runs in the same process as the Shopware core and has the same capabilities as the core itself. It can react to events, store its own data, change the database structure and extend both the Administration and the Storefront. That closeness to the core is what makes a plugin powerful, and it is also why a plugin needs maintenance whenever Shopware makes a major version jump.

You do not have to read PHP to steer a plugin project well. It does help to know the building blocks a plugin is made of, because they let you place a quote in context. A plugin that only adjusts one Storefront template is a very different job from one that touches the checkout, creates its own tables and ships its own screen in the Administration.

Whether you have something built at all or rent a ready-made extension is a separate question, covered in detail in our guide Shopware plugin: buy or build. Here we focus on the how, meaning what happens once you have decided on a custom build.

Architecture

Plugin or Shopware app: which route fits your shop?

Plugin or Shopware app is usually settled by where your shop runs, because Shopware says plugins are not supported on Shopware Cloud as SaaS. There, the app is the only option. In a self-hosted shop, you can choose.

An app lives in the folder custom/apps and describes itself in a file called manifest.xml, which Shopware calls the contract between shop and app. If the app needs its own logic on a server, that server registers with the shop, receives events by webhook and works with the data through the Admin API. An app cannot change the shop's database structure.

For your planning, this means: if the extension mainly exchanges data with another system, an app is often the longer-lived route, because it depends less on Shopware's internals. If it reaches deep into price calculation, checkout or the data model, you will usually end up with a plugin, provided your hosting allows it.

Structure

How do you create a Shopware plugin for Shopware 6?

To create a Shopware plugin, developers usually start with the command bin/console plugin:create, which sets up the skeleton with all required files. bin/console plugin:refresh then registers the plugin with the shop, and plugin:install --activate installs and activates it. What follows is spread across a handful of building blocks that come up in almost every project:

1. Base class and composer.json01Every plugin has a main class that extends Shopware's plugin class, plus a composer.json with metadata such as the technical name, description and author. This file also states which Shopware versions the plugin requires.
2. Services02The actual logic lives in services that Shopware provides through Symfony's dependency injection. They are registered in the plugin's service configuration.
3. Events and subscribers03A subscriber is a class that declares which events it listens to, for example products having been loaded. Without an entry in the service configuration, Shopware never calls it.
4. Lifecycle04Installation, activation, update, deactivation and uninstallation each have their own method. Well-built plugins deactivate their own data when switched off instead of deleting it, and ask on uninstall whether that data should be kept.
5. Storefront05Templates are written in Twig. A plugin extends one of the shop's templates with sw_extends and overrides individual blocks, rather than copying the whole file.
6. Administration06The Administration is built on Vue. A plugin brings its modules and changes in through an entry file called main.js, which is built before delivery.

Tooling

What does the Shopware CLI do in Shopware plugin development?

The Shopware CLI is a standalone command line tool from Shopware that builds extensions, validates them, packages them as an archive and, if you want, uploads them to the Shopware Store. It is installed separately from the shop, which also makes it a good fit for automated runs in a CI/CD pipeline. When building, it reads from composer.json which Shopware version the plugin targets.

For local development, Shopware recommends Docker. The benefit is easy to see: everyone on the team works under the same conditions, services such as cache, queues and search behave as they do in production, and a broken environment can be rebuilt quickly. The Shopware CLI can create and start such a Docker environment itself.

For you as the client, this is more than a matter of taste. A team that builds and validates reproducibly can hand you exactly the same version again at any time, and the bug that never shows up on the developer's machine but does at the host becomes rarer.

Interfaces

When is the Shopware Admin API enough instead of a plugin?

The Shopware Admin API is often enough when another system needs to read or write data in the shop and no rule has to fire inside the shop's own processes. Shopware describes it as the interface for integrations, automation, data synchronisation and imports and exports, with read and write access to every entity. For large numbers of records at once, there is a dedicated sync endpoint.

A typical case is connecting an ERP, PIM or shipping system: stock, prices and order status travel through the interface, and no extra code is left behind in the shop that has to be maintained with every update. How such a connection is planned is covered in our article on Shopware ERP integration.

The limit is reached where something has to happen inside the shop on every order or page view, such as a custom price rule in the cart. No interface can do that from outside. That needs a plugin or an app.

Quality

How can you tell good Shopware plugin development?

You can tell good Shopware plugin development by tests, static analysis and a clear version statement being part of the delivery, not something you only get when you ask. Shopware provides the groundwork: plugins can be tested with PHPUnit, including integration tests against a database, and the full check in the Shopware CLI bundles tools such as PHPStan, ESLint and Stylelint.

Compatibility deserves particular attention. With Shopware 6.7, the Administration build moved from Webpack to Vite, the compatibility layer for Vue 2 was removed and the framework moved up to Symfony 7. Plugins with Administration components therefore needed separate versions for 6.6 and 6.7. So ask which versions a plugin is built and tested for, and plan the next major update in from the start; what matters there is explained in our Shopware update guide. According to the vendor, Shopware 6.8 is planned for 2027 (as of October 2026).

If you want your plugin in the Shopware Store, it also has to pass a review, first automated with PHPStan and SonarQube and then by hand. For a plugin that only runs in your own shop this is not required, but the standards still work well as a benchmark.

Process

How does it work when you commission Shopware plugin development?

When you commission Shopware plugin development, the work starts with a description of the process and only then moves to code. Who clicks what, in which order, with which data, what happens when something goes wrong, and what should be different at the end? The more precise these sentences are, the more reliable the estimate.

From that comes a concept that sets out whether it will be a plugin or an app, which building blocks are needed and which Shopware versions it targets. Then come the build, tests on the agreed versions, acceptance in a test environment and only after that the rollout to the live shop. Maintenance begins from there, and it comes round again with every major Shopware update.

With Shopware development at Scalableloops, this runs in three steps: a free initial call, a concept with a quote, and the build with testing on Shopware 6.6 and 6.7. Development, maintenance and support stay with us, and the people you talk to are the developers themselves. Our own extensions show what a result can look like, for example the Google Ads integration for Shopware, which reports conversions through both browser and server.

Preparation

How to prepare for Shopware plugin development

1. 01Write down the processCapture in a few sentences who does what, with which data, which exceptions exist and what should be different afterwards.
2. 02Clarify hosting and versionNote whether your shop is self-hosted or runs on Shopware Cloud, and which Shopware version is live. That decides between plugin and app.
3. 03Put quality into the quoteAsk about tests, static analysis, supported versions and handover of the code before you commission anything. For a first conversation, you can request a free consultation.