Von OpenCart zu einem eigenen Shop wechseln

Was OpenCart ist, und wer es entwächst

OpenCart ist ein kostenloser, quelloffener Shop, in PHP geschrieben und von dir selbst gehostet. Du lädst ihn herunter, legst ihn auf deinen eigenen Server, verbindest ihn mit einer MySQL oder MariaDB Datenbank, und ab da gehört er dir.¹ Er steht unter Version 3 der GNU General Public License, es gibt also keine Lizenzgebühr und keine Umsatzbeteiligung, und der Quellcode liegt offen, damit du oder jede Entwicklerin ihn lesen und ändern kann.² Für einen schlanken Shop ist das eine starke Ausgangslage, und ich sage es offen: Wenn dein OpenCart Shop klein, stabil und günstig im Betrieb ist, solltest du vermutlich draufbleiben. Für dich ist dieser Artikel nicht.

Er ist für den Shop, der OpenCart entwachsen ist. Das Muster ist immer dasselbe. Der Katalog wuchs, das Gewerbegeschäft wuchs, und aus dem Shop wurde ein Turm aus bezahlten Erweiterungen, die alle miteinander können müssen. Jede einzelne will ihre Lizenz erneuert haben. Eine neue Hauptversion ist draußen, das Theme wurde für die alte Version gekauft und läuft auf der neuen nicht, und die Hälfte der Erweiterungsautoren hat ihre Arbeit nicht aktualisiert oder will erneut bezahlt werden. Irgendwo im Shop hat ein Entwickler, der vor zwei Jahren ging, eine wichtige Regel in einer Modifikationsdatei versteckt, und niemand weiß genau, was sie tut. Der Shop läuft noch, aber etwas zu ändern fühlt sich an wie eine Bombe zu entschärfen.

Wenn du dort stehst, lautet die gute Nachricht: OpenCart gehört zu den einfacheren Plattformen, die man verlassen kann, weil dir die Daten bereits gehören. Der harte Teil ist nicht der Export. Es ist das Entwirren dessen, was die Erweiterungen und Modifikationen wirklich getan haben, und der Wiederaufbau als eine einzige, dir gehörende, getestete Anwendung. Diese Anwendung baue ich auf Solidus, einem quelloffenen Shop Framework auf Ruby on Rails, und ich begleite den Umzug. Das Ergebnis gehört dir. Dieser Artikel ist die ehrliche Form dieses Umzugs, erzählt speziell für OpenCart. Für die tiefe, plattformunabhängige Erklärung, wie jede Datenart reist, verlinke ich auf die Leitfäden, denen sie gehört, statt sie hier zu wiederholen, beginnend mit der Säule, was sich überträgt und was nicht.

Was dir gehört, und was eingesperrt ist

Weil OpenCart selbst gehostet ist, spricht die wichtigste Tatsache beim Verlassen für dich: Die Datenbank gehört dir. Alles, was der Shop weiß, liegt in Tabellen, die du direkt lesen kannst, mit einem Präfix wie oc_ vor Namen wie oc_product, oc_customer, oc_order und oc_seo_url. Ein einfacher Datenbankauszug mit mysqldump liefert dir alles, und von dort ist die Zuordnung in ein neues Modell gewöhnliche, sorgfältige Arbeit statt eines Kampfes um Zugang. Vergleiche das mit einer gehosteten Plattform, wo du nur die Exporte bekommst, die der Anbieter dir geben will, und du siehst, warum quelloffene Shops freundlicher zu verlassen sind.

Eingesperrt sind also nicht die Daten. Es ist das Verhalten rund um die Daten: die Zahlungs und Versandlogik, die jede Erweiterung auf ihre eigene Art hält, die Geschäftsregeln, die in Modifikationen versteckt sind, das Theme, das für eine Version von OpenCart geschrieben wurde, und die Anbindungen, die genau an diese Installation verdrahtet sind. Nichts davon reist mit. Es muss verstanden und neu gebaut werden. Die folgende Tabelle ist die ehrliche Aufteilung.

