Diskussion rund um den OXID eShop

Deutsches Forum
81

[QUOTE=bluesmaker;74764]Es geht um Installationen und Updates. Ich steh auch Modulbauweise und automatisieren Installationen. Weil es zwei Vorteile vereint: Man kann mit einem Klick ein neues Modul installieren ohne tief ins System einzugreifen und man hat die Releasefähigkeit des Systems erhalten. Man kann also auch ein Update mit wenigen Klicks erledigen. [/QUOTE]
Das einzige Shopsystem. das m.E. derzeit diesem Ideal nahe kommt, ist Shopware…

Obwohl es da auch immer mal wieder klemmt…

Für den automatisierten Moduleinbau gibt es ja schon 2 Lösungen hier im Forum…

Und mit der neuen Template-Blockvererbung kann man jetzt auch das Thema “automatische Template-Anpassung” angehen.

Ist halt alles nicht so einfach…

Aber gerade die kleinen Firmen sind aus ihrer osCommerce/xtCommerce-Erfahrung noch sehr viel mehr Kummer gewöhnt…

Demgegenüber ist OXID schon weit, weit, weit fortgeschritten…

82

[QUOTE=bluesmaker;74764]Es geht um Installationen und Updates. Ich steh auch Modulbauweise und automatisieren Installationen. Weil es zwei Vorteile vereint: Man kann mit einem Klick ein neues Modul installieren ohne tief ins System einzugreifen und man hat die Releasefähigkeit des Systems erhalten. Man kann also auch ein Update mit wenigen Klicks erledigen. [/QUOTE]
Falls eine Modulinstallation vollautomatisch ablaufen soll, muss sie sich an zwei Orten verankern: zum Einen im Core-Bereich des Shops mit den ganzen php-Dateien, und zum Anderen im Template-Bereich.

Die Installation im Core-Bereich, d.h. im Module-Ordner, ist meistens ein Klacks. Reinkopieren, vielleicht noch ein sql-Skript, fertig.

Die Installation im Templatebereich kann dagegen nur ein Klacks sein, wenn die zu ändernden Templates noch dem Auslieferungszustand des Shops entsprechen. Das ist aber nahezu nie der Fall, da sie meistens bereits manuell angepasst worden sind. Von daher ist es kaum machbar, dass eine Modulinstallation vollautomatisch auch den Templatebereich updaten kann, falls sie nicht komplett neue, unabhängige Templates mitbringt. Das ist aber selten der Fall; meistens werden Zusatzfunktionalitäten in bestehende Templates integriert.

Und diese Problematik existiert natürlich auch für ein normales Shopupdate.

83

oh es gibt viele die schlechter sind!!! ohne jetzt ein Liebeslied zu singen

84

Moin,

ich habe vor wenigen Tagen den Weg zu oxid gefunden, weil mir das alte shopsystem einfach ein paar mal einen Blutsturz gebracht hat. Wenn man über 2500 Euro Netto in einen Shop steckt - und nach einem wichtigen Update keine Bestellungen mehr editieren kann, bis man ein Modul für 150 Netto gekauft hat - dann hört es einfach auf. Man muß dort für !grundlegenste! Sachen im Shop viel viel Geld ausgeben, damit man überhaupt arbeiten kann. Im Forum des Anbieters gibts aber als Ausgleich noch etwas viel tolleres… Wenn man dort Sachen schreibt, die unangenehm sind, wundert man sich, warum niemand darauf eingeht. Zumindest bis man mal nicht eingeloggt ist - und mitbekommt, dass das Posting weg ist. Einloggen: Oh, da ist es ja!
Kurzum: Eine sehr bedenkenswerte Form der Zensur. Man denkt es ist da - angezeigt wird es aber nur dem Autor.
Das und vieles vieles mehr hat mich einfach davon abgebracht weiter Geld in den Laden zu stecken.

Mal ganz im Ernst: Für 30 Euro Netto kann man eine Domainänderung kaufen, Wenn Du also Interesse hast - ich mache dir einen guten Preis für die tolle Software vom Marktführer! Aber wehe Du schreibst dann da: “Das ist ja noch schlechter als das, was ich zuletzt probiert habe…”

greets, Nik

85

salut,

@Niktator
>>Wenn man über 2500 Euro Netto in einen Shop steckt
du hättest auch in Ruhe die CE testen können, anstatt hier zu meckern!

