Shopware-Hilfe
Fehler 500 im Checkout, falsche Bestände aus dem ERP, ein Shop, den seit Monaten niemand aktualisiert hat. Damit landen Sie hier. Die Sharpness Solutions GmbH aus Oldenburg hilft Betreibern selbst gehosteter Shopware-6-Shops bei Störungen, Updates, Migrationen von Shopware 5 und Schnittstellen zu ERP, PIM und CRM. Shopware 5 ist seit Ende Juli 2024 aus der Wartung, aktuell ist Shopware 6.7. Stand: 16. August 2026. Telefon 0441 21 21 63 0, Mo–Fr 9:00–16:00 Uhr.
Wer nach Shopware-Hilfe sucht, will kein Agenturprofil. Er hat ein Symptom. Diese sechs Fälle decken den größten Teil dessen ab, womit Betreiber bei der Sharpness Solutions GmbH in Oldenburg anrufen: Fehler 500 im Checkout, gescheitertes Update auf Shopware 6.7, Shop auf dem abgekündigten Shopware 5, abweichende Bestände aus dem ERP, schlechte Ladezeiten, Agentur ohne Antwort. Meist heißt es, gestern habe noch alles funktioniert. Der Auslöser lag schon länger vor.
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.
Shopware 5 ist seit Ende Juli 2024 aus der Herstellerwartung. Der Shop verkauft weiter, aber 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.
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 zum ERP sind deshalb fast immer ein Synchronisations- oder Reservierungsproblem, kein Indexierungsproblem.
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.
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.
Eine Support-Hotline für technische Störungen gibt es beim Hersteller nicht. Die Telefonnummer auf shopware.com führt zu Vertrieb und allgemeinen Anfragen; technischer Support setzt einen kostenpflichtigen Plan voraus und läuft über account.shopware.com, Betreiber der Community Edition werden ausdrücklich ans Community-Forum verwiesen. Wer also sucht, wo er eine Störung melden kann, sucht etwas, das beim Hersteller in dieser Form nicht existiert. Bei uns geht jemand ans Telefon, Mo–Fr 9:00–16:00 Uhr. Reaktionszeiten in Stunden sagen wir nicht pauschal zu. Sie stehen in einer SLA oder sie stehen nirgends. Außerhalb von Mo–Fr 9:00–16:00 Uhr geht hier niemand ans Telefon. Wer Samstagabend jemanden braucht, braucht Rufbereitschaft. Die gibt es nur mit SLA, und sie kostet auch in den Monaten, in denen nichts passiert.
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.
Eine Migration von Shopware 5 auf Shopware 6 ist kein Update, sondern ein Neuaufbau mit Datenübernahme. Der Shopware-Migrations-Assistent ist im Shopware-Store kostenlos und derzeit kompatibel mit 6.6.0.0 bis 6.7.13.0; im Quellshop wird zusätzlich das Migrations-Connector-Plugin installiert. Übernommen werden unter anderem Produkte, Varianten, Hersteller, Kategorien, Kunden, Bestellungen samt Bestelldokumenten, Medien, Versandarten, Cross-Selling, Custom Fields, SEO-URLs und Produktbewertungen. Vor dem Start läuft ein Datencheck, der Mappings verlangt. Gemeint sind Zuordnungen für alles, was sich nicht automatisch auflösen lässt.
Der Shopware-Migrations-Assistent migriert ausschließlich Daten. Er migriert nicht Ihr Aussehen, nicht Ihre Funktionen und nicht Ihre Schnittstellen. Theme und Erweiterungen werden neu gebaut, ERP-, PIM- und CRM-Anbindungen neu angebunden. Genau hier entstehen die Kosten, mit denen Betreiber regelmäßig überrascht werden, nicht beim Datentransfer. Eine Falle obendrauf: Die beim ersten Lauf angelegten Verkaufskanäle sollten Sie stehen lassen. Hängen Kunden daran, verweigert die Datenbank das Löschen ohnehin mit einer Foreign-Key-Verletzung; wer den Kanal auf Umwegen entfernt, riskiert unvollständige Folgeläufe. Prüfen Sie nach jedem Lauf die Zahl der übernommenen Kunden und Bestellungen gegen den Altshop. Es fehlen einfach Kunden und Bestellungen.
Über Erfolg oder Misserfolg einer Migration entscheiden am Ende die Weiterleitungen. Die SEO-URLs aus Shopware 5 lassen sich mitnehmen, aber die URL-Struktur von Shopware 6 ist eine andere; ohne vollständige Redirect-Liste verlieren Sie am Umschalttag gewachsene Rankings, und zwar dauerhaft. Wir erzeugen die Liste aus dem Altbestand, nicht aus Vermutungen, und prüfen sie vor dem Cutover. Wer dafür gerade keine Zeit hat, kauft sich mit safefive-Patches für Shopware 5 Luft. Das ist eine Verlängerung, keine Lösung. Platz 1 garantiert dabei niemand, wir auch nicht.
Shopware 6 hat zwei APIs und einen Sonderweg für Massendaten, der regelmäßig für eine dritte gehalten wird. Die Admin API ist die administrative Schnittstelle: Authentifizierung über OAuth 2.0 im Client-Credentials-Flow, die Integration wird unter Einstellungen → System → Integrationen angelegt, Access Key ID entspricht der client_id, Secret Access Key dem client_secret. Der Token kommt per POST auf /api/oauth/token, gilt standardmäßig 600 Sekunden und wandert danach als Bearer-Header mit; läuft er ab, wird ein neuer angefordert. Die Store API ist die kundenseitige Schnittstelle für Produktsuche, Warenkorb und Checkout. Sie authentifiziert über den Header sw-access-key des Verkaufskanals, nicht über OAuth.
Für Massendaten gibt es die Sync API: kein eigener Zugang, sondern ein Endpunkt der Admin API unter /api/_action/sync, mit demselben Token. Sie kennt nur zwei Operationen, upsert und delete, unterscheidet also nicht zwischen Anlegen und Ändern. Entscheidend für die Laufzeit ist der Header indexing-behavior: ohne ihn wird sofort im Request indexiert, mit use-queue-indexing übernimmt die Message Queue, mit disable-indexing entfällt sie ganz. Wer einen Vollimport ohne diesen Header fährt, wartet um Größenordnungen länger. Für den B2B-Einkauf kommen OCI- und cXML-Punch-out-Kataloge dazu. Das ist weder ein Core-Feature noch ein Modul der B2B Components, sondern kommt über eine Drittanbieter-Erweiterung oder als eigene Entwicklung auf Basis der Store API. Der Einkäufer startet im Beschaffungssystem, füllt den Warenkorb im Shop und gibt ihn dorthin zurück.
Die schwierigen Fragen einer ERP-Anbindung sind nicht technischer, sondern betrieblicher Natur: Wer besitzt welches Feld — Preis, Bestand, Beschreibung? Was passiert, wenn der Import mitten im Lauf abbricht? Darf derselbe Datensatz zweimal geschrieben werden, ohne Schaden anzurichten? Und wer liest das Fehlerprotokoll? Statische Staffel- und Kundengruppenpreise beherrscht Shopware 6 über den Rule Builder. Für kundenindividuelle Preise aus dem ERP gibt es zwei Wege: die Customer-Specific-Pricing-API der Shopware-Commercial-Erweiterung und, in den B2B Components, das Modul Individual Pricing. Wer das umgeht und jeden Kunden zur eigenen Kundengruppe macht, treibt die Tabelle product_price ins Absurde. Die Zeilenzahl wächst dann mit jedem Kunden mal jedem Artikel — und die Suche über diese Tabelle wird zum Flaschenhals im Checkout.
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 Infrastruktur.
Valkey, Redis und OpenSearch reparieren keine schlechte Abfrage. Ein Suchindex beschleunigt sie nicht, er verschiebt sie nur, und ein stiller Fallback auf die MySQL-Suche kaschiert das Problem, bis der Katalog wächst. Setzen Sie SHOPWARE_ES_THROW_EXCEPTION=1, damit dieser Fallback sichtbar wird. Auf Datenbankseite gehören zwei Werte dazu: group_concat_max_len ab 320000 und ein sql_mode ohne ONLY_FULL_GROUP_BY. Auf PHP-Seite sind es vier: opcache.validate_timestamps=0, opcache.interned_strings_buffer=20, zend.assertions=-1 und realpath_cache_ttl=3600. Das sind Betriebsparameter, keine Geheimtipps. Sie fehlen trotzdem erstaunlich oft.
Der in der Shopware-Dokumentation empfohlene Betriebsstack lässt sich Zeile für Zeile gegen Ihr Hosting halten: PHP 8.4 empfohlen, mindestens 8.2, memory_limit ab 512M; MariaDB 11.4 oder MySQL 8.4; Node.js 24 mit npm 10 für den Administration-Build; Valkey 8.0 oder alternativ Redis 7+; OpenSearch 2.17.1; Caddy als empfohlener Webserver, Nginx und Apache werden ebenfalls unterstützt. Wer darunter liegt, hat kein Performance-Problem, sondern ein Hosting-Problem. Wir betreiben Shopware-Instanzen auf eigenen Servern in Deutschland, auf Proxmox-PVE-Clustern, mit PHP 8.4, Valkey und OpenSearch.
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.
Für die Übernahme brauchen wir Zugänge, und die Liste ist immer dieselbe: Hosting beziehungsweise Server, Datenbank, Git-Repository, Shopware-Account, API-Schlüssel und Integrationen, dazu die Konfiguration von Redis oder Valkey und einem etwaigen Varnish. Ihr Hosting müssen Sie dafür nicht wechseln. Wir arbeiten auf dem Bestand; ein Umzug auf unsere Server ist eine eigene Entscheidung mit eigenem Angebot. Fehlt Dokumentation, ist das kein Ausschlusskriterium. Undokumentierter Code ist der Normalfall, nicht die Ausnahme. Das eigentliche Risiko beim Agenturwechsel ist selten der Wechsel selbst, sondern der unbekannte Zustand des Altsystems. Wie lange ein Wechsel dauert, entscheidet genau dieser Zustand: Bei vollständigen Zugängen und vorhandenem Git-Repository liegen wir erfahrungsgemäß im Bereich weniger Wochen. Die belastbare Zahl steht im Befundbericht, nicht davor.
Nach dem Befundbericht gibt es zwei Wege der Zusammenarbeit mit Sharpness. Entweder Sie beauftragen einzelne Arbeiten — ein Fehlerbild, ein Update, eine Schnittstelle — 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, die uns am häufigsten erreichen. Wer fremden Code nicht kennt, kann ihn nicht supporten. Deshalb übernehmen wir keinen Support ohne vorherigen Befund. Unter der Marke Sharpness entwickeln wir seit 1999 in Oldenburg, Vertragspartnerin ist die Sharpness Solutions GmbH.
Ablauf
0441 21 21 63 0, Mo–Fr 9:00–16:00 Uhr, oder über das Formular. Sie schildern das Symptom, wir sagen Ihnen, was wir sehen. Was die Reparatur kostet, steht danach im Befundbericht. Wir arbeiten bundesweit remote, Termine im Nordwesten nach Absprache.
Sie schildern das Symptom, wir fragen nach Shopware-Version, Hosting, Plugin-Liste und dem letzten Deployment. Aus dem Symptom wird eine Hypothese. Erreichbar sind wir Mo–Fr 9:00–16:00 Uhr, telefonisch oder über das Formular.
Wir brauchen Shell- oder SFTP-Zugang, Datenbank, Git und Admin. Dann lesen wir Logs, Composer-Stand und Plugin-Liste, statt zu vermuten. Fehlt ein Staging-System, richten wir zuerst eines ein.
Sie bekommen von Sharpness schriftlich, was kaputt ist, warum es kaputt ist und was die Reparatur kostet. Dazu die Risiken, die wir nebenbei gefunden haben — mit Priorität, nicht als Wunschliste.
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.
Danach entweder Wartungsvertrag mit SLA, Monitoring und geplanten Updates — oder eine saubere Übergabe an Ihr Team samt Dokumentation. Beides ist in Ordnung. Ein Shop, den niemand pflegt, ist es nicht.
Projekte auf diesem System
Ein Auszug — nicht die vollständige Kundenliste.
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–Fr 9:00–16:00 Uhr unter 0441 21 21 63 0.
Verbindliche Reaktionszeiten sagt Sharpness ohne Wartungsvertrag nicht zu. Innerhalb der Geschäftszeiten, Mo–Fr 9:00–16:00 Uhr, nehmen wir Ihre Störungsmeldung 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 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. Migrationen und Schnittstellen kalkulieren wir daraus, nicht am Telefon. 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.
Aktuell ist Shopware 6.7.13.0, veröffentlicht am 5. August 2026 (Stand dieser Seite: 16. August 2026). Für Neuprojekte ist der aktuelle 6.7-Stand die richtige Wahl. Für Bestandsshops gilt: Auf dem laufenden Major bleiben und Patch-Stände zeitnah nachziehen. Neue x.x.x.0-Releases sollten Sie meiden — Neue x.x.x.0-Releases sollten Sie meiden — Shopware hat 6.7.12.0 kurz nach der Veröffentlichung gesperrt: Laut Release-Notes kann diese Version wegen eines nachträglich entdeckten Fehlers nicht installiert oder aktualisiert werden, stattdessen ist 6.7.12.1 zu verwenden. Warten Sie auf einen späteren Patch-Stand. Warten Sie auf einen späteren Patch-Stand.
Shopware 6.7 wird gepflegt, solange 6.7 der laufende Major ist; ein festes Enddatum nennt Shopware nicht, und die nächste Major-Version 6.8 wurde am 12. November 2025 auf 2027 verschoben. Der Grund für die fehlende Jahreszahl: Shopware koppelt Supportübergänge an Major-Releases, nicht an Kalenderdaten — im Original: „Support transitions are tied to major releases, not fixed timelines.“ Es gibt vier Zustände: Maintained, Extended Support, Security fixes only und End of life. Der Extended Support für 6.6 verlängert sich entsprechend bis zum Release von 6.8.
Ja — Shopware 5 hat Ende Juli 2024 das End of Life erreicht: 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. 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.
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.
Der reine Datenlauf des Shopware-Migrations-Assistenten dauert je nach Katalog- und Bestellmenge Stunden. Den Zeitplan bestimmt nicht er, sondern der Neubau: Theme, Erweiterungen und Schnittstellen überträgt der Assistent nicht, sie werden neu gebaut und neu angebunden. Wie viele Wochen das sind, hängt an der Zahl der Erweiterungen, an ERP-, PIM- und CRM-Anbindungen und am Zustand der Altdaten. Eine belastbare Zahl steht im Befundbericht vor Projektbeginn, nicht im ersten Telefonat.
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.
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.
Redis beziehungsweise Valkey, Varnish und OpenSearch sind für einen Shopware-6-Shop nicht automatisch nötig — ob sie sich lohnen, hängt von Kataloggröße, Traffic und Architektur ab. Shopware empfiehlt Valkey 8.0 oder Redis 7+ für Caching und für verzögerte Cache-Invalidierung bei vielen gleichzeitigen Schreibzugriffen, einen Reverse-Proxy wie Varnish vor allem bei mehreren App-Servern und OpenSearch 2.17.1, sobald die MySQL-Suche an Grenzen stößt. Setzen Sie dabei SHOPWARE_ES_THROW_EXCEPTION=1, sonst fällt die Suche still auf MySQL zurück und Sie halten ein Problem für gelöst, das noch da ist.
Anfrage
Beschreiben Sie kurz, was nicht funktioniert oder was ansteht. Bei akuten Störungen rufen Sie besser an — dann sind wir schneller als jedes Formular.