Das ist leider wahr. Ich werde mal versuchen, das die Tage mit einem längeren Post etwas abzumildern. Allerdings sind auch sehr viele Dinge noch im Fluss. Bitte habt Verständnis dafür, dass wir die alten Strukturen und Prozesse nicht von heute auf morgen ändern können. Wir müssen sie alle einzeln genau ansehen, bewerten und dann anpassen. OXID ist zwar kein riesiger Konzern, aber trotzdem ist das ein Haufen Arbeit.
Wenigstens steht jetzt die neue Strategie. Darauf aufbauend schauen wir uns jetzt alles andere an. Jeder Stein wird umgedreht, bewertet und in Linie gebracht (oder aussortiert).
Die Kommunikation gehört übrigens dazu. Und sie ist nicht gerade die kleinste Baustelle.
1 Like
Hallo, dass so was auch sehr gut funktioniert, zeigt der Contao Manager! Allerdings war das auch dort, ein langer und steiniger Weg, den die Entwickler gegangen sind! Aber jetzt Modulinstallationen oder auch Core Updates flutschen nur so!
Und vor allem muss man da nicht studiert haben dafür!
1 Like
Mein Punkt war hier auch nur, dass die Community durchaus sowas entwickelt hat. Weil die Aussage war, “die Community interessiert sich für sowas nicht, sonst hätte sie sowas entwickelt” 
Wenn man sich damit näher beschäftigt unter SOLID: Die ersten 5 Prinzipien des objektorientierten Designs | DigitalOcean wäre es wünschenswert wenn OXID eSales es schafft zum Kernthema HEADLESS die Abhänigkeiten von Klassen mehr aufzulösen.
Aber glaube da sitzt Ihr schon dran, aber ein Fokus Schwerpunkt darauf zu setzen wäre sicherlich nicht verkehrt.
Tatsächlich ist das im Moment das Kernthema in der Core-Entwicklung.
@rheinstruktur das Routing über GET und POST ist PHP. Oder was meinst Du hier mit Quatsch?
Ich glaube, er bezieht sich auf das POST-Redirect-GET-Pattern, das der Shop momentan noch einsetzt. https://de.wikipedia.org/wiki/Post/Redirect/Get
Auch das ist ein Thema, das mit der Fertigstellung des GraphQL-API angegangen wird. Allerdings erst danach.
Ich würde sogar soweit gehen, dass sich CE, PE und EE sehr wenig unterscheiden. Der einzige kleine Vorteil sind die Subshops mit der Vererbung der EE.
Und Rechte/Rollen und die neue Caching-Infrastruktur…
Allerdings Entfällt der Vorteil schnell wenn man über eine Deployment Routine nachdenkt mit einer angeschlossener Drittsystem-Software wie eine Warenwirtschaftssystem. Dann brauchst nämlich keine EE mehr, weil dann kannst mehrere CE an ein Warenwirtschaftssystem anschließen.
Das stimmt so nicht ganz. Erstens erhöht das die Komplexität und die zu übertragende Datenmenge enorm und außerdem hast du keine übergreifende Verwaltung von Rechten mehr. Bei ein paar wenigen Shops kann man das noch umgehen. Bei unserem größten Kunden sind das >1500 Shops. Alles 1500 Mal zu übertragen und sicherzustellen, dass die gemeinsamen Daten überall synchron sind, ist dann keine triviale Aufgabe mehr.
Aus meiner Sicht wäre ein logischer Schritt sich von der EE zu verabschieden und diesen Zusatznutzen der Subshops auch in ein Modul auszulagern.
Sowas in der Art schwebt uns tatsächlich vor. Allerdings ist das noch nicht final ausdiskutiert. Und, wie einige Modulhersteller schon bemerkt haben: OXID hat keine eingebaute Lizenzverwaltung für Module.
Um Geld zu verdienen aus OXID eSales Perspektive würde ich persönlich nur noch die CE und PE anbieten. Bzw. die PE zur EE machen und die EE so umbauen, dass die Subshops nur noch über separates Modul angeschlossen.
Das ist ein entscheidender Punkt. Wir müssen die Core-Entwicklung finanzieren. Die CE finanziert aber keine Core-Entwicklung. Und die PE tut das nicht ausreichend. Sowas funktioniert dann nur im Massengeschäft. Und dann stehen wir in direkter Konkurrenz mit Shopify. Ich glaube nicht, dass wir den Wettbewerb gewinnen würden.
Die Anfangskosten einer EE kannst keinen vermitteln. Es werden daher auch viele EE Lizenzinhaber das System wechseln, weil der Kostendruck zugenommen hat und man sich dann bewusst nach Alternativen umschaut.
Es gibt gar nicht so wenige Shopbetreiber, gerade im mittelständischen Bereich, für die die Lizenzkosten für eine EE oder B2B-Edition nicht zu hoch sind. Tatsächlich verkaufen wir meines Wissens kaum noch EE-Lizenzen, sondern stattdessen B2B-Editions.
Was wir aber tatsächlich häufig haben, ist, die Lizenz monatlich zu zahlen. Das war mal die grundlegende Idee zu unserer Cloud-Lösung, aber tatsächlich wollten die Kunden einfach nur nicht eine hohe Summe am Anfang zahlen, sondern die Kosten gleichmäßig verteilen und mit den einsetzenden Shop-Umsätzen gegenfinanzieren.
Lesson learned.
Geht also heute schon.
Im Prinzip kannst aus dem aktuellen Core so viel Positives machen. Es Bedarf nur einer Aufbruchstimmung und vorallem schnellere, kleinere Release Zyklen.
Die Aufbruchstimmung haben wir und wir haben auch schon ein paar Partner mitgenommen. Bis aus der Aufbruchstimmung allerdings ein öffentlich einsehbarer Plan für alle wird, brauchen wir immernoch etwas Zeit. Und ja, ich weiß, dass das so aussieht, als würde bei uns nichts passieren und als würden wir nicht mehr kommunizieren, aber wir haben einfach noch nichts fertig, was wir veröffentlichen könnten.
Henry legt großen Wert darauf, dass wir ab sofort sagen, was wir tun und tun, was wir sagen.
Heißt aber natürlich auch gleichzeitig, dass wir nicht mehr sagen, “wir tun dies oder jenes”, wenn das noch nicht fertig geplant und beschlossen ist.
Deswegen lege ich auch immer großen Wert bei meinen Antworten drauf zu verweisen, wenn etwas nur ein grober Plan ist. Auch das ist aber schon gefährlich, weil wir das zu unseren Roadmaps auch immer dazu gesagt haben.
Es gibt trotzdem hinterher einen Shitstorm, wenn sie dann nicht genau so umgesetzt wird.
3 Likes
Das interessant. Aber dies scheitert wahrscheinlich daran, dass im OXID Framework wie oben erwähnt der Symfony Kernel nicht integriert ist.
Im Contao Manager ist der Symfony Kernel zumindest Bestandteil https://github.com/contao/contao-manager/blob/main/composer.json#L33 weiß nicht ob man losgelöst vom OXID Framework auch so eine .phar Skript umsetzen kann um die Installation/Updates für den Anwender zu vereinfachen.
Hinzu kommt das CMS Contao scheint bereits einen Schritt weiter zu sein und nutzt klassische Composer Packages für die Funktionalitäten. Beim OXID Framework kommen aktuell noch Module zum Einsatz.
Eine Besonderheit vom OXID Framework sind noch die Überladungsketten von oxNew(..) die es erlauben, dass bestimmte Logik/Seitenelemente vom Shop mehrfach von unterschiedlichen Modulen überladen werden können.
Hinzu kommt, dass bei Contao Themes die Handhabung losgelöst von der Core Funktionalität ist wenn ich mir die Dokumentation Templates verwalten :: Contao Handbuch angucke.
Beim OXID eShop Framework wird über die Controller und Models bereits die Theme Struktur der Verzeichnisse und Namen vorgegeben. Eine Grundstruktur wird vom Framework vorgeben wo man schwer mit brechen kann außer man individualisiert den eigenen Shop sehr stark.
Das Kernziel von OXID eShop Modulen ist meist die Erweiterung/Anpassung des Shop Themes. Da ist neben der Composer Installation noch eine weitere Abhängigkeitsstruktur erforderlich, welche sich nicht zu 100% über ein OXID Manager am Vorbild von Contao lösen lässt.
Kurzum technische Grundkenntnisse für Composer und den Eigenarten vom OXID Framework werden immer notwendig bleiben. Ob dem Anwender mit einem OXID Manager alleine für die Eröffnung und Betrieb eines Online-Shops geholfen ist darf bezweifelt werden.
Da bei einem Shop-System noch weitere Abhängigkeiten wie Zahlungsarten und Versandarten oder diverse Schnittstellen zu Warenwirtschaftssystemen von Nöten sind.
Auf der anderen Seite wäre sicherlich viel gewonnen wenn der Laie zumindest ohne Composer Kenntnisse sich auf seinen Hoster ein OXID eShop selber installieren kann.
Mittlerweile gibt es auch Hoster welche bereits einen OXID eShop für den Kunden vorinstallieren. Also Alleine an der Installation eines OXID eShops kann es beim Anwender nicht scheitern.
Daher eher die Vermutung, dass viele Anwender am Betrieb eines Online-Shops scheitern. Dies können diverse Gründe sein wie z.B.
- Unterschätzung der Technikkosten, alles alleine lösen zu wollen
- Unterschätzung des Wettbewerbs
- Kein Plan von der Vermarktung eines Online-Shops
- Zu wenig Erfahrung im Vertrieb/Verkaufen
- Schlechte IT-Beratung
- Online-Shop wird mehr als Hobby betrieben anstatt professionell
- Unterschätzung von Updates, indem die Wartung des Shops vernachlässigt
- Sparen am falschen Ende, Wahl eines Billig-Hosters
- Scheuen von Investitionskosten bei Anpassungen am Shop-System
- Falsche Planung oder unzureichend
- Abgabe eines Updates an einen Entwickler ohne OXID Erfahrung was im Desaster endet oder Update nie erfolgreich beendet wird
- Kommunikationsprobleme mit betreuender Agentur/Entwickler
- …
Das war einmal. Wegen der Probleme haben die meisten Hoster OXID entfernt, weil zu serviceintensiv…
…hört bitte auf, das Problem schönzureden. Schaut mal in andere Foren, was über OXID geschrieben wird.
1 Like
Hast Beispiele als Links zu anderen Foren?
Selber findet ich wenn ich z.B. “oxid eshop erfahrungen” suche keine Foren Einträge.
Wenn ich nach “forum erfahrungen oxid” suche lande ich auf alte Beiträge aus 2017 und noch älter dies meist Foren von anderen Shop-Systemen oder Schnittstellen Diensten wie Warenwirtschaftssystemen.
Update: Wenn ich nach “oxid eshop installationen erfahrungen” suche lande ich in einem Forum vom Hoster aber da geht es um ini_set Erfahrungen mit OXID Shop / KeyHelp und ini_set - KeyHelp Community
Wenn ich bisschen mit Such-Parametern rumspiele z.B. inurl:forum intext:oxid hoster mit Zeitintervall auf 2 Jahre, dann lande ich z.B. auf https://www.homepage-forum.de/forum/-1-homepage-forum/-1-1-einsteiger/726660-webshop-alleine-erstellen-custom-shopsystem
Das ist zum Beispiel so ein Punkt, wo ein Laie sofort aufgibt!
Selbst auf meinem gemanagtem Server komme ich da nicht weiter ohne Klimmzüge und Änderungen an Coredateien!
Wenn man dort schon aufgibt, was machst man erst wenn die Lieferkette beim Versand abreißt oder andere Dinge den Betriebsablauf stören?
Update
@Sven_Brunk aber die Argumentation im Forum KeyHelp
Find ich von OXID Shop (ohne die Software näher zu kennen) aber schon abenteuerlich, es mit memory_limit zu überprüfen - das funktioniert natürlich nicht. Wollen die diesen Wert zur Laufzeit immer anpassen oder wie, anstatt die das mit einem unproblematischeren Wert testen…
Schon nachvollziehbar. Wenn dadurch die Installation nicht abgeschlossen werden kann, dies schon sehr ärgerlich. Vielleicht könntet Ihr die Prüfung verfeinern oder ganz rauswerfen?
Fazit der Grund warum im OXID Forum nichts los ist liegt am Webbrowser Setup, weil man wegen ini_set Prüfung die Installation nicht abschließen kann da vorab das Composer Geraffel schon zu viel geistige Kraft gekostet hat.
Es ist wissenschaftlich² erwiesen, dass wenn man einer Testgruppe vor die Wahl stellt ob Sie einen Apfel oder Schokolade essen möchten gibt die Testgruppe welche sich für den Apfel entschieden hat bei einer anschließende Aufgabenstellung früher aufgibt, als die Testgruppe welche sich für die Schokolade entschieden hat.
Diese Überwindung für die langfristig bessere Lösung mit dem Verzehr des Apfels hat bereits zu viel Kraft gekostet.
Vorschlag für neuen Marketing-Slogan:
OXID eShop Installation mit Composer und Browser Setup ist Training der eigenen Willenskraft. Bist Du willensstaark genug um einen OXID eShop zu installieren? Nimm die Herausforderung an!
² Quellenangabe: https://blog.neuronation.com/de/schokolade-oder-apfel-gehirntraining-steigert-die-willenskraft/
Ich überlege, wie ich das nett formulieren soll, aber ganz ehrlich:
Wir wollen gar nicht, dass ein Laie einen OXID eShop installiert. Das ist weder in seinem, noch unseren, noch im Interesse der Kunden dieses Laien.
Noch Fragen? 
memory_limit wird nicht gesetzt. Nur geprüft.
ini_set wird im Shop aber vor allem in der bootstrap.php an einigen Stellen verwendet. Es muss also möglich sein.
Beim letzten Mal, als ich das getestet habe, brauchte man aber nicht wirklich AllowOverrides All
In Server und Systemvoraussetzungen — OXID eShop 6.4 | Anwenderdokumentation steht sogar, es soll jetzt auf “None” stehen.
Dies stimmt nicht ganz.
Im ersten Schritt möchte der Interessent OXID eShop testen, wenn der Interessent bereits bei der Installation scheitert wird es gar nicht erst ein Kunde.
Auf https://www.oxid-esales.com/ und bei der Dokumentation wo es um die Installation geht fehlen noch Buttons mit der fetten Aufschrift “Demo Vorführung Termin vereinbaren ohne eigene Installation”.
Dort solltet Ihr als OXID eSales unabhängig von der Größe des Interessent eine Möglichkeit schaffen einem Interessent einfach und simple eine Vorführung des OXID eShops in der Community Edition bzw. der Edition seiner Wahl zu vereinbaren.
Zusätzlich kann man noch darauf hinweisen, dass empfohlen wäre sich bei der Installation und Einrichtung professionellen Rat zu holen.
Das ist richtig. Aber ein gänzlich anderes Thema Ich sehe den Anwendungsfall nicht ganz, dass jemand tatsächlich den Installationsprozess testen will, der den Shop nicht wirklich selber auch installieren muss.
Für den Fall, dass jemand den Shop selbst testen will, haben wir ja zumindest den Demoshop. Es wird dann auch in Zukunft noch weitere Optionen und auch einfachere Möglichkeiten/Vorlagen für Entwickler geben. Die Priorität liegt aber dann tatsächlich eher auf dem Verkaufsprozess.
Genau, und damit sind wir im Jahre 2008, d.h. in der Zeit vor Einführung der CE. Zum Glück hat Marco darauf frühzeitig hingewiesen.
@Sven_Brunk nur um Sicher zu gehen, dass wir uns nicht falsch verstehen.
Ich schreibe von der Customer Journey.
Beispiel
-
Ein Unternehmen/Händler*in denkt über Eröffnung von einem Online-Shop nach und möchte verschiedene Shop-Systeme testen, befindet sich im Auswahlprozess mit seinen Kriterien was sein Online-Shop alles können sollte
-
OXID eShop Community Edition hat es in Vorauswahl geschafft ohne die Erfüllung der Kriterien im Detail beurteilen zu können
-
Das/Die Unternehmen/Händler*in möchte nun gerne vorab Testen welche Kriterien das Shop-System erfüllt. Möchte ggfs. auch erste Module oder Themes ins System integrieren um zu testen (es handelt sich noch um einen Interessent kein Kunde)
Damit über Schritt 3 ernsthaft in Erwägung gezogen werden kann OXID eShop als Online-Shop Lösung auszuwählen möchte der Interessent sich OXID eShop installieren und bisschen einrichten.
- Nachdem erste positive Erfahrungen mit der OXID eShop Community Edition gesammelt werden konnten fällt die Entscheidung zu Gunsten von OXID eSales aus.
Erst nach dieser Entscheidung handelt es sich um einen Kunden welcher bereit ist Zeit, Ressourcen und Geld in den Aufbau seines Online-Shops mit der Software OXID eShop zu investieren.
Fazit es geht nicht darum alleine den Installationsprozess zu testen sondern das ganze Handling und die Art/Weise wie Themes und Module ergänzt werden können, wie die Datenpflege erfolgen kann oder Versandkostenregeln angelegt werden können.
Der ist aber sehr gut versteckt… Vom Erlebnis wäre wirklich ein Onboarding/Vorführung wünschenswert, die man Bestenfalls alleine durchlaufen kann und freiverfügbar z.B. in Form einer Video-Serie Darstellung.
Naja, das Kernproblem liegt darin bevor es überhaupt zu einem Verkaufsprozess kommen kann. Muss ein potenzielles Unternehmen/Shop-Gründer*in auf OXID eShop stoßen davon erfahren, dass es ein System gibt und dann muss der erste Eindruck positiv sein.
Erst daraufhin wird sich ein vermeintlicher Interessent überhaupt auf der Webseite zu erkennen geben, indem Kontakt aufnimmt.
Auch ein vermeintlicher Enterprise Interessent welcher Vorab eine Marktsondierung vornimmt, muss vorab überzeugt werden - da ist ein positiver erster Eindruck einer CE wichtig.
Wenn die CE schon nicht gut gepflegt und bereut wird, was wird der vermeintliche erste Eindruck sein und was wird der Interessent denken über die PE/EE.
Angenommen die CE würde es verstehen zu begeistern, wäre die Erwartungshaltung bzw. Bild einer vermeintlicher PE/EE schon vorab groß welche es nur gilt zu bestätigen.
Sehr interessante Diskussion…
Vorab: Ich bin kein Entwickler, sondern jemand der mit einer OxidInstallation im Jahre 2014 (CE 4.x) angefangen hat und mittlerweile bei OXID 6.2.0 PE angekommen ist.
Ich bin bei weitem kein Laie, aber eben auch kein OXID-eShop-Profi.
Und es ist in meiner Wahrnehmung auch so wie hier schon mehrfach geschrieben, dass sich der Shop, was die Updates betrifft, sich kaum noch betreiben lässt.
Man sollte eigentlich meinen, dass im Jahre 2022 die Installation und das Updaten einer Software zum Kinderspiel geworden ist, dies ist leider bei OXID eShop zu einer Katastrophe geworden.
Es geht hier nicht um spezielle Anpassungen für den Shop sondern um das reine “aktuell halten”
Wenn ich das hier im Forum richtig wahrgenommen habe, hat OXID auch gar kein Interesse daran, dass die Software leicht zu handeln ist.
Dann wundert es mich jetzt auch nicht, dass wohl viele schon abgewandert sind oder in naher Zukunft abwandern werden.
Das ist echt schade…
Gruß
Maro
1 Like
Von der reinen zeitlichen Entwicklung her, scheint es, dass man OXID vor die Wand fährt, sich nur nicht entscheiden kann, wer hinter dem Lenkrad sitzen soll…
Gruss
Marcel
Könntest du genauer erläutern, was dir die Updates erschwert?
Bei mir sind es das fehlende Vertrauen in andere Progrmmierer und die Ungewissheit darüber, was genau da im Hintergrund für ein Quatsch passiert, die mir das Leben… ääh… die Updates schwierig machen.
Obwohl ich nicht ganz neu mit OXID bin und auch ein bisschen programmieren kann, fühle ich mich bei Composer wie ein 11jähriger, der plötzlich eine Atombombe entschärfen muss.
Beim altmodischen Hochladen weiß man ja, was man hochgeladen hat. Aber nun sind da 500.000 Dateien im vendor, die Composer sont woher herzaubert, wenn er nicht vorher wegen RAM-limits verreckt.
Und was mache ich, wenn er mittendrin am RAM-Limit verreckt? Strg+Z gibts da nicht.
Dann installiert er plötzlich irgendwelche ganz neuen PayMore, -Later, -After, PayWithYourOrgans oder wie auch immer diese mitgelieferten Payment Module heißen.
Dann will er Dateien im Source und einzelne Module und Themes überschreiben, aber was davon muss überschrieben werden?
Und was passiert mit dem aktiven PaymentModul nach dem Update? In den Anleitungen wurde noch nie ein Shop+Module Update in einem Rutsch behandelt. Muss dann alles neu konfigureirt werden?
Und dann gibts da diese Module, die mit dem eigenen Zuhälter-Modul kommen, das unbedingt erforderlich ist, damit man diese Module nutzen kann. Dafür müssen Repo-Zugangsdaten eingegeben werden, die man seit dem letzten mal nicht mehr weiß.
Und absolut garantiert taucht irgendwo irgendwas auf, was in der neuen PHP oder Shop version nicht miteinander kompatibel ist.
Und sollte Composer bis hierher wie durch ein Wunder nicht an RAM-Limits verreckt sein, installiert er plötzlich die ganzen Dev-Dependencies, weil das die standard Option ist und dann schimft entweder composer selbst, dass post-install scripts nicht laufen können, oder falls doch, schimpft eines der post-install scripts aus den dev-dependencies über fehlende Konfiguratin derr CodeInception Tests.
Nicht mal ich in meiner beruflichen Funktion will mich dem Quatsch rumschlagen müssen, warum sollen das normale Anweder tun, die das nicht mal gelernt haben?
4 Likes