>> keine Bestellungen mehr editieren kann, bis man ein Modul für 150 Netto gekauft hat
Und was für ein Modul?
Bestellung lassen sich doch bearbeiten??

ceau

86

…ich hoffe er sprach von seinem Vorgänger-System, irgendwie kann ich die genannten Probleme nicht mit Oxid in Verbindung bringen.

87

[QUOTE=Niktator;74850]Moin,

ich habe vor wenigen Tagen den Weg zu oxid gefunden,[B] weil mir das alte shopsystem einfach ein paar mal einen Blutsturz gebracht hat. Wenn man über 2500 Euro Netto in einen Shop steckt - und nach einem wichtigen Update keine Bestellungen mehr editieren kann, bis man ein Modul für 150 Netto gekauft hat - dann hört es einfach auf[/B]. Man muß [B]dort[/B] für !grundlegenste! Sachen im Shop viel viel Geld ausgeben, damit man überhaupt arbeiten kann. [B]Im Forum des Anbieters[/B] gibts aber als Ausgleich noch etwas viel tolleres… [B]Wenn man dort[/B] Sachen schreibt, die unangenehm sind, wundert man sich, warum niemand darauf eingeht. Zumindest bis man mal nicht eingeloggt ist - und mitbekommt, dass das Posting weg ist. Einloggen: Oh, da ist es ja!
Kurzum: Eine sehr bedenkenswerte Form der Zensur. Man denkt es ist da - angezeigt wird es aber nur dem Autor.
Das und vieles vieles mehr hat mich einfach davon abgebracht weiter Geld in den Laden zu stecken.

Mal ganz im Ernst: Für 30 Euro Netto kann man eine Domainänderung kaufen, Wenn Du also Interesse hast - ich mache dir einen guten Preis für die tolle Software vom Marktführer! Aber wehe Du schreibst dann da: “Das ist ja noch schlechter als das, was ich zuletzt probiert habe…”

greets, Nik[/QUOTE]

Mein Gemecker bezieht sich NICHT auf oxid. es geht um das was ich vorher hatte.
aktuell bin ich mit oxid sehr zufrieden, stolpere hier und da noch ein wenig rum - aber nach nicht mal einer woche komme ich schon sehr sehr gut zurecht und staune was man in einer CE alles geboten bekommt.

greets, Nik

p.s.: ich werde dem alten hersteller noch einen offenen brief schreiben den ich dann gerne hier in meiner signatur tragen werde. erstmal muß ich jedoch zusehen, dass ich die migration schnell hinbekomme, damit ich wenigstens noch ein bisschen vom weihnachtsgeschäft mitnehmen kann ^^

88

11 jahre später, und es wird immer nur schlechter und schlechter, bzw. es tut sich nichts… der code ist so dreckig. Man, die Article Model Klasse hat 5300 Zeilen. Sowas von Anti-Solid hab ich noch nicht gesehen. Die meisten Methoden sind als deprecated markiert, aber es werden keine Alternativen bereit gestellt.

Ich glaube dieser Saftladen hat überhaupt keine Programmierer mehr…

Nie wieder ein neues Projekt mit diesem Schrott!

89

Kritik finde ich durchaus angemessen, aber man sollte nicht in Straßenjargon und Beleidigungen enden.

My 2ct

90

Dies stimmt nicht.

  • 2012 gab es den Sprung auf die Serie 4.7 / 5.0 welches die Verzeichnisstruktur geändert
  • 2017 mit dem Sprung auf die 6.0 Serie wurde auf Composer und Symfony Framework umgestellt
  • 2022/23 steht der Sprung auf die 7.0 Serie bevor, wobei die Composer und Symfony Package Verwaltung Rechnung getragen wird

Übersicht der Versionssprünge Übersicht der OXID Editionen und Versionen

Über die Jahre wurde stets das Shop Framework auf die PHP und MySQL Versionen optimiert. Es wurde Zeit in Tests gesteckt. Mit dem B2B Bereich und der Cloud weitere Geschäftsfelder am Markt orientiert bedient.

Neu hinzu gekommen sind die GraphQL Module welche es langfristig ermöglichen ein besseres Frontend und Admin GUI zu entwerfen zugeschnitten auf die Geschäftsbedürfnisse der Shops.

Hinzu darf man die Zulieferer Industrie nicht vergessen, es kommen zahlreiche Zahlungsarten, Newsletter und Suche/Filter Module oder Integrationen zum Einsatz.

