Shopware-Hilfe
Fremdes JavaScript im Checkout, ein Fehler 500 bei der Bestellung, eine leere Administration nach dem Update oder ein Shop, der von Woche zu Woche langsamer wird: Damit landen Sie hier. Die Sharpness Solutions GmbH aus Oldenburg hilft Betreibern selbst gehosteter Shopware-6-Shops in fester Reihenfolge — erst sichern, dann verstehen, dann reparieren —, auch wenn wir den Shop nicht gebaut haben. Erreichbar Mo–Do 9:00–16:00 Uhr, Fr 9:00–13:00 Uhr unter 0441 21 21 63 0, außerhalb der Geschäftszeiten über das Formular unten. Notfälle bearbeiten wir vor allen anderen Anfragen.
Wer nach Shopware-Hilfe sucht, will kein Agenturprofil. Er hat ein Symptom. Die sechs Fälle unten decken den größten Teil dessen ab, womit Betreiber bei Sharpness (Oldenburg) anrufen, und sie fallen in drei Gruppen: Der Shop ist kompromittiert, der Shop ist kaputt, oder er läuft, aber schlecht. Meist heißt es, gestern habe noch alles funktioniert. Der Auslöser lag fast immer schon länger vor.
Kunden berichten von missbrauchten Karten oder Konten, die Zahlungsseite sieht plötzlich anders aus, im Quelltext lädt ein Skript von einer Domain, die niemand kennt. Das ist das Muster eines Skimmers, der Eingaben im Checkout mitliest. Jetzt nichts löschen: erst sichern, dann analysieren — und den Zahlungsanbieter informieren.
Ein Benutzer, den niemand angelegt hat, eine Integration mit Admin-Zugriff, die niemand kennt, Besucher landen auf fremden Seiten, Google listet Seiten mit Inhalten, die es in Ihrem Shop nie gab. Jedes davon ist ein Grund, den Shop als kompromittiert zu behandeln, bis das Gegenteil feststeht.
Der Shop lädt, aber die Bestellung scheitert. Erste Spur: var/log/ im Shopware-Verzeichnis. Danach bin/console cache:clear und die Plugins einzeln deaktivieren. Bleibt der Fehler, liegt er im Code — meist in einer Erweiterung im Bestellprozess.
Shopware 6.7 hat das Build-System von Webpack auf Vite umgestellt, Vuex durch Pinia ersetzt und die Cached*Route-Klassen entfernt. Erweiterungen, die darauf aufsetzen, brechen still. Wir prüfen Ihre Plugin-Liste gegen 6.7, bevor Sie updaten.
Bevor Redis ins Spiel kommt, prüft Sharpness drei Dinge: Läuft die Instanz noch im Development-Modus? Ist der HTTP-Cache aktiv? Wie viele Plugins hängen im Request-Pfad? Der Development-Modus ist dabei der häufigste Fund.
Sie haben einen Shop, aber keine Zugänge, keine Doku und keinen Ansprechpartner. Das ist unangenehm und trotzdem lösbar. Was Ihnen vertraglich zusteht, klärt anwaltliche Beratung, nicht Ihre neue Agentur. Die technische Bestandsaufnahme läuft auch ohne Mitwirkung der Altagentur.
Wenn ein Shopware-Shop gehackt wurde, kommt zuerst die Sicherung, nicht das Aufräumen: Shop in den Wartungsmodus nehmen oder beim Hoster vom Netz, Dateien und Datenbank als Kopie sichern, Server- und Zugriffsprotokolle sichern, Verwaltungszugänge sperren. Erst dann wird analysiert. Der naheliegende Impuls — auffällige Dateien löschen, das Admin-Passwort ändern und weiterverkaufen — zerstört Spuren und schließt die Tür nicht. Die Hintertür liegt fast nie dort, wo die erste auffällige Datei liegt.
In einem Shopware-6-Shop suchen wir dort, wo Angreifer sich einrichten: zusätzliche Benutzer unter Einstellungen → System → Benutzer, fremde Integrationen mit Admin-API-Zugriff unter Einstellungen → System → Integrationen, geänderte Twig-Templates und JavaScript-Dateien im Theme und in den Erweiterungen unter custom/plugins und custom/apps, eingeschleustes HTML in Erlebniswelten und Textbausteinen, unbekannte Dateien unter public/ und geplante Aufgaben auf dem Server. Core und Erweiterungen vergleichen wir mit den Originalquellen aus Composer und Store. So wird sichtbar, was hinzugefügt oder verändert wurde, und aus den Zugriffsprotokollen ergibt sich, wann und über welchen Weg.
Ein Skimmer im Checkout ist der ernsteste Fall, weil er Daten abgreift, während der Shop normal weiterverkauft. Er sitzt meist als nachgeladenes Skript in einem Template oder einer Erweiterung und liest mit, was Kunden in Formulare tippen. Leitet Ihr Checkout zum Zahlungsanbieter weiter, sinkt das Risiko für Kartendaten — für Adressen, Kundenkonten und Bestellungen sinkt es nicht. Informieren Sie Ihren Zahlungsanbieter, sobald Zahlungsseiten manipuliert sein könnten. Waren personenbezogene Daten erreichbar, verlangt Artikel 33 DSGVO eine Meldung an die zuständige Aufsichtsbehörde binnen 72 Stunden. Die technischen Fakten dafür liefern wir, ob gemeldet wird, entscheiden Sie mit Ihrem Datenschutzbeauftragten.
Der sauberste Weg zurück ist ein Backup von vor dem Einbruch, ergänzt um alle Sicherheitsupdates, die seitdem erschienen sind. Bestellungen und Kundenkonten, die seit dem Backup entstanden sind, gleichen wir ab und übernehmen sie geprüft. Gibt es kein verlässliches Backup, setzen wir Shopware und die Erweiterungen aus den Originalquellen neu auf und übernehmen aus der befallenen Installation nur, was sich prüfen lässt: Datenbankinhalte, Medien und eigene Plugins nach Durchsicht des Codes.
Danach werden alle Zugangsdaten getauscht, ohne Ausnahme: Administratoren, Integrationen und API-Schlüssel, Datenbank, SFTP und SSH, Zahlungs- und Versanddienste, Mailversand. Ein Schlüssel, den der Angreifer kennt, macht die beste Wiederherstellung wertlos. Dann wird die Ursache geschlossen — meist ein Shopware-Stand ohne Sicherheitsupdates oder eine veraltete Erweiterung — und der Shop gehärtet: ein zweiter Faktor vor der Administration, Verwaltung nur aus bekannten Netzen, auf Wunsch eine vorgelagerte Firewall mit Cloudflare, deren Regeln Zahlungsanbieter und Warenwirtschaft nicht aussperren.
Shopware veröffentlicht Sicherheitshinweise zu seinen Versionen, und der Patch gegen eine ausgenutzte Lücke ist fast immer schon verfügbar, wenn der Einbruch passiert. Die unbequeme Erkenntnis aus solchen Fällen: Sicherheitsupdates in festen Intervallen hätten den Vorfall meist verhindert, zu einem Bruchteil dessen, was Analyse und Neuaufbau kosten. Hundertprozentige Sicherheit versprechen wir nicht. Was wir herstellen, ist ein Zustand, in dem Massenangriffe ins Leere laufen und ein Vorfall ein Vorfall bleibt.
Ein Fehler 500 (HTTP 500, „Internal Server Error“) im Checkout eines Shopware-6-Shops hat fast immer eine von drei Ursachen: Cache, Indexierung oder ein Plugin. Die Reihenfolge zur Selbsthilfe: 1. Logdateien unter var/log/ lesen. 2. bin/console cache:clear, cache:clear:http und cache:warmup. 3. bin/console dal:refresh:index, wenn neue Produkte nicht erscheinen. 4. bin/console plugin:deactivate, danach erneut cache:clear. Meldungen wie „Unable to generate a URL for the named route“ deuten auf Cache oder Routing. Ein Fehler aus dem Suchindex, also aus Elasticsearch beziehungsweise OpenSearch, beim Aufruf einer Kategorie deutet auf den Index, dann hilft bin/console es:index. „Class not found“ oder eine weiße Seite deuten auf ein Plugin. Wer das durchhat und weiter im Dunkeln steht, braucht jemanden mit Shell-Zugang.
Nach einem Update ist der häufigste Defekt eine Erweiterung, die nicht mehr zur neuen Version passt. Shopware 6.7 war ein Infrastruktur-Release mit harten Breaking Changes: Das Administration-Buildsystem wechselte von Webpack auf Vite, das State-Management von Vuex auf Pinia, die Cached*Route-Klassen entfielen, Header und Footer laden per ESI. Erweiterungen und eigene Templates, die darauf aufsetzen, brechen still — die Administration bleibt leer, der Checkout wirft Fehler. Wir prüfen Plugin- und Template-Stand gegen die Zielversion, bevor ein Update produktiv geht, und fahren Updates über die Kommandozeile statt über den grafischen Updater.
Im Störungsfall arbeitet Sharpness rückwärts vom letzten funktionierenden Zustand: Was wurde zuletzt deployed, welches Plugin wurde installiert, welcher Composer-Stand liegt vor. Reproduziert wird auf einem Staging-System, nicht im Live-Shop. Erst wenn die Ursache benannt ist, wird gefixt. Ein Rollback ist eine Entscheidung, keine Panikreaktion. Wer Updates ausschließlich über die grafische Oberfläche fährt und kein Staging hat, hat auch keinen Rückweg. Diese Lücke schließen wir zuerst, weil sie den nächsten Notfall billiger macht als den aktuellen.
Ein langsamer Shopware-Shop hat meist eine Ursachenkette, keinen einzelnen Schuldigen, und sie lässt sich in fester Reihenfolge abarbeiten. Zuerst: Läuft die Instanz noch im Development-Modus? Dann schreibt Shopware bei jedem Request Debug-Logs und kompiliert Templates neu. Allein die Umstellung auf den Production-Modus bringt in der Regel den größten Einzelsprung; wie groß, sagen wir erst nach der Messung. Zweitens: Ist der HTTP-Cache über SHOPWARE_HTTP_CACHE_ENABLED=1 überhaupt aktiv? Drittens: Wie viele Plugins hängen im Request-Pfad, und was machen sie dort? Erst danach lohnt das Gespräch über Redis, Valkey oder OpenSearch.
Meldet das ERP andere Bestände als der Shop, liegt das fast nie an Shopware selbst. Seit Shopware 6.6 ist der Bestand ein Echtzeitwert: product.stock wird über die Bestell-Events fortgeschrieben, der frühere „verfügbare Bestand“ ist nur noch ein schreibgeschützter Spiegel desselben Feldes. Abweichungen sind deshalb fast immer ein Synchronisations- oder Reservierungsproblem: Welches System schreibt zuletzt, werden Reservierungen doppelt gezählt, bricht der Import mitten im Lauf ab? Das klären wir an der Schnittstelle, nicht im Index.
Läuft der Shop noch auf Shopware 5, ist das kein akuter Defekt, aber ein offenes Risiko: Shopware 5 ist seit Ende Juli 2024 aus der Herstellerwartung, und jede neue Lücke bleibt offen, solange Sie keine Patches über safefive beziehen — den kostenpflichtigen Drittanbieter-Dienst, der die Pflege übernommen hat. safefive verschiebt den Migrationstermin, es ersetzt ihn nicht. Eine Migration auf Shopware 6 ist kein Update, sondern ein Neuaufbau mit Datenübernahme. Wie wir Shops neu bauen, steht auf einer eigenen Seite.
Sharpness übernimmt bestehende Shopware-Shops, aber nicht blind. Am Anfang steht eine Bestandsaufnahme: Shopware-Version und Patch-Stand, Composer- und Plugin-Liste mit Herkunft, Umfang des eigenen Codes, Zustand des Hostings, vorhandene Deployment-Wege, Backups und ihre Wiederherstellbarkeit. Daraus wird ein Befundbericht mit Risikoliste und Aufwandsschätzung, ein abgegrenztes Erstprodukt, kein Vertriebsgespräch. Erst danach sagen wir zu, was wir übernehmen können. Eine Zusage vor dem Blick in den Code wäre geraten, und Raten ist bei fremdem Code keine Methode.
Nach dem Befundbericht gibt es zwei Wege der Zusammenarbeit mit Sharpness. Entweder Sie beauftragen einzelne Arbeiten — ein Fehlerbild, ein Update, eine Bereinigung — und wir rechnen nach Aufwand ab. Oder wir vereinbaren einen Wartungsvertrag mit einer SLA, in der Reaktionszeiten, Erreichbarkeit und Leistungsumfang schriftlich stehen. Der Unterschied zum Support des Herstellers: Shopware unterstützt sein eigenes Produkt, nicht Ihre Drittanbieter-Plugins und nicht Ihren individuellen Code. Genau dort sitzen die Fehler und Lücken, die uns am häufigsten erreichen. Unter der Marke Sharpness entwickeln wir seit 1999 in Oldenburg, Vertragspartnerin ist die Sharpness Solutions GmbH.
Ablauf
0441 21 21 63 0, Mo–Do 9:00–16:00 Uhr, Fr 9:00–13:00 Uhr, außerhalb dieser Zeiten über das Formular. Sie schildern das Symptom, wir sagen Ihnen, was Sie jetzt nicht tun sollten und was wir sehen. Was die Reparatur kostet, steht danach im Befundbericht. Wir arbeiten bundesweit remote, Termine im Nordwesten nach Absprache.
Sie schildern das Symptom: Was sehen Sie, seit wann, was wurde zuletzt geändert? Bei Verdacht auf einen Einbruch sagen wir Ihnen sofort, was Sie selbst nicht tun sollten. Erreichbar sind wir Mo–Do 9:00–16:00 Uhr, Fr 9:00–13:00 Uhr; Notfälle bearbeiten wir vor allen anderen Anfragen.
Wartungsmodus, Kopie von Dateien und Datenbank, Protokolle sichern. Dazu brauchen wir Shell- oder SFTP-Zugang, Datenbank, Git und Administration. Nichts wird gelöscht, bevor es gesichert ist. Fehlt ein Staging-System, richten wir zuerst eines ein.
Logs, Composer-Stand, Plugin-Liste und Dateivergleich statt Vermutungen. Sie bekommen von Sharpness schriftlich, was kaputt ist, warum und was die Reparatur kostet — nach einem Einbruch zusätzlich Einstiegsweg, Zeitpunkt und Umfang.
Gearbeitet wird auf einem Staging-System, nicht im Livebetrieb. Updates fahren wir über die Kommandozeile statt über den grafischen Updater, x.x.x.0-Releases meiden wir und warten auf einen belastbaren Patch-Stand.
Nach dem Livegang messen wir dieselben Werte wie vorher: Antwortzeiten, Fehlerrate im Log, Indexierungsdauer. Ohne Vorher-Wert ist jede Verbesserung eine Behauptung. Das Ergebnis bekommen Sie als Vergleich, nicht als Adjektiv.
Ursache geschlossen, Zugänge getauscht, auf Wunsch eine Firewall davor. Danach Wartungsvertrag mit SLA, Monitoring und geplanten Updates — auf einem Stand, den wir jetzt kennen. Ein Shop, den niemand pflegt, ist der nächste Notfall.
Projekte auf diesem System
Ein Auszug — nicht die vollständige Kundenliste.
Im ganzen Nordwesten
Wir arbeiten für Unternehmen von Wuppertal und Münster über das Emsland und Ostfriesland bis Hamburg und Hannover. Termine vor Ort nach Absprache, die laufende Arbeit remote. Zu jeder Region gibt es eine eigene Seite.
Eine öffentliche Support-Hotline für technische Störungen gibt es bei Shopware nicht: Bestandskunden mit kostenpflichtigem Plan gehen über account.shopware.com, Betreiber der Community Edition werden ausdrücklich ans Community-Forum verwiesen. Die kostenpflichtigen Pläne beginnen laut Shopware-Preisübersicht bei Rise ab 600 Euro pro Monat und Evolve ab 2.400 Euro pro Monat, jeweils zuzüglich Mehrwertsteuer. Technische Hilfe für einen selbst gehosteten Shop kommt deshalb meist von Dienstleistern, etwa der Sharpness Solutions GmbH in Oldenburg, Mo–Do 9:00–16:00 Uhr, Fr 9:00–13:00 Uhr unter 0441 21 21 63 0.
Drei Dinge: den Shop in den Wartungsmodus nehmen oder beim Hoster vorübergehend abschalten, damit keine Kundendaten mehr abfließen; nichts löschen und nichts „aufräumen“; und von einem anderen, sauberen Gerät aus die Passwörter von E-Mail-Postfach und Hoster-Kundenkonto ändern. Danach rufen Sie an, Mo–Do 9:00–16:00 Uhr, Fr 9:00–13:00 Uhr unter 0441 21 21 63 0, außerhalb dieser Zeiten über das Formular. Sicherung, Analyse und Wiederherstellung laufen dann in fester Reihenfolge.
Typische Zeichen sind Benutzer oder Integrationen in der Administration, die niemand angelegt hat, Skripte von unbekannten Domains im Quelltext — besonders im Checkout —, Weiterleitungen auf fremde Seiten, Spam-Seiten unter Ihrer Domain bei Google, eine Warnung in der Google Search Console, eine Abuse-Meldung des Hosters oder Spam aus Ihrem Mailversand. Ein unauffälliger Shop ist allerdings kein Beweis: Skimmer sind darauf gebaut, nicht aufzufallen. Bei einem konkreten Verdacht prüfen wir Dateien, Datenbank und Protokolle gegen die Originalquellen.
Ja, wenn auch in geringerem Maß. Leitet der Checkout auf die Seite des Zahlungsanbieters weiter, tippen Kunden ihre Kartendaten nicht in Ihren Shop. Ein Skimmer kann aber vorher ein gefälschtes Zahlungsformular einblenden, und Adressen, E-Mail-Adressen und Kundenpasswörter laufen ohnehin über Ihre Seiten. Sharpness behandelt deshalb jedes fremde Skript im Checkout als Vorfall, unabhängig von der Zahlungsart, und rät dazu, den Zahlungsanbieter früh einzubinden.
Wenn personenbezogene Daten betroffen waren oder sein könnten — Kundenkonten, Adressen, Bestellungen —, verlangt Artikel 33 DSGVO eine Meldung an die zuständige Aufsichtsbehörde binnen 72 Stunden; bei hohem Risiko sind nach Artikel 34 auch die Betroffenen zu informieren. Sharpness liefert die technischen Fakten dafür: Zeitpunkt, Einstiegsweg, betroffene Daten. Ob und was gemeldet wird, entscheiden Sie mit Ihrem Datenschutzbeauftragten. Rechtsberatung leisten wir nicht.
Notfälle wie ein gehackter oder stehender Shop bearbeiten wir vor allen anderen Anfragen, verbindliche Reaktionszeiten sagt Sharpness ohne Wartungsvertrag aber nicht zu. Innerhalb der Geschäftszeiten, Mo–Do 9:00–16:00 Uhr, Fr 9:00–13:00 Uhr, nehmen wir Ihre Meldung telefonisch oder über das Formular an und sagen Ihnen, wann wir sie bearbeiten können. Außerhalb dieser Zeiten geht hier niemand ans Telefon. Wer abends, am Wochenende oder an Feiertagen jemanden braucht, braucht Rufbereitschaft. Feste Fristen, Erreichbarkeit und Leistungsumfang regelt ein Wartungsvertrag mit SLA — der kostet auch in den Monaten, in denen nichts passiert.
Einzelaufträge und Soforthilfe rechnet die Sharpness Solutions GmbH nach Aufwand ab, laufende Betreuung läuft über einen Wartungsvertrag mit monatlicher Pauschale und SLA. Feste Zahlen nennen wir erst, wenn wir den Shop gesehen haben. Der Befundbericht mit Risikoliste und Aufwandsschätzung ist ein abgegrenztes Erstprodukt zum Festpreis, den wir vorher schriftlich nennen. Wie aufwendig eine Bereinigung wird, hängt vor allem daran, ob ein sauberes Backup existiert und wie lange der Angreifer unbemerkt arbeiten konnte. Den aktuellen Stundensatz und den Preis des Befundberichts bekommen Sie auf Anfrage.
Die auf dieser Seite beschriebenen Eingriffe setzen einen selbst gehosteten Shopware-6-Shop voraus, also Community Edition oder Commercial on-premise: Logs unter var/log/, bin/console, eigenes Staging, eigene Server. In Shopware Cloud gibt es weder Shell noch bin/console. Dort übernimmt Sharpness Konfiguration, App-Entwicklung nach Shopware-Standard und Schnittstellen über Admin API und Store API; Eingriffe in Server, Cache und Datenbank sind dem Hersteller vorbehalten. Welche Variante Sie betreiben, klären wir im ersten Telefonat.
Shopware 6.7 war ein Infrastruktur-Release mit harten Breaking Changes, deshalb brechen vor allem Erweiterungen und individuelle Templates. Das Administration-Buildsystem wechselte von Webpack auf Vite, das State-Management von Vuex auf Pinia, das Store-API-Route-Caching samt aller Cached*Route-Klassen entfiel, die Payment-Handler wurden auf eine einheitliche AbstractPaymentHandler-Klasse umgestellt, Header und Footer laden per ESI. Custom-Field-Namen dürfen keine Bindestriche oder Punkte mehr enthalten. Dazu kamen Barrierefreiheits-Umbauten im Storefront, die eigene Templates zerlegen können. Wir prüfen Plugin- und Template-Stand gegen 6.7, bevor ein Update produktiv geht.
Ein langsamer Shopware-6-Shop hat fast immer eine von fünf Ursachen, in der Reihenfolge der Häufigkeit: Die Instanz läuft noch im Development-Modus, der HTTP-Cache ist nicht aktiviert, es gibt keinen Objekt-Cache in Redis oder Valkey, bei großem Katalog fehlt OpenSearch, oder zu viele Plugins hängen im Request-Pfad. Der Wechsel vom Development- in den Production-Modus bringt dabei meist den größten Einzelsprung. Arbeiten Sie diese Kette von oben nach unten ab, bevor Sie über zusätzliche Hardware nachdenken. Hardware kaschiert Ursachen, sie beseitigt keine.
Weil „Lagerbestand“ und „verfügbarer Bestand“ seit Shopware 6.6 denselben, in Echtzeit geführten Wert zeigen: product.stock wird über die Bestell-Events aktualisiert, availableStock ist nur noch ein schreibgeschützter Spiegel. Wenn das ERP korrekt liefert und der Shop trotzdem falsch anzeigt, liegt es an der Übertragung: Welches System schreibt zuletzt, werden Reservierungen doppelt gezählt, bricht der Import ab? Im Warenkorb lässt sich die Menge über den Bestand hinaus erhöhen, solange der Abverkauf-Schalter nicht gesetzt ist. Das ist der erste Griff; bei Sets, Bundles oder mehreren Kanälen auf einem Lager kommt serverseitige Validierung dazu.
Ja — Shopware 5 hat Ende Juli 2024 das End of Life erreicht: Der Hersteller entwickelt keine Sicherheitsupdates mehr und hat den kommerziellen Sicherheits-Support an safefive übergeben. Ein Shopware-5-Shop verkauft danach weiter, er wird nur nicht mehr sicherer — und ist damit ein bevorzugtes Ziel genau der automatisierten Angriffe, die nach bekannten Lücken suchen. Wer nicht sofort migrieren kann, kauft mit safefive Zeit: Das Sicherheits-Plugin ist im Shopware-Store kostenlos, setzt aber einen Vertrag voraus; die Kosten richten sich nach Jahresnettoumsatz und werden je produktiver Instanz berechnet.
Anfrage
Beschreiben Sie kurz, was Sie sehen. Bei einem Einbruch oder einer akuten Störung rufen Sie besser an — dann sind wir schneller als jedes Formular. Und bis dahin bitte nichts löschen.