Viele Unternehmen betreiben weiterhin einen OXID eShop 6. Der Shop läuft, Bestellungen gehen ein und im Tagesgeschäft gibt es keinen offensichtlichen Grund, kurzfristig etwas zu verändern.
Doch diese vermeintliche Sicherheit kann trügen.
Denn auch wenn am Shop selbst nichts geändert wird, entwickeln sich die technische Infrastruktur und die Anforderungen der Hostinganbieter weiter. Genau das geschieht derzeit bei MySQL 5.7: Die veraltete Datenbankversion wird nach und nach abgeschaltet und durch MySQL 8.0 ersetzt.
Für Betreiber eines älteren OXID eShop 6 kann diese Umstellung weitreichende Folgen haben. Im schlimmsten Fall funktioniert der Shop nach dem Datenbankupdate nur noch teilweise, das Backend lässt sich nicht mehr zuverlässig bedienen oder Kunden können ihre Bestellung nicht mehr abschließen.
Besonders dringend ist das Thema für Kunden des bekannten OXID-Hostingpartners PROFIHOST. PROFIHOST stellt seine Systeme schrittweise von MySQL 5.7 auf MySQL 8.0 um. Der Weiterbetrieb von MySQL 5.7 kann nur noch vorübergehend über eine zusätzliche Hostinglösung verlängert werden – laut PROFIHOST bis September 2026.
UPDATE (30.07.2026): PROFIHOST hat angekündigt, dass MySQL 5.7 über den 30.09.2026 unterstützt wird: „(…) profihost wird MySQL 5.7 auch über den 30.09.2026 hinaus weiter unterstützen. Die bisher kommunizierte Beendigung des Extended Supports zu diesem Datum entfällt damit. (…)“
Wer noch einen OXID eShop 6 betreibt, sollte deshalb jetzt prüfen lassen, ob der Shop auf die Umstellung vorbereitet ist.
Ein Datenbankupdate, das den gesamten Shop betreffen kann
Aus Sicht eines Shopbetreibers klingt der Wechsel von MySQL 5.7 auf MySQL 8.0 zunächst nach einer technischen
Aktualisierung im Hintergrund.
Der Hoster aktualisiert die Datenbank, der Shop bleibt bestehen und der Geschäftsbetrieb läuft weiter. So zumindest
die naheliegende Erwartung.
Bei OXID eShop 6.5 ist die Situation jedoch komplizierter. Die Software verwendet an einigen Stellen ältere
Datenbankfunktionen, die in MySQL 8.0 nicht mehr vorhanden sind.
Versucht der Shop nach der Umstellung, eine solche Funktion aufzurufen, entsteht ein Datenbankfehler. In den
technischen Protokollen sieht dieser beispielsweise so aus:
SQLSTATE[42000]: Syntax error or access violation: 1305 FUNCTION ... DECODE does not exist
Der Shopbetreiber bekommt diese konkrete Fehlermeldung häufig gar nicht zu sehen. Stattdessen erscheint im Shop oder
im Administrationsbereich lediglich eine allgemeine technische Fehlermeldung.
Das Problem kann dabei sehr unterschiedliche Bereiche betreffen:
- Einstellungen im OXID-Backend lassen sich nicht mehr öffnen oder speichern.
- Module können ihre Konfiguration nicht mehr lesen.
- Theme-Einstellungen funktionieren nicht mehr.
- Einzelne Seiten des Shops können ausfallen.
- Automatisierte Prozesse und Schnittstellen können Fehler erzeugen.
- Im schlimmsten Fall bricht der Checkout beim Abschluss einer Bestellung ab.
Gerade der letzte Punkt macht das Thema geschäftskritisch.
Eine funktionierende Startseite ist noch kein Entwarnungssignal
Nach einer technischen Umstellung wird häufig zunächst geprüft, ob die Startseite des Shops erreichbar ist. Ist das
der Fall, gilt das Update schnell als erfolgreich.
Bei der Umstellung eines OXID eShop 6 auf MySQL 8.0 reicht diese Prüfung jedoch nicht aus.
Die problematischen Datenbankzugriffe werden teilweise erst ausgeführt, wenn eine bestimmte Moduleinstellung
aufgerufen, eine Konfiguration gespeichert oder eine Bestellung abgeschlossen wird.
Das bedeutet: Ein Shop kann auf den ersten Blick normal aussehen und trotzdem keine Bestellungen mehr zuverlässig
verarbeiten.
Auch ein Test bis zum Warenkorb genügt nicht. Der Fehler kann erst im letzten Schritt auftreten, wenn der Kunde die
Bestellung verbindlich absendet.
Nach unseren Erfahrungen kann der Bestellabschluss nicht nur bei komplexen Zahlungsarten wie PayPal oder Kreditkarte
betroffen sein. Auch bei einer Standardzahlungsart wie Vorkasse kann der Checkout scheitern, weil OXID während der
Bestellverarbeitung auf einen nicht mehr kompatiblen Datenbankzugriff zurückgreift.
Für einen Shopbetreiber ist das besonders gefährlich: Der Ausfall wird möglicherweise erst bemerkt, wenn Kunden
Bestellungen abbrechen oder sich beim Support melden.
Wurde das Thema von Ihrer Agentur bereits vollständig geprüft?
Viele OXID-eShop-6-Projekte werden seit Jahren von derselben OXID-Agentur, einem freien Entwickler oder einer internen
IT-Abteilung betreut.
Dabei wird die Umstellung auf MySQL 8.0 teilweise unterschätzt. Mitunter beschränkt sich die Vorbereitung auf ein
Datenbank-Backup und einen kurzen Aufruf des Shops nach dem Update.
Wer bisher lediglich die Aussage erhalten hat, dass die Umstellung „vermutlich problemlos“ funktionieren werde, sollte
noch einmal gezielt nachfragen:
Wurde der Shop bereits vollständig unter MySQL 8.0 getestet?
Wurden dabei auch das Backend, die Modulkonfigurationen, das aktive Theme, sämtliche Zahlungsarten und der
vollständige Bestellabschluss geprüft?
Wurden individuelle Erweiterungen, Schnittstellen, Exporte und automatisierte Prozesse berücksichtigt?
Und wurde geprüft, ob bestehende Konfigurationsdaten vor der Umstellung vorbereitet werden müssen?
Kann die betreuende Agentur diese Fragen nicht eindeutig beantworten, besteht weiterer Handlungsbedarf.
Warum die Vorbereitung vor der Umstellung erfolgen muss
Ein besonders kritischer Punkt liegt in der bisherigen Speicherung bestimmter OXID-Konfigurationswerte.
Ein Teil dieser Werte wurde unter MySQL 5.7 in einer Form gespeichert, die mithilfe einer alten MySQL-Funktion wieder
lesbar gemacht wird. Diese Funktion steht unter MySQL 8.0 nicht mehr zur Verfügung.
Deshalb genügt es nicht, nach der Umstellung lediglich ein paar Programmdateien auszutauschen.
Die vorhandenen Konfigurationsdaten müssen zunächst kontrolliert in eine Form überführt werden, die auch nach dem
Wechsel auf MySQL 8.0 gelesen werden kann. Dieser vorbereitende Schritt sollte stattfinden, solange noch eine
MySQL-5.7-kompatible Datenbankumgebung verfügbar ist.
Wurde die Datenbank bereits umgestellt und existieren weder ein geeignetes Backup noch eine kompatible
Datenbankinstanz, kann die Wiederherstellung der betroffenen Einstellungen erheblich aufwendiger werden.
Im ungünstigsten Fall müssen Modul- und Shopkonfigurationen manuell rekonstruiert werden.
Deshalb lautet unsere wichtigste Empfehlung:
Warten Sie nicht darauf, dass der Shop nach der MySQL-8.0-Umstellung ausfällt. Die Vorbereitung muss vorher
erfolgen.
Unser kostenloser MySQL-8.0-Fix für OXID eShop 6.5
Für OXID-eShop-6.5-Projekte, bei denen ein vollständiges Update nicht mehr rechtzeitig umgesetzt werden kann, haben
wir einen pragmatischen Workaround entwickelt.
Der KUSSIN | MySQL 8.0 Fix steht kostenfrei auf GitHub zur Verfügung: https://github.com/kussin/oxid-mysql8-fix
Die Lösung besteht im Wesentlichen aus zwei Schritten.
Zunächst werden die betroffenen Konfigurationsdaten noch auf der bisherigen Datenbankumgebung für MySQL 8.0
vorbereitet. Anschließend wird ein Patch installiert, der die uns bekannten inkompatiblen Datenbankzugriffe innerhalb
von OXID eShop 6.5 anpasst.
Der Patch kann so in das Projekt eingebunden werden, dass er auch bei späteren Deployments und Composer-Installationen
nachvollziehbar erneut angewendet wird. Es handelt sich also nicht um eine versteckte manuelle Änderung auf dem
Produktivserver, sondern um eine dokumentierbare und reproduzierbare Anpassung.
Die vollständige technische Anleitung stellen wir im GitHub-Repository bereit. Die Anwendung sollte jedoch von einem
erfahrenen OXID-Dienstleister durchgeführt und zunächst auf einer Entwicklungs- oder Testumgebung geprüft werden.
Was der Patch leisten kann – und was nicht
Unser MySQL-8.0-Fix kann eine sinnvolle Übergangslösung sein, wenn der Hoster die Datenbank zeitnah umstellt und ein
vollständiges Update auf OXID eShop 7.5 bis dahin nicht mehr realistisch abgeschlossen werden kann.
Er behebt gezielt die uns bekannten Probleme von OXID eShop 6.5 mit den nicht mehr vorhandenen MySQL-Funktionen.
Der Patch macht aus einem älteren OXID eShop 6 jedoch kein vollständig modernisiertes Shopsystem.
Individuelle Entwicklungen und Drittanbietermodule können weitere Inkompatibilitäten enthalten. Auch Zahlungs-, ERP-,
Marktplatz-, Tracking- oder Exportmodule müssen separat getestet werden.
Besondere Aufmerksamkeit benötigen ältere Erweiterungen, deren Programmcode verschlüsselt ist. Bei solchen Modulen
kann die technische Funktionsweise häufig nicht direkt geprüft oder angepasst werden. Hier ist gegebenenfalls eine
Rücksprache mit dem jeweiligen Hersteller erforderlich.
Der Patch ist deshalb keine pauschale Garantie dafür, dass jedes individuelle OXID-eShop-6-Projekt vollständig unter
MySQL 8.0 funktioniert. Er löst ein konkretes und in realen Projekten nachgewiesenes Problem.
Drei mögliche Wege für Shopbetreiber
Grundsätzlich haben Betreiber eines betroffenen OXID eShop 6 drei Handlungsoptionen.
1. Direkt auf OXID eShop 7.5 aktualisieren
Das Update auf OXID eShop 7.5 ist die nachhaltige Lösung.
Die aktuelle OXID-Version ist für moderne Systemumgebungen ausgelegt und unterstützt laut offiziellen
Systemvoraussetzungen sowohl MySQL 8.0 als auch MySQL 8.4.
Ein solches Update benötigt allerdings ausreichend Vorlauf. Individuelle Module, Themes, Schnittstellen,
Zahlungsanbieter und projektspezifische Anpassungen müssen geprüft und gegebenenfalls aktualisiert oder ersetzt
werden.
Ist bis zur geplanten Datenbankumstellung genügend Zeit vorhanden, sollte dieser Weg bevorzugt werden.
2. Den Patch als zeitlich begrenzte Brücke einsetzen
Kann das Update auf OXID eShop 7.5 nicht mehr rechtzeitig abgeschlossen werden, kann unser Patch helfen, den
bestehenden Shop vorübergehend unter MySQL 8.0 weiterzubetreiben.
Damit lässt sich Zeit für ein kontrolliertes Updateprojekt gewinnen, ohne die anstehende Datenbankumstellung
vollständig zu blockieren.
Wichtig ist jedoch, den Patch nicht als dauerhafte Lösung zu betrachten. Er sollte mit einem konkreten Plan für die
Modernisierung des Shops verbunden werden.
3. Nichts unternehmen und auf einen störungsfreien Wechsel hoffen
Diese Variante birgt das größte Risiko.
Der Shop kann nach der Umstellung zunächst erreichbar sein und trotzdem später beim Speichern einer Einstellung, bei
einem automatisierten Prozess oder während des Checkouts ausfallen.
Ein solcher Fehler tritt dann nicht auf einer kontrollierten Testumgebung auf, sondern möglicherweise mitten im
laufenden Geschäftsbetrieb.
Die vermeintliche Kostenersparnis durch das Aufschieben der Prüfung kann dadurch schnell von Umsatzausfällen,
Supportaufwand und einer ungeplanten Notfallbehebung übertroffen werden.
Warum ein Update auf OXID eShop 7.5 trotzdem notwendig bleibt
MySQL 5.7 ist bereits veraltet. Die Umstellung auf MySQL 8.0 ist deshalb kein überraschender Sonderweg eines einzelnen
Hostinganbieters, sondern Teil einer allgemeinen technischen Entwicklung.
Gleichzeitig steht mit MySQL 8.4 bereits die nächste langfristig unterstützte Generation zur Verfügung. OXID eShop 7.5
unterstützt sowohl MySQL 8.0 als auch MySQL 8.4.
Das zeigt: Die aktuelle Umstellung wird nicht die letzte notwendige Modernisierung der technischen Infrastruktur sein.
Auch PHP, Betriebssysteme, Sicherheitsanforderungen, Zahlungsanbieter und Schnittstellen entwickeln sich weiter. Je
länger eine ältere Shopversion unverändert betrieben wird, desto größer wird die Abhängigkeit von veralteten
Komponenten und individuellen Sonderlösungen.
Der MySQL-8.0-Patch kann einen akuten Zeitdruck entschärfen. Er kann aber nicht verhindern, dass der technologische
Abstand weiter wächst.
Deshalb empfehlen wir, den Workaround ausschließlich als Übergangslösung zu betrachten und parallel das Update auf
OXID eShop 7.5 vorzubereiten.
Was vor der Umstellung geprüft werden sollte
Für Geschäftsführer und E-Commerce-Verantwortliche ist nicht entscheidend, jeden technischen Einzelschritt selbst zu
verstehen. Wichtig ist, dass die verantwortliche Agentur oder IT-Abteilung eine belastbare Prüfung durchführt.
Dabei sollten mindestens folgende Fragen beantwortet werden:
- Welche genaue OXID-Version wird aktuell eingesetzt?
- Welche MySQL-Version verwendet der Shop?
- Wann plant der Hostinganbieter die Umstellung?
- Wurde eine vollständige Kopie des Shops unter MySQL 8.0 getestet?
- Funktionieren Backend, Module und Theme-Einstellungen?
- Wurde der Checkout mit allen relevanten Zahlungsarten vollständig abgeschlossen?
- Sind Eigenentwicklungen und Drittanbietermodule berücksichtigt?
- Existieren ein vollständiges Datenbank-Backup und ein Server- oder Dateisystem-Snapshot?
- Wurden die bestehenden Konfigurationsdaten vor der Umstellung vorbereitet?
- Gibt es einen getesteten Rückfallplan, falls Probleme auftreten?
Bei mehreren Mandanten oder Subshops muss die Prüfung für jeden Shop separat erfolgen. Unterschiedliche Module, Themes
und Konfigurationen können dazu führen, dass der Hauptshop funktioniert, während ein Subshop bereits Fehler erzeugt.
Wichtiger Hinweis zur Nutzung unseres Patches
Wir stellen den KUSSIN | MySQL 8.0 Fix kostenfrei und ohne Gewährleistung zur Verfügung.
Vor der Anwendung müssen zwingend ein vollständiges Datenbank-Backup und möglichst auch ein Server- oder
Dateisystem-Snapshot erstellt werden.
Die Umstellung darf nicht erstmals ungeprüft auf dem Produktivsystem durchgeführt werden. Sie sollte zunächst auf
einer Entwicklungs- oder Stagingumgebung mit sämtlichen relevanten Shopfunktionen getestet werden.
Individuelle Erweiterungen können zusätzliche MySQL-8.0-Probleme enthalten, die nicht durch unseren Patch abgedeckt
werden.
Die Nutzung erfolgt auf eigenes Risiko. Eine Haftung für Datenverlust, Ausfallzeiten, fehlerhafte Konfigurationen,
entgangene Bestellungen oder sonstige unmittelbare und mittelbare Schäden wird ausgeschlossen.
Jetzt prüfen, bevor aus einem Update ein Notfall wird
Der Wechsel von MySQL 5.7 auf MySQL 8.0 ist grundsätzlich notwendig und aus Sicherheits- und Wartungssicht
nachvollziehbar.
Für einen weiterhin produktiv eingesetzten OXID eShop 6 kann diese Umstellung jedoch zum geschäftlichen Risiko werden,
wenn sie nicht vorbereitet und vollständig getestet wird.
Unser MySQL-8.0-Fix bietet betroffenen Shopbetreibern eine Möglichkeit, kurzfristig auf die anstehende Umstellung zu
reagieren. Er kann den notwendigen zeitlichen Spielraum schaffen, um anschließend ein strukturiertes Update auf OXID
eShop 7.5 umzusetzen.
Wir unterstützen Sie bei beiden Schritten:
Zunächst prüfen wir, ob Ihr OXID eShop 6 von dem konkreten MySQL-8.0-Problem betroffen ist und ob unser Patch als
Übergangslösung eingesetzt werden kann.
Anschließend bewerten wir gemeinsam, welche individuellen Module, Schnittstellen und Anpassungen bei einem Update auf
OXID eShop 7.5 berücksichtigt werden müssen.
Betreiben Sie noch einen OXID eShop 6 bei PROFIHOST oder einem anderen Hostinganbieter, der MySQL 5.7 abschaltet?
Dann sprechen Sie uns rechtzeitig an – möglichst bevor die Datenbank umgestellt wird und der erste Fehler im laufenden
Shopbetrieb auftritt.