Da neben wurde zu vielen Dritt-Systemen Schnittstellen geschaffen z.B. Warenwirtschaftsystemen und andere.

Dies stimmt auch nicht.

Es wurde mit großen Schritten die ungarische Notation gegen neue Code Konvention ersetzt. Es gibt sogar Empfehlungen für die Programmierung von Tests für Module und Komponenten.

Die Anzahl der Code Zeilen sagt nichts über die Qualität einer Software aus.

Im Gegenteil verbirgt sich im Code jahrelange Erfahrung aus der Praxis. Selbst finde ich wurde ein guter Mittelweg gefunden was die Code Struktur anbelangt.

@rheinstruktur was ist damit gemeint?

Glaube vieles hast im Detail nicht betrachtet, viele deprecated Hinweise bei Methoden weisen nur darauf hin, dass sich die Code Konvention geändert hat protected und private markierte Methoden nicht mehr mit einen Unterstrich zu versehen.

Programmierer fehlen glaube ich überall. Für Bewerbungen ist OXID eSales sicherlich offen siehe die aktuelle Stellenanzeige unter OXID Entwickler im OXID Core Development Team Freiburg (m/w/d)

Glaube dies ist übereilt. Meist fängt man an die guten Seiten des OXID Frameworks zu vermissen, nachdem man den Schritt zu einem anderen Shop-System vollzogen hat.

Jede Software kommt an Ihre Grenzen und braucht Wartung auf Dauer. Auch bei anderen Shop-Systemen werden z.B. Updates/Migrationen nicht unnötig.

1 Like
91

Für viele leider nicht, wie ich aus den Anfragen, die uns erreichen, feststelle. Wie schon in einem anderen Fred geschrieben, war Composer der Genickbruch und das Aus bei vielen KMUs.

2 Likes
92

Mit der Serie 6.0 und Einführung von Composer sicherlich komplexer geworden.

Für viele KMUs welche viele Dinge in Eigenleistung erbringen möchten sicherlich dies ein großer Grund das System zu wechseln, welches nicht technisch nicht gewartet werden muss.

Aber dies als Hauptgrund aus zu machen finde ich zu kurz gedacht. Aus meiner Sicht ist der Wettbewerb härter geworden, die Erwartungshaltung an die Technik gestiegen z.B. soll diese viele Funktionen im Standard mitbringen und wartungsarm sein indem ein Laie sie pflegen kann.

Die Realität ist aber auch, dass viele Shops gerade wegen dem OXID Framework einen starken Einstieg in den E-Commerce gefunden haben vor allem über individuelle SEO Maßnahmen konnte ein/e Händler*in ein großes Publikum erreichen.

Wenn man die technischen Kosten der 6er Serie scheut, kann es sein das so manch ein/e Händler*in eine Bruchlandung hinlegt, weil das neue System und ein Relaunch die erworbene Sichtbarkeit nachhaltig zerstören kann wenn man nicht auf passt.

Ich mag den Ansatz von OXID eSales und unterstütze die Entwicklung hin zu einem Shop Framework anstatt ein Standard Shop System zu sein wie es mittlerweile dutzende auf dem Markt gibt.

Finde einen alten Blog Beitrag über die Entwicklung von OXID eSales lesenwert um daran zu erinnern wo OXID eSales herkam https://blog.oreilly.de/2014/05/19/individualitaet-als-standard-11-jahre-oxid/

Die ganze Wahrheit ist aber auch ohne Technik wird es heute im E-Commerce nicht mehr gehen.

Jeder welcher sich die Individualität an seiner Technik beim Shop nehmen lässt fährt ein großes Risiko eine hohe Abhängigkeit zu einer Plattform oder ein Software-as-a-Service Shop-System einzugehen.

Deshalb gehören bei der Planung, Umsetzung und Betrieb eines Online-Shops die technischen Kosten in der Preiskalkulation mit eingepreist.

Wer an der Technik spart, der hat aus meiner Sicht keine Zukunft bzw. beraubt seinem Entwicklungspotenzial.

93

Kein Beginner, der sich etwas aufbauen möchte, will sich nebenbei um’s Coding und Befehle kümmern müssen, nur um einen Shop zu installieren. Erstmal muss es laufen und getestet werden. Dann kann man investieren.

Das Forum lebte bis zur Einführung des Composers. Seitdem wird es immer weniger. Das Interesse schrumpft täglich Schlechter kann es für eine OpenSource-Version nicht laufen. Daher passt es auch zur 'Überschrift.

