OpenCart oder Laravel: Sie haben schon eine PHP-Anwendung

Vergleichsseiten werfen OpenCart meist mit gehosteten Plattformen in einen Topf und streiten dann über Kontrolle und Eigentum. Dieses Argument greift hier nicht. Sie haben die Kontrolle bereits. OpenCart ist PHP auf Ihrem Server, Ihre Datenbank, Ihre Dateien, keine Gebühr pro Bestellung, und niemand kann Ihnen die Bedingungen unter den Füßen wegziehen.

Die ehrliche Fassung der Frage ist deshalb enger: Sie haben eine PHP-Anwendung, und Sie fragen, ob sie noch die richtige ist für das, was das Geschäft inzwischen tut.

Was OpenCart wirklich gut kann

Das gehört gesagt, weil es meist fehlt.

Ein Katalog mit Optionen und Varianten, ein Warenkorb, ein Checkout, Steuer- und Versandregeln, ein Multi-Store-Setup, ein Backend, das ein kleines Team ohne Schulung bedient. Es läuft auf günstigem Hosting, es ist hunderttausendfach installiert, und der Erweiterungsmarkt deckt das meiste ab, wonach ein wachsender Shop fragt.

Wenn diese Beschreibung noch auf Ihren Shop passt: bleiben Sie. Einen funktionierenden Warenkorb durch eine Individualanwendung zu ersetzen, ist eine große Rechnung für ein Ergebnis, das für Ihre Kunden ähnlich aussieht.

Wo die Frage tatsächlich beginnt

Nicht beim Traffic und nicht beim Katalogumfang. Sie beginnt, wenn die Regeln, die Sie brauchen, aufhören, Katalogregeln zu sein.

Eine Erweiterung ist die natürliche Form für alles, wofür ein Warenkorb schon einen Begriff hat: eine Preisregel, eine Versandart, ein Zahlungsanbieter, ein Feld am Produkt. Dafür ist das Erweiterungsmodell da, und es funktioniert.

Die Form ändert sich, wenn die Regel etwas anderes betrifft. Ein Angebot, das nach Freigabe zur Bestellung wird. Ein Fulfilment-Prozess mit Zuständen, durch die Mitarbeitende Vorgänge schieben. Kundenspezifische Vertragspreise mit eigener Historie. Bestand, der im ERP liegt und mit ihm übereinstimmen muss. Abonnements und anteilige Berechnung.

Nichts davon wurde je von einem Warenkorb gehalten, und jedes davon als Erweiterung gebaut muss in Teile des Systems greifen, die nicht dafür gedacht sind. Dort beginnen die Kosten, und es sind Kosten der Passung, nicht eines Fehlers.

Die Frage der Modifikationen, ehrlich

Vor allem anderen lohnt es sich zu messen, wie weit Ihre Installation von einer Standardinstallation abweicht.

OpenCarts Erweiterungsmodell erlaubte es Erweiterungen historisch, das Kernverhalten direkt zu verändern. Das machte es flexibel und leicht erweiterbar, und es ist auch der Grund, warum zwei Shops auf derselben Version in sehr unterschiedlichem Zustand sein können. Manche sind nah am Standard und lassen sich sauber aktualisieren. Manche tragen ein Jahrzehnt Modifikationen, mehrere davon an denselben Dateien, installiert von Leuten, die nicht mehr erreichbar sind.

Lesen Sie das, bevor Sie irgendetwas entscheiden. Es ist ein Tag Arbeit und es ändert die Rechnung vollständig, denn ein Shop, der sauber aktualisiert, hat eine günstige Option, die ein stark modifizierter nicht hat. Es ist dieselbe Lektüre, die ein Audit macht, nur an einer anderen Codebasis.

Was eine Laravel-Anwendung ändert und was nicht

Sie ändert, wo die Regeln leben. Eine Service-Schicht, ein Schema mit Constraints, Migrationen, eine Testsuite und eine Queue für die Arbeit, die nicht im Request passieren sollte. Wenn die Geschäftslogik das Produkt ist, ist genau dafür das Framework da.

Sie verbessert Ihre Hosting-Situation nicht von allein, und sie schenkt Ihnen keinen Katalog, keinen Warenkorb und keinen Checkout. Die bauen Sie neu. Das sind die ehrlichen Kosten und der Grund, warum wir zuerst fragen, ob das Passungsproblem echt ist oder ob zwei Erweiterungen etwas Ungeschicktes tun.

Wie ein Umzug tatsächlich läuft

Route für Route, mit beiden Systemen live, was der Ansatz ist und nicht die Ausnahme.

OpenCart liefert den Storefront weiter aus, während die neue Anwendung gruppenweise Routen übernimmt. Zu jedem Zeitpunkt besitzt ein System die Bestellung, und welches das ist, wird aufgeschrieben, bevor etwas umzieht. Die URL-Zuordnung kommt zuerst, denn Kategorie- und Produkt-URLs haben Ihren Traffic verdient, und eine Weiterleitung, die in der letzten Woche geschrieben wird, ist zu spät geschrieben.

Und das Bestellmodell kommt vor dem Storefront. Der Storefront ist der Teil, der sich später am billigsten ändern lässt.

Liegt der Shop auf einer gemieteten Plattform statt auf Ihrem eigenen Server, wird das Eigentumsargument, das hier nicht greift, zum ganzen Argument - und dafür gibt es eine eigene Seite.