Was	Wie es reist	Wohin es geht
Produkte, Varianten, Optionen, Attribute, Preise, Bilder, Kategorien, Lagerstand	Sauber, über direkten Datenbankzugriff oder das Exportwerkzeug, als Zuordnungsarbeit	Das Solidus Produktmodell, siehe Produkt und Katalogdaten
Kundenkonten und Adressen	Sauber, aber Passwörter sind gehasht und nicht wiederverwendbar	Neu aufgebaut mit einem Reset oder einer Prüfung beim ersten Login, siehe Kundenkonten
Bestell und Kaufhistorie	Als Datensätze, zur Ansicht und für den Kundenservice	Eine nur lesbare Historie im neuen Shop
SEO Schlüsselwörter und URLs	Als Liste zum Zuordnen, nicht zum Kopieren	Eine Weiterleitungstabelle im neuen Shop
Zahlungskonfiguration und gespeicherte Karten	Nicht portabel, jede Erweiterung speichert sie anders	Neu aufgebaut rund um dein eigenes Gatewaykonto, siehe Zahlungstoken
Theme, Modifikationen und Anbindungen	Reisen gar nicht mit	Neu gebaut als eigener, getesteter Code

Export und API, wie es wirklich ist

OpenCart gibt dir drei ehrliche Wege, deine Daten herauszuholen, und es lohnt sich, genau zu sein, was jeder ist, denn das Marketing rund um Migrationswerkzeuge verwischt sie.

Der erste ist der direkte Datenbankzugriff, und er ist der stärkste. Dir gehören der Server und die Datenbank, ein vollständiger Auszug steht dir also immer offen. Für einen großen Katalog oder eine komplexe Bestelltabelle ist das der Weg, den ich tatsächlich nehme, weil nichts verborgen und nichts wegsummiert ist.

Der zweite ist das Export und Importwerkzeug. Viele glauben, das stecke in OpenCart. Tut es nicht. Das weit verbreitete Export/Import Tool ist eine Community Erweiterung, für das Projekt gepflegt und über den OpenCart Marktplatz verteilt, und du installierst es selbst.³ Es leistet echte Arbeit: einen Massenexport von Kategorien, Produkten, Optionen, Attributen, Filtern und Kunden in eine Tabelle, die du offline bearbeiten und wieder einlesen kannst. Der Import läuft in zwei Modi, einer fügt gegen den Bestand hinzu und aktualisiert, der andere löscht erst alle alten Daten und ersetzt sie. Zwei Vorbehalte zählen. Der Speicherbedarf ist hoch, und auf einfachem geteiltem Hosting rät der Autor, nicht mehr als ein paar tausend Produkte auf einmal zu exportieren und in Chargen zu arbeiten.³ Und die Tabelle ist eine Bequemlichkeitsschicht, nicht die ganze Wahrheit: Was ein eigenes Feld oder eine Erweiterung außerhalb der Standardtabellen gespeichert hat, steht nicht darin. Für einen Shop jeder Größe behandle ich die Tabelle als Ausgangspunkt und gleiche sie gegen die Datenbank ab.

Der dritte ist die API, und hier müssen die Erwartungen gedämpft werden. OpenCart hat eine eingebaute API, die du bei den Systembenutzern einrichtest, indem du eine Zugangskennung mit Benutzernamen, erzeugtem Schlüssel und einer Liste erlaubter IP Adressen anlegst und ein oder ausschaltest.⁴ Was die Dokumentation beschreibt, ist eine Schnittstelle, damit vertrauenswürdige Anwendungen mit deinem Shop sprechen, mit einer Aufrufhistorie, nicht eine vollständige Leseschnittstelle über deinen ganzen Katalog. Es gibt keinen dokumentierten Endpunkt, der dir einfach jedes Produkt, jeden Kunden und jede Bestellung auflistet. Die eingebaute API wurde rund um Warenkorb und Bestellvorgänge für den Shop und Begleitapps gebaut, und eine echte REST Schnittstelle über die Daten bedeutet in der Regel eine weitere Erweiterung. OpenCart selbst setzt bei der eingebauten API kein veröffentlichtes Ratenlimit, jede Grenze, an die du stößt, ist die deines Hosters, nicht die der Plattform.⁴ Die praktische Schlussfolgerung ist einfach: Bei OpenCart migrierst du aus der Datenbank, und die API ist Nebendarsteller, nicht Hauptrolle.

Passwörter ziehen nie um, und das ist gut so