94

Ich kann die Diskussion um composer nicht nachvollziehen, die ich hier im Forum mehrfach gesehen habe. Für mich macht eine Software wie OXID eShop erst mit composer Sinn, da es unter anderem durch die Verwaltung der Paketabhängigkeiten Fehler und Gefrickel deutlich reduziert. Auch ist es dadurch sogar einfacher zu installieren, als sich erst ein zip auf seinen privaten Rechner zu laden, zu entpacken und dann per FTP auf einen Server zu laden. Mal davon abgesehen, dass composer in der PHP-OpenSource-Welt inzwischen Standard ist. Das hat mit OXID nichts zu tun.

Und wer für die Installation nicht mal einen Befehl copy & pasten kann, der sollte am besten auch nicht technisch alleine einen Shop betreiben. Denn dies geht mit einer Verantwortung einher. Daher würde ich sogar so weit gehen, dass nicht jeder, der technisch keine Ahnung hat, da dran gelassen werden sollte. So wie auch nicht jeder einfach Auto fahren darf. Hier stehen in den meisten Fällen zwar keine Leben auf dem Spiel, aber die Daten der Kunden. Das wird aus meiner Sicht zu oft übersehen.

Natürlich steht auch die eigene Existenz auf dem Spiel, wenn es den Shop zerschießt.

Daher besser immer einen technischen Partner hinzuziehen. Dazu zähle ich neben Agenturen auch Cloud-Systeme oder Plattformen wie amazon/eBay. Das mag zunächst teurer sein, aber mittel bis langfristig ist es billiger. Alles andere ist aus meiner Sicht grob fahrlässig.

95

Genau deswegen ist hier nichts mehr los. Wir bekommen täglich Anfragen zu Composer-Fehlern. Vom Update bis zur Installation von Modulen ist da alles bei. Die Leute verzweifeln und wandern ab.

Warum sollte es das? Keiner der Konkurrenten (z.B. Shopware, Joomla, Woocommerce, Magento) wird so kompliziert installiert. Und die rechtliche Prüfung muss sowieso sein.

96

@rheinstruktur was ist damit gemeint?

SOLID Principles

97

So ein Quatsch… bin hier z.B: auf der 6.2.5 und überall ungarische Notation… Die hätte man doch mal mit dem Sprung auf v6 komplett rausschmeißen können.

Statt ordentlich zu refactoren werden z.B. Symfony Events, QueryBuilder, etc. draufgebaut, aber nicht im Code verwendet… Der ganze Schrott untenrum bleibt. Große Teile des Cores sind als deprecated markiert…

98

Was wurde auf Symfony umgestellt? Beispielsweise Routing mit GET Parametern index.php?cl=xxx&fnc=xxx ??? Was ist das für ein Qutsch.
Du diese Aussage ist doch von den Releasenotes ge-copy-pasted.

So eine schlechte composer Integration habe ich noch nie gesehen echt… es wurde einfach der ganze Schrott in composer packages gepackt und dann bei composer update werden die module rüberkopiert… Das war halt der minimalste Aufwand um zu sagen “Wir haben auf composer umgestellt”…

99

Update-Probleme hast du mit jeder Software. Da diese jetzt mit composer durchgeführt werden, treten sie nun eben mit composer auf. Und bei Modul-Installationsproblemen liegen diese beim Modul und nicht bei composer. Ansonsten hätte sich composer gar nicht durchgesetzt.

Meines Wissens verwendet auch Shopware im Hintergrund composer.

Zur Einfachheit der Installation, die ich wie gesagt mit composer viel einfacher finde: Wäre es der Community so wichtig eine Alternative zur composer Installation zu haben, so hätte sie eine entwickelt. Zumindest steht es ihr offen. Was bringt Open Source sonst, wenn man nur den Hersteller in der Pflicht sieht? Ich habe hier auch keine Aktion gesehen etwas auf die Beine zu stellen oder mit dem Hersteller zusammen zu arbeiten. Habe aber auch nicht den Überblick :man_shrugging:

Aber wie gesagt, ich halte das aus besagten Gründen für keine gute Idee. Und vermutlich ist das auch der Grund, warum es bisher hierzu nichts gibt.

100

Hintergrund ist der Punkt

Mitnichten. Wir haben eine Sammlung von Fehlern und Korrekturen. Die wenigsten hängen direkt mit dem Modul zusammen. Viele Fehler werden auch hier beschrieben. Zuviele.