Shopware help
Unknown JavaScript in the checkout, a 500 error when customers place an order, a blank administration after an update, or a shop that gets slower week by week: that is what brings people here. Sharpness Solutions in Oldenburg helps operators of self-hosted Shopware 6 shops in a fixed order — secure first, then understand, then repair — even if we did not build the shop. Reachable Monday to Thursday, 9:00 to 16:00, and Friday, 9:00 to 13:00 CET, on +49 441 21 21 63 0, and outside business hours through the form below. Emergencies come before every other request.
Anyone searching for Shopware help does not want an agency profile. They have a symptom. The six cases below cover most of what operators call Sharpness in Oldenburg about, and they fall into three groups: the shop has been compromised, the shop is broken, or it runs, but badly. Usually we hear that everything still worked yesterday. The trigger had almost always been there for some time.
Customers report misused cards or accounts, the payment page suddenly looks different, the page source loads a script from a domain nobody recognises. That is the pattern of a skimmer reading along with what is typed into the checkout. Delete nothing now: secure first, then analyse — and inform your payment provider.
A user nobody created, an integration with admin access nobody knows about, visitors landing on other people's sites, Google listing pages with content your shop never had. Each of these is reason enough to treat the shop as compromised until the opposite has been established.
The shop loads, but the order fails. First place to look: var/log/ in the Shopware directory. Then bin/console cache:clear, then deactivate the plugins one at a time. If the error survives that, it sits in the code — usually in an extension somewhere in the order process.
Shopware 6.7 moved the build system from Webpack to Vite, replaced Vuex with Pinia and removed the Cached*Route classes. Extensions built on any of that break silently. We check your plugin list against 6.7 before you update.
Before Redis enters the conversation, we check three things: is the instance still running in development mode? Is the HTTP cache switched on? How many plugins sit in the request path? Development mode is the most common finding.
You have a shop, but no access credentials, no documentation and nobody to ask. That is unpleasant and still solvable. What you are contractually entitled to is a question for a lawyer, not for your new agency. The technical review runs without the old agency taking part.
When a Shopware shop has been hacked, securing it comes first, not cleaning it up: put the shop into maintenance mode or take it offline at the host, copy the files and the database, secure the server and access logs, lock the administrative accounts. Only then does the analysis begin. The obvious impulse — delete the suspicious files, change the admin password and carry on selling — destroys evidence and does not close the door. The back door is almost never where the first suspicious file is.
In a Shopware 6 shop we look where attackers settle in: additional users under Settings → System → Users, unknown integrations with Admin API access under Settings → System → Integrations, modified Twig templates and JavaScript files in the theme and in the extensions under custom/plugins and custom/apps, injected HTML in Shopping Experiences and snippets, unknown files under public/ and scheduled tasks on the server. We compare core and extensions with the original sources from Composer and the Store. That shows what was added or changed, and the access logs show when and by which route.
A skimmer in the checkout is the most serious case, because it harvests data while the shop goes on selling as normal. It usually sits as a script loaded from a template or an extension and reads what customers type into forms. If your checkout redirects to the payment provider, the risk to card data falls — the risk to addresses, customer accounts and orders does not. Inform your payment provider as soon as payment pages may have been tampered with. If personal data was accessible, Article 33 GDPR requires notification of the competent supervisory authority within 72 hours. We provide the technical facts for that; whether a notification is made is for you to decide with your data protection officer.
The cleanest way back is a backup from before the break-in, brought up to date with every security update released since. Orders and customer accounts created after the backup are reconciled and carried over once checked. If there is no reliable backup, we rebuild Shopware and the extensions from the original sources and take over from the infected installation only what can be checked: database content, media and your own plugins after a code review.
After that every set of credentials is changed, without exception: administrators, integrations and API keys, database, SFTP and SSH, payment and shipping services, mail delivery. A key the attacker knows makes the best restoration worthless. Then the cause is closed — usually a Shopware version without security updates or an outdated extension — and the shop is hardened: a second factor in front of the administration, administration only from known networks and, if you wish, a firewall in front with Cloudflare whose rules do not lock out payment providers and the ERP.
Shopware publishes security advisories for its versions, and the patch against an exploited vulnerability is almost always available by the time the break-in happens. The uncomfortable lesson from such cases: security updates at fixed intervals would usually have prevented the incident, at a fraction of what analysis and rebuilding cost. We do not promise one hundred per cent security. What we establish is a state in which mass attacks come to nothing and an incident stays an incident.
A 500 error (HTTP 500, “Internal Server Error”) in the checkout of a Shopware 6 shop almost always has one of three causes: cache, indexing or a plugin. The order to work through yourself: 1. Read the log files under var/log/. 2. bin/console cache:clear, cache:clear:http and cache:warmup. 3. bin/console dal:refresh:index if new products do not appear. 4. bin/console plugin:deactivate, then cache:clear again. Messages such as “Unable to generate a URL for the named route” point to the cache or to routing. An error from the search index — Elasticsearch or OpenSearch — when a category is opened points to the index, and bin/console es:index is the answer. “Class not found” or a blank page points to a plugin. If you have been through all of that and are still in the dark, you need someone with shell access.
After an update, the most common defect is an extension that no longer fits the new version. Shopware 6.7 was an infrastructure release with hard breaking changes: the administration build system moved from Webpack to Vite, state management from Vuex to Pinia, the Cached*Route classes were dropped, and header and footer load via ESI. Extensions and custom templates built on any of that break silently — the administration stays blank, the checkout throws errors. We check the plugin and template state against the target version before an update goes into production, and we run updates from the command line rather than through the graphical updater.
When something breaks, we work backwards from the last state that worked: what was deployed last, which plugin was installed, what the Composer state looks like. We reproduce the fault on a staging system, not in the live shop. Nothing gets fixed until the cause has a name. A rollback is a decision, not a panic reaction. Anyone who runs updates only through the graphical interface and has no staging system also has no way back. That is the gap we close first, because it makes the next emergency cheaper than this one.
A slow Shopware shop usually has a chain of causes rather than a single culprit, and the chain can be worked through in a fixed order. First: is the instance still running in development mode? Then Shopware writes debug logs on every request and recompiles templates. Switching to production mode alone usually produces the single largest gain; how large, we say after the measurement, not before it. Second: is the HTTP cache actually switched on via SHOPWARE_HTTP_CACHE_ENABLED=1? Third: how many plugins sit in the request path, and what are they doing there? Only after that is it worth talking about Redis, Valkey or OpenSearch.
If the ERP reports different stock levels than the shop, Shopware itself is almost never the cause. Since Shopware 6.6 stock is a real-time value: product.stock is written forward by the order events, and the former “available stock” is now only a read-only mirror of the same field. Differences are therefore almost always a synchronisation or reservation problem: which system writes last, are reservations counted twice, does the import break off halfway? We resolve that at the interface, not in the index.
If the shop still runs on Shopware 5, that is not an acute defect, but it is an open risk: Shopware 5 has been out of the manufacturer's maintenance since the end of July 2024, and every new vulnerability stays open unless you buy patches through safefive — the paid third-party service that took the maintenance over. safefive postpones the migration date. It does not replace it. A migration to Shopware 6 is not an update but a rebuild with a data transfer. How we build shops is described on a page of its own.
We take over existing Shopware shops, but not blind. It starts with a review: Shopware version and patch level, the Composer and plugin list with the origin of each entry, the amount of custom code, the state of the hosting, the deployment routes that exist, the backups and whether they can actually be restored. Out of that comes a findings report with a risk list and an estimate — a self-contained first deliverable, not a sales conversation. Only then do we say what we can take on. A commitment made before looking at the code would be guesswork, and guessing about somebody else's code is not a method.
After the findings report there are two ways of working with us. Either you commission individual pieces of work — one fault, one update, one clean-up — and we bill by time and materials. Or we agree a maintenance contract with an SLA that sets out response times, availability and scope in writing. The difference from the manufacturer's support: Shopware supports its own product, not your third-party plugins and not your custom code. That is exactly where the faults and vulnerabilities that reach us most often sit. We have been developing in Oldenburg under the Sharpness name since 1999; the contracting party is Sharpness Solutions GmbH.
Process
+49 441 21 21 63 0, Monday to Thursday, 9:00 to 16:00, and Friday, 9:00 to 13:00 CET, and outside those hours through the form. You describe the symptom, we tell you what not to do right now and what we see. What the repair costs is in the findings report afterwards. We work remotely across Germany; meetings in the north-west by arrangement.
You describe the symptom: what do you see, since when, what was changed last? If a break-in is suspected, we tell you straight away what you should not do yourself. We are reachable Monday to Thursday, 9:00 to 16:00, and Friday, 9:00 to 13:00 CET; emergencies come before every other request.
Maintenance mode, a copy of files and database, logs secured. For that we need shell or SFTP access, the database, Git and the administration. Nothing is deleted before it has been secured. If there is no staging system, we set one up first.
Logs, Composer state, plugin list and file comparison instead of assumptions. You get in writing what is broken, why, and what the repair costs — after a break-in also the route in, the point in time and the extent.
The work happens on a staging system, not in live operation. We run updates from the command line rather than through the graphical updater, we avoid x.x.x.0 releases and wait for a patch level that holds.
After going live we measure the same values as before: response times, error rate in the log, indexing time. Without a before value, every improvement is a claim. You get the result as a comparison, not as an adjective.
Cause closed, credentials changed, a firewall in front if you wish. After that a maintenance contract with an SLA, monitoring and scheduled updates — on a codebase we now know. A shop nobody looks after is the next emergency.
Projects on this system
A selection — not the full client list.
Across the north-west
We work for companies from Wuppertal and Münster via the Emsland and East Frisia to Hamburg and Hanover. Meetings on site by arrangement, the ongoing work remotely. Each region has a page of its own.
There is no public support hotline for technical faults at Shopware: existing customers on a paid plan go through account.shopware.com, and operators of the Community Edition are explicitly referred to the community forum. According to Shopware's price overview, the paid plans start at Rise from 600 euros per month and Evolve from 2,400 euros per month, each plus VAT. Technical help for a self-hosted shop therefore usually comes from service providers. We are one of them, in Oldenburg, Monday to Thursday, 9:00 to 16:00, and Friday, 9:00 to 13:00 CET, on +49 441 21 21 63 0.
Three things: put the shop into maintenance mode or have the host switch it off temporarily, so that no more customer data leaks out; delete nothing and do not “clean up”; and, from a different, clean device, change the passwords for your email account and your hosting customer account. Then call us, Monday to Thursday, 9:00 to 16:00, and Friday, 9:00 to 13:00 CET, on +49 441 21 21 63 0, and outside those hours use the form. Securing, analysis and restoration then follow in a fixed order.
Typical signs are users or integrations in the administration that nobody created, scripts from unknown domains in the page source — especially in the checkout —, redirects to other sites, spam pages under your domain in Google, a warning in Google Search Console, an abuse report from your host or spam sent through your mail delivery. An inconspicuous shop is no proof, though: skimmers are built not to be noticed. If there is a concrete suspicion, we check files, database and logs against the original sources.
Yes, although to a lesser extent. If the checkout redirects to the payment provider's page, customers do not type their card details into your shop. A skimmer can, however, show a fake payment form beforehand, and addresses, email addresses and customer passwords pass through your pages in any case. That is why we treat every unknown script in the checkout as an incident, whatever the payment method, and advise involving the payment provider early.
If personal data was or may have been affected — customer accounts, addresses, orders —, Article 33 GDPR requires notification of the competent supervisory authority within 72 hours; where the risk is high, Article 34 also requires informing the people affected. We provide the technical facts for that: point in time, route in, data affected. Whether and what is reported is for you to decide with your data protection officer. We do not give legal advice.
Emergencies such as a hacked or stalled shop come before every other request, but we do not commit to binding response times without a maintenance contract. Within business hours, Monday to Thursday, 9:00 to 16:00, and Friday, 9:00 to 13:00 CET, we take your report by phone or through the form and tell you when we can deal with it. Outside those hours nobody here answers the phone. If you need someone in the evening, at the weekend or on a public holiday, you need an on-call arrangement. Fixed deadlines, availability and scope are set out in a maintenance contract with a service level agreement — which also costs money in the months when nothing happens.
We bill individual jobs and emergency help by time and materials, while ongoing support runs through a maintenance contract with a monthly fee and a service level agreement. We name figures once we have seen the shop. The findings report with a risk list and an estimate is a self-contained first deliverable at a fixed price, which we state in writing beforehand. How much work a clean-up takes depends above all on whether a clean backup exists and how long the attacker was able to work unnoticed. The current hourly rate and the price of the findings report are available on request.
We work with Shopware Cloud (SaaS) too, but within narrower limits: the work described on this page assumes a self-hosted Shopware 6 shop, either Community Edition or Commercial on-premise — logs under var/log/, bin/console, your own staging, your own servers. Shopware Cloud has neither a shell nor bin/console. There we handle configuration, app development to the Shopware standard and interfaces through the Admin API and Store API; anything touching servers, cache and database is reserved for the manufacturer. Which of the two you run is something we establish in the first phone call.
Shopware 6.7 was an infrastructure release with hard breaking changes, which is why extensions and custom templates are what break. The administration build system moved from Webpack to Vite, state management from Vuex to Pinia, Store API route caching and all Cached*Route classes were dropped, the payment handlers were consolidated into a single AbstractPaymentHandler class, and header and footer load via ESI. Custom field names may no longer contain hyphens or full stops. On top of that came accessibility rework in the storefront, which can take custom templates apart. We check the plugin and template state against 6.7 before an update goes into production.
A slow Shopware 6 shop almost always has one of five causes, in order of frequency: the instance is still running in development mode, the HTTP cache is not switched on, there is no object cache in Redis or Valkey, OpenSearch is missing on a large catalogue, or too many plugins sit in the request path. Moving from development mode to production mode usually produces the single largest gain. Work through that chain from the top down before you think about more hardware. Hardware hides causes, it does not remove them.
Stock levels diverge because “stock” and “available stock” have shown the same real-time value since Shopware 6.6: product.stock is updated through the order events, and availableStock is now only a read-only mirror. If the ERP delivers correct figures and the shop still shows the wrong ones, the transfer is the problem: which system writes last, are reservations counted twice, does the import break off? In the cart, the quantity can be raised beyond the stock level as long as the closeout flag is not set. That is the first thing to check; with sets, bundles or several sales channels on one warehouse, server-side validation is added.
Yes — Shopware 5 reached end of life at the end of July 2024: the manufacturer develops no further security updates and has handed commercial security support to safefive. A Shopware 5 shop keeps selling after that, it just stops getting safer — and so becomes a preferred target for exactly the automated attacks that look for known vulnerabilities. If you cannot migrate immediately, safefive buys you time: the security plugin is free in the Shopware Store but requires a contract, and the cost depends on annual net revenue and is charged per productive instance.
Enquiry
Describe briefly what you are seeing. For a break-in or an acute fault, better to call — we are faster than any form. And until then, please delete nothing.