Kein Passwort kommt in lesbarer Form herüber, nicht aus OpenCart und aus keiner vernünftigen Plattform, denn OpenCart speichert das Passwort selbst nie. Die aktuelle Version hasht jedes Passwort mit PHPs eigener Funktion password_hash und dem Standardalgorithmus, der heute bcrypt ist, und schreibt nur diesen Hash.⁵ Ältere OpenCart Installationen nutzten stattdessen ein gesalzenes, mehrfach gehashtes SHA1 Verfahren, mit einem kurzen Zufallssalz neben dem Hash.⁶ So oder so ist der gespeicherte Wert einseitig. Er lässt sich nicht in das Passwort zurückrechnen, es gibt also nichts zum Mitnehmen, womit sich eine Kundin anmelden könnte.

Das ist ein Vorteil, kein Verlust, und der Plan dahinter ist derselbe, den der Leitfaden zu Kundenkonten vollständig beschreibt. Jedes Konto, mit Namen, Adressen und Bestellhistorie, wird im neuen Shop angelegt. Beim ersten Besuch setzt die Kundin entweder über einen Einmallink ein neues Passwort oder, wenn du die alten Hashes behältst, wird der alte Hash einmal geprüft und danach still durch das Format des neuen Shops ersetzt, ohne dass sie etwas merkt. Was auch immer du wählst, niemand sieht je ein Passwort im Klartext, und das Konto, das die Kundin wieder aufbaut, hängt an ihrer gesamten Historie.

Der Turm aus Erweiterungen ist der eigentliche Grund zu gehen

Fast niemand verlässt OpenCart, weil die Daten gefangen sind. Man geht wegen dessen, was obendrauf sitzt. Ein funktionierender OpenCart Shop mit Anspruch ist selten reines OpenCart. Es ist reines OpenCart plus zwanzig oder dreißig bezahlte Erweiterungen: eine bessere Suche, abgestufte Filter, ein Modul für Gewerbepreise, Mails für abgebrochene Warenkörbe, ein Bewertungssystem, ein Retourenportal, eine Anbindung an die Buchhaltung, ein Feed für Marktplätze und ein oder zwei Zahlungserweiterungen. Jede ist ein eigener Kauf von einem eigenen Autor, mit eigenem Veröffentlichungsrhythmus und eigener Qualität. Sie müssen zusammenspielen, und sie müssen jedes Mal weiter zusammenspielen, wenn eine von ihnen aktualisiert. Sind sie uneins, bricht der Shop auf schwer auffindbare Weise, denn der Fehler liegt im Raum zwischen zwei Erweiterungen, den kein Autor besitzt.

Obendrauf sitzt die Upgradefrage, die bei OpenCart schärfer ist als bei den meisten Plattformen. Der Sprung zwischen Hauptversionen, von der 1.5 Reihe zu 2, von 2 zu 3, von 3 zu 4, ist weniger ein Upgrade als ein Neubau. Themes sind gegen eine bestimmte Version und ihr Vorlagensystem geschrieben, ein Theme für eine Reihe läuft also nicht einfach auf der nächsten. Erweiterungen müssen von ihren Autoren für die neue Version neu herausgegeben werden, und viele werden das nie, oder nur gegen erneute Bezahlung. Ein Shop, der aktuell bleiben will, steht also alle paar Jahre vor einem Projekt, das fast so viel kostet wie ein frischer Aufbau und dafür nichts Neues zu zeigen hat. Das ist die Tretmühle. Mein Argument für einen eigenen Solidus Shop ist nicht, dass Rails gerade modern ist. Es ist, dass du einen Turm aus fremden Erweiterungen, jede eine Abhängigkeit, die du nicht steuerst, durch eine einzige Anwendung ersetzt, die dir gehört, die mit Tests beweist, dass sie sich richtig verhält, und die eine Entwicklerin, die sie kennt, pflegen und erweitern kann, ohne irgendwen um Erlaubnis zu fragen.

Modifikationen verstecken deine Geschäftslogik

OpenCart hat ein geschicktes System, um das Verhalten des Shops zu ändern, ohne die Kerndateien zu bearbeiten, genannt OCMOD, mit einem älteren Vorfahren eines Drittanbieters namens vQmod, den viele Shops noch mitschleppen. Eine Modifikation ist eine XML Anweisung, die im Kern sagt: Finde diese Zeile in jener Datei und ändere sie, und das System wendet die Änderung zur Laufzeit auf eine Kopie an, das Original bleibt unberührt.⁷ Das ist eine sinnvolle Idee, und es ist zugleich der Ort, an dem sich Geschäftslogik versteckt.

Die Falle ist, dass über die Jahre die echten Regeln deines Shops in diese Modifikationsdateien wandern. Wie Gewerbekunden bepreist werden, die eigenartige Rundung, auf der dein Buchhalter besteht, das Zusatzfeld auf der Bestellung, die Art, wie das Etikett eines bestimmten Transporteurs erzeugt wird: Ein Entwickler, oft längst weg, löste jedes davon mit einer kleinen Modifikation, und das Wissen ging mit ihm. Beim Umzug sind diese Dateien das Wertvollste und zugleich Gefährlichste zu verstehen, denn sie sind der Unterschied zwischen dem Shop, den du zu haben glaubst, und dem Shop, den du wirklich hast. Die erste ernste Aufgabe in jeder OpenCart Migration, die ich begleite, ist, jede Modifikation zu lesen und in klaren Worten aufzuschreiben, was jede wirklich tut. Dieses Dokument, nicht der Datenexport, ist meist der Ort, an dem die Überraschungen liegen.

SEO URLs und die Weiterleitungsliste

OpenCart bildet die Adresse einer Seite auf zwei Arten. Von Haus aus nutzt es Abfragezeichenfolgen, ein Produkt liegt also unter so etwas wie index.php?route=product/product&product_id=42. Mit eingeschalteten SEO URLs bekommt stattdessen jedes Produkt, jede Kategorie und jede Informationsseite ein Schlüsselwort, das im ganzen Shop eindeutig sein muss, und der Server wird so eingerichtet, dass er die freundliche Adresse auf die echte Route umschreibt.⁸ Diese Schlüsselwörter sind die URLs, die sich deine Kunden gemerkt haben und die Suchmaschinen indexiert haben, und wenn du den Shop seit Jahren führst, tragen sie echtes Ranking.

Der Umzug in einen neuen Shop ist der Moment, in dem dieser Wert am häufigsten weggeworfen wird, und das hat nichts mit OpenCart im Besonderen zu tun und alles mit Disziplin. Jede Adresse, die im letzten Jahr einen Besuch oder einen Link bekam, muss mit einer dauerhaften Weiterleitung ihrem neuen Zuhause zugeordnet werden, und die Weiterleitung muss direkt auf die Zielseite zeigen, nicht über eine Kette. Die ganze Methode, und warum der meiste Rankingverlust bei einer Migration von verpassten Weiterleitungen kommt und nicht vom Umzug selbst, steht im Leitfaden zu Produkt und Katalogdaten. Bei OpenCart ist der eine plattformspezifische Hinweis, dass deine Schlüsselwortliste in einer Datenbanktabelle liegt, die du direkt lesen kannst, der erste Entwurf der Weiterleitungsliste ist also eine Abfrage, kein Crawl. In den Shops, die ich baue, leben die Weiterleitungen in der Anwendung selbst als bearbeitbare Tabelle, sie überstehen also jedes künftige Deploy, und dein eigenes Team kann eine ergänzen, wenn ihm eine Lücke auffällt.

Zahlungen und gespeicherte Karten

Zahlungen sind der Punkt, an dem ein OpenCart Umzug aufhört, ordentlich zu sein. In OpenCart ist jedes Gateway eine eigene Zahlungserweiterung, und jede speichert ihre Konfiguration und jeden Verweis auf eine gespeicherte Karte auf ihre eigene Art. Es gibt keinen einzigen, portablen Zahlungstresor zum Übergeben. Was wirklich zählt, ist, wer die Kartendaten hält, und die Antwort ist nie OpenCart: Es ist dein Zahlungsanbieter. Bucht dein Shop Karten bereits über dein eigenes Konto bei Stripe oder einem ähnlichen Anbieter, gehören die gespeicherten Karten diesem Konto, und der neue Solidus Shop kann sich mit demselben Konto verbinden, sodass die Karten einfach dort bleiben und nichts verloren geht. Sitzen die Karten dagegen in einem Anbieter, den du nur über eine OpenCart Erweiterung erreicht hast, bedeutet ein Umzug eine Übertragung von Anbieter zu Anbieter, die der empfangende Abwickler nur von einem anderen Inhaber mit Zertifizierung auf der höchsten Stufe des Kartensicherheitsstandards annimmt, und die niemals die Abonnements oder die Zahlungshistorie mitbringt.

Das ist das Wichtigste, das zuerst zu klären ist, nicht zuletzt, und der Leitfaden zu Zahlungstoken geht jeden Fall durch. Wenn du aus diesem Abschnitt nur eines mitnimmst, dann dies: Entscheide deinen Zahlungsanbieter, bevor du eine Zeile des neuen Shops schreibst, denn diese eine Entscheidung bestimmt, ob wiederkehrende Kunden ihre gespeicherten Karten behalten oder sie neu eingeben müssen. Macht dich das Thema nervös, ist die warnende Geschichte vom Wechsel des Payment Gateways die passende Lektüre.

Abonnements und wiederkehrende Zahlungen

Verkauft dein OpenCart Shop irgendetwas auf wiederkehrender Basis, behandle es als den härtesten Teil des ganzen Umzugs und bring es am ersten Tag auf den Tisch. OpenCart kann wiederkehrende Produkte abbilden, doch das eigentliche Abbuchen hängt davon ab, dass die jeweilige Zahlungserweiterung es unterstützt, und das Mandat, mit dem du eine Kundin erneut belasten darfst, liegt beim Gateway, nicht in OpenCart. Ein laufendes Abonnement lässt sich also nicht einfach als Datenzeile exportieren und im neuen Shop nachspielen. Ob es überhaupt umziehen kann, hängt von deinem Gateway ab und braucht oft dessen Mitwirkung, und manchmal ist die ehrliche Antwort, dass bestehende Abonnenten neu zustimmen müssen. Der Leitfaden zu Abonnements legt die Möglichkeiten und die Fragen an deinen Anbieter dar. Die Regel ist dieselbe wie bei Karten: zuerst ansprechen, denn die Antwort formt alles andere.

Ein Beispiel

Mach ich es konkret an einem erfundenen Shop. Donau Werkzeug (donauwerkzeug.example) ist ein Linzer Betrieb, der Schuhe, Arbeitskleidung und Schutzausrüstung verkauft, mit einem wachsenden Gewerbegeschäft, das Baufirmen auf Rechnung beliefert. Es setzt online rund 1,4 Millionen € um, führt etwa 6.000 Produkte, sobald Größen und Farben gezählt sind, und ist seit fünf Jahren auf OpenCart 3. In dieser Zeit hat es 22 bezahlte Erweiterungen gekauft und ein Dutzend Modifikationen angesammelt. Die Gewerbepreise, die Art, wie Rechnungskunden Preise ohne Mehrwertsteuer sehen, und ein eigenes Feld auf Bestellungen für die Baustelle, an die geliefert wird, laufen alle über Modifikationen eines Entwicklers, der weitergezogen ist.

Das Problem der Inhaberin ist nicht, dass der Shop kaputt ist. Es ist, dass er furchteinflößend geworden ist, um ihn anzufassen. OpenCart 4 ist draußen, das Theme wurde für 3 gekauft und der Autor hat es nicht neu herausgegeben, vier der Erweiterungen sind verwaist, und der Kostenvoranschlag, alles auf der neuen Version zum Laufen zu bringen, liegt nahe an den Kosten eines Neuanfangs, für keine neue Fähigkeit. Sie hat entschieden, keine fremden Erweiterungen mehr zu mieten und stattdessen den Shop zu besitzen.

So läuft der Umzug. Der saubere Teil kommt zuerst und beruhigt alle: ein vollständiger Datenbankauszug, und daraus werden die 6.000 Produkte mit Größen, Farben, Preisen, Lagerstand und Bildern in ein paar Wochen sorgfältigen Abgleichs auf den Solidus Katalog abgebildet. Die Kundendatensätze, einschließlich der Gewerbekonten, kommen mit Adressen und Bestellhistorie herüber, Passwörter ausgenommen. Die Bestellhistorie wird als nur lesbare Referenz eingebracht, drei Jahre tief, die älteren Datensätze bleiben im archivierten Export. Die SEO Schlüsselwörter werden direkt aus der Datenbank in den ersten Entwurf der Weiterleitungsliste gelesen, rund 7.000 Zeilen, die dann eine Person prüft.

Dann die harten Teile, die in Woche eins angesprochen wurden, nicht in Woche zehn. Die Gewerbepreise und die Anzeige ohne Mehrwertsteuer, gefunden beim Lesen der Modifikationen, werden echte, getestete Funktionen des neuen Shops statt Flicken. Das Bestellfeld für die Baustelle wird sauber neu gebaut. Zahlungen sind der Angelpunkt: Der Shop nutzt bereits sein eigenes Stripe Konto, der neue Solidus Shop verbindet sich also mit demselben Konto, und die gespeicherten Karten der Gewerbekunden bleiben gültig, was den beängstigendsten Teil zum einfachsten macht. Es gibt keine Abonnements, diese Frage ist also rasch geschlossen. Vierzehn Wochen nach dem ersten Workshop stellt Donau Werkzeug an einem ruhigen Dienstagvormittag um, lässt die alte OpenCart Installation dreißig Tage unberührt als Rückfalloption laufen und kündigt sie erst danach. Ein Jahr später ist der Shop eine gepflegte Anwendung mit Tests, ohne Erweiterungsverlängerungen, und die Gewerberegeln sind dort aufgeschrieben, wo die nächste Person sie lesen kann.

Der ehrliche Umzugsplan

Auf das Nötigste gebracht, läuft der Weg von OpenCart zu einem eigenen Solidus Shop so. Erstens die Erhebung: jede Modifikation lesen und aufschreiben, was sie tut, die Erweiterungen auflisten und wofür jede wirklich da ist, den Zahlungsanbieter wählen und die eine Person im Betrieb benennen, der die Daten gehören. Zweitens der Bau: den Solidus Shop aufstellen, die Importskripte schreiben und sie wieder und wieder gegen eine Kopie der echten Datenbank laufen lassen, bis der Import langweilig ist. Drittens Katalog und Kunden zuordnen und die versteckte Modifikationslogik in getestete Funktionen verwandeln. Viertens die Weiterleitungsliste aus der Schlüsselworttabelle bauen und jede Zeile prüfen. Fünftens ein Parallelbetrieb von einigen Wochen mit eingefrorenem Katalog, der finale Import zweimal geprobt. Sechstens an einem ruhigen Werktagvormittag umstellen, eine echte Testbestellung auf jeder Zahlungsart aufgeben, die wichtigsten Weiterleitungen von Hand prüfen und den alten Shop dreißig Tage als Rückfalloption behalten, bevor irgendetwas gekündigt wird.

Durch alles hindurch gilt das Prinzip aus der Säule: Zieh den Shop um, wie er ist, mach ihn stabil, und verbessere erst dann. Aus einer Migration zugleich eine Neugestaltung zu machen, verdoppelt das Risiko und macht es unmöglich zu sagen, welche Änderung einen Einbruch verursacht hat.

Wann du auf OpenCart bleiben solltest

Mir ist lieber, ich verliere die Arbeit, als dir einen Umzug zu verkaufen, den du nicht brauchst, hier also, wann du bleiben solltest. Bleib, wenn dein OpenCart Shop klein ist, die Erweiterungen, auf die du angewiesen bist, wenige und gut gepflegt sind und die Rechnung tragbar ist. Bleib, wenn dich nichts wirklich blockiert und die einzige Klage ein vages Gefühl ist, die Software sei alt. Bleib, wenn du die Person im Betrieb nicht benennen kannst, die die Daten, die Gewerberegeln und den Grund für die Endungen an den alten Produktcodes versteht, denn ohne diese Person bringt jede Migration, auf jede Plattform, einen schönen neuen Shop voller falscher Daten.

Zieh um, wenn der Turm aus Erweiterungen zur Steuer und zum Risiko geworden ist, wenn das nächste Upgrade der Hauptversion so viel kostet wie ein frischer Start für nichts Neues, wenn die Regeln, die dein Geschäft steuern, in Modifikationen gefangen sind, die niemand lesen kann, und wenn du einen Shop willst, der dir gehört und ordentlich getestet werden kann. Für die Geldseite dieser Entscheidung rechnet die Gesamtkosten über fünf Jahre die Zahlen durch, der Plattformvergleich stellt OpenCart neben die Alternativen, und wem deine Geschäftsdaten eigentlich gehören ist das Prinzip darunter. Wägst du im selben Atemzug andere quelloffene Shops ab, habe ich denselben ehrlichen Leitfaden für den Abschied von WooCommerce und für den Abschied von PrestaShop geschrieben. Solidus selbst ist quelloffen unter der BSD Lizenz, der Shop, den ich dir baue, trägt also keine Lizenzgebühr und keine eigene Abhängigkeit.⁹

Der Workshop

Wenn du einen OpenCart Shop führst und nicht sicher bist, ob du ihm entwachsen bist, bring ihn in einen kostenlosen Workshop, und die ersten zwei Wochen Arbeit gehen auf mich. Bring deine Erweiterungsliste, deine Verlängerungsrechnungen und alles, was du über die Modifikationen weißt. Gemeinsam lesen wir, was der Shop wirklich tut, klären, was sauber umzieht und was neu gebaut werden muss, bringen die Fragen zu Zahlung und Abonnement zuerst auf den Tisch, und ich sage dir ehrlich, ob sich ein Umzug für dich rechnet. Manchmal tut er das nicht, und dann sage ich das auch.

Footnotes

1. OpenCart Dokumentation, System Requirements (PHP 8.0 oder neuer, benötigte PHP Bibliotheken, MySQL oder MariaDB über den MySQLi oder PDO Treiber, PostgreSQL, Apache empfohlen), geprüft am 14. November 2026, https://docs.opencart.com/getting-started/system-requirements ↩

2. OpenCart Quellcode Repository, lizenziert unter der GNU General Public License Version 3, GitHub, geprüft am 14. November 2026, https://github.com/opencart/opencart ↩

3. OpenCart Marktplatz, Export/Import Tool (eine von der Community gepflegte Erweiterung von JNeuhoff, Massenexport und Import von Kategorien, Produkten, Optionen, Attributen, Filtern und Kunden in eine Tabelle, Import additiv oder als vollständiger Ersatz, hoher Speicherbedarf, ein paar tausend Produkte je Charge auf einfachem geteiltem Hosting), geprüft am 14. November 2026, https://www.opencart.com/index.php?route=marketplace/extension/info&extension_id=17 ↩ ↩²

4. OpenCart Dokumentation, System users API (Zugangskennung mit Benutzernamen, erzeugtem Schlüssel, Liste erlaubter IP Adressen, Status und einer Aufrufhistorie; für vertrauenswürdigen Anwendungszugriff gebaut, nicht als vollständige Leseschnittstelle über den Katalog dokumentiert; kein von der Plattform gesetztes Ratenlimit angegeben), geprüft am 14. November 2026, https://docs.opencart.com/admin-interface/system/users/api ↩ ↩²

5. OpenCart Quellcode, catalog/model/account/customer.php (Kundenpasswörter gehasht mit PHP password_hash und PASSWORD_DEFAULT), GitHub master Branch, geprüft am 14. November 2026, https://github.com/opencart/opencart/blob/master/upload/catalog/model/account/customer.php ↩

6. OpenCart Issue 1269, das ältere Passwortverfahren nutzte ein kurzes Zufallssalz mit mehrfach angewandtem SHA1, GitHub, geprüft am 14. November 2026, https://github.com/opencart/opencart/issues/1269 ↩

7. OpenCart Wiki, Modification System (OCMOD ändert einen Shop über XML Anweisungen, die auf Kopien der Kerndateien angewandt werden, die Originale bleiben unberührt), GitHub, geprüft am 14. November 2026, https://github.com/opencart/opencart/wiki/Modification-System ↩

8. OpenCart Dokumentation, SEO URL (standardmäßig routenbasierte Adressen wie index.php?route=product/product, ersetzt durch ein eindeutiges Schlüsselwort je Produkt, Kategorie und Informationsseite, mit serverseitigem Umschreiben, sonst liefern freundliche URLs 404), geprüft am 14. November 2026, https://docs.opencart.com/design/seo-url ↩

9. Solidus Quellcode Repository, das Solidus Ecommerce Framework unter der BSD 3 clause Lizenz, GitHub, geprüft am 14. November 2026, https://github.com/solidusio/solidus ↩