Dem würde ich nicht zustimmen. Community besteht zum großen Teil aus kleineren Shopbetreibern, weil OXID früher deutlich einfacher zu handeln war.
Das ist, als würde VW den Autofahrern sagen “wenn ihr weniger für Benzin zahlen wollt, dann baut euch selbst einen Motor, der weniger schluckt.”
Hätte OXID von Anfang an solche Komplexität, wäre nichts dagegen zu sagen, aber es ist mittendrin von einem Auto zu einem Segelboot geworden.
Und dann hat diese Boot auch noch keine gescheite Bedingungsanleitung dabei.
2 Likes
Der Vergleich scheint mir nicht ganz passend. VW ist keine Open Source Software mit Entwickler-Community oder ruft zum Mitmachen auf. Und VW bietet keine Basis-Autos kostenlos zur Erweiterung an.
Wenn ich es richtig sehe, wurde composer hier 2018 eingeführt. Oben ging jemanden die Entwicklung der Software noch zu langsam 
Wenn ich ins Shopware Forum schaue, gibts dieses “Gejammere” dort auch. Eben zu anderen Themen. Mir scheint, das normal. Jeder will irgendwas und das kostenlos. Verstehe ich ja auch, aber konstruktiv ist das nicht und vergiftet aus meiner Sicht die Atmosphäre in der Community.
Was fehlt dir in der Doku? Dort sind die nötigen Befehle und Schritte für die Installation gelistet. In der Doku gibt es oben rechts auch einen Link, wo man Pull Requests für die Doku machen kann.
Du meinst, es gibt eklatante Bugs bei der Modulinstallation, die der Hersteller nicht fixt? Worauf beziehst du dich?
Ich habe das gegenteilige geschrieben:
Modulfehler kommen im Zsh. mit dem Composer vor, aber sehr selten. Benutz mal die Suche, um Fehler rund um den Composer zu finden. Die Fragen stellen überwiegend einfache Anwender und keine Nerds.
Ich bin einige Jahre dabei und kann das Geschehen hier recht gut bewerten. Das Forum ist fast tot. Dank des Composers. Jetzt ist aber auch gut, denn es ist nur IMHO.
Du weißt aber schon, dass zu einem online Shop mehr gehört, als es einfach zu installieren? Wenn man nicht gerade zwei paar Jeans und fünf verschiedene Kite Boards verkaufen möchte, würde man eigene Produkte hinterlegen wollen, Texte anpassen, Sprachen hinzufügen. Es gibt immer wieder Neulinge im Forum, die nach Grundlagen fragen. Da würde ich wirklich gerne die Doku verlinken, muss aber immer wieder feststellen, dass dort kein Wort zu bestimmten Themen steht.
Und? Wie soll denn bitte jemand, der gerade zum ersten Mal OXID ausprobieren wollte, aber an fehlenden Infos scheitert, die Doku verbessern?
1 Like
@rubbercut:
Ich formuliere meine Frage klarer: Gibt es Bugs bei der Modulinstallation im Bugtracker, die OXID nicht fixt? Wenn ja, kannst du mir ein oder zwei nennen?
Interessiert mich auch, weil ich selbst die zsh verwende.
@vanilla_thunder:
Hier gibts ja auch Wikis, die aber scheinbar kaum noch gepflegt werden. Daher wundert mich die Kritik. Ansonsten hast du dich oder die Community bezüglich fehlender Themen in der Doku an den Hersteller gewandt?
Ich frage das und auch bei rubbercut, um zu wissen wie OXID reagiert hat.
Ist mir nicht bekannt. Würde im Einzelfall auch viel zu lange dauern. Fehler findest über die Suche.
Grundsätzlich hat ein Shop System zwei Anwender. Der eine will es installieren und mit geringsten Kenntnissen von PHP/MySql/Webserver evt. einfach ein paar Artikel verkaufen.ihm ist zudem Performance, SEO ect. wichtig
Der andere ist der Entwickler, der unter Umständen auch einen Shop betreiben kann. Er benötigt bequeme Entwicklungsumgebungen, Managementsysteme, um durch das Chaos JS/JQuery, Template processing, Datenbankabfragen optimieren ect.
OXID hat sich vor Jahren dafür entschieden, den Entwickler Part mehr zu fördern, als den der normalen kleinen ShopUser, die jahrelang die Basis des OXID Systems gebildet haben.
Und Fortschritte hat dass System vielleicht unter der Haube gemacht, nach aussen keinesfalls.
Klar es gibt eine B2B Edition, zusammengeschustert aus zugekauften Komppnenten. Ein Responsive Theme, zugekauft. Ansonst ziemlich dünne Hose.
Linie und Struktur sind nicht zu erkennen. GraphQL wird angekündigt, ein Workshop eingesetzt, Basis Elemente bereit gestellt, und danach? Ebenfalls ziemlich tot Hose.
Andere Shopsysteme, die bei weitem schlechtere Code Qualität hatten, haben die Chance genutzt, und bedienen alle. Auch composer einfach im Backend, ohne cli.
Zudem modernerund performanter. OXID hat an dieser Stelle leider falsch taktiert und wird, wenn das Geld alle ist, in der Bedeutungslosigkeit versinken
Ergänzend noch den dritten Anwender namens Endkunde 
@mws_1941 gute Zusammenfassung. Die technische Basis ist da. Jetzt gilt es die Kundenbasis zu erhöhen.
Die Kunden basis war mal da, wer sich aktuell umsieht, würde sich nicht für OXID entscheiden.
Das ist der Punkt. Laut Marco strebt OXID andere Ziele als CE an. Deswegen kam es ja auch zum Bruch.
Das ist aber genau das Problem. Klar will OXID Professionelle Service Verkaufen und gibt z.b. bestimmte Performance Module ab PE/EE raus.
Nur ohne breite Basis ala CE werde ich keinen nennenswerte Platform für PE/EE/B2B sein. Wie aich immer die Editionen dann heissen…
Masse als Basis, Enterprise ect. um Geld zu verdienen. Guck Dir sowohl IT Firmen als auch normale an. Ohne dieses Prinzip gehe alle verloren
Ob das strategisch sinnvoll ist, kann nur OXID beantworten. OXID ist damals ja mit dem Bezahlmodell gestartet. CE kam später. Scheinbar lohnt sich der PE && EE Bereich mehr als CE mit den anhängigen Kosten. Wir sind froh, dass wir auch andere Shopsysteme betreuen und nicht von OXID abhängig sind.
PE/EE kann man Leuten verkaufen, die das System kennen und nutzen. Neukunden mit der aktuellen Basis zu bekommen, bei Lizenzkosten/Wartungskosten im 4 bis mittlerem 5 stelligen Bereich ist mit Sicherheit nicht so einfach. Ja es gibt ein paar Premium Kunden, die auch eine entsprechende Lösung gebaut haben, oder sich haben bauen lassen, aber zum dauerhaften Überleben zu wenig.
Gruss
Marcel
Wäre es nicht klüger, die Zukunftsfähigkeit der Plattform an Hand der aktuellen Repositories und dem master-branch zu bewerten?
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.
Du meinst sowas wie GitHub - ioly/ioly: We all love ioly. ?
Ja, es wäre schön wenn die 7er Serie früher kommen könnte als im Release Plan vermerkt.
@Sven_Brunk dies finde ich einen berechtigten Kritikpunkt.
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.
@Sven_Brunk dort könntet auch nochmal nacharbeiten um die ungarische Notation komplett zu entfernen.
@rheinstruktur @Sven_Brunk an dieser Stelle weiß ich nicht was ich darauf schreiben soll. Selber würde ich mir an dieser Stelle wünschen, dass OXID eSales den Symfony Kernel noch implementiert damit man den Symfony Profiler integrieren kann und andere Tools wie Encore für Frontend Techniken wie Webpack.
Einen Anlauf gibt es dazu bereits unter GitHub - OXIDprojects/oxid-symfony-kernel: Symfony Kernel für Oxid; Routen, Events, What ever; Module & Themes mit Symlinks installieren.
@rheinstruktur das Routing über GET und POST ist PHP. Oder was meinst Du hier mit Quatsch?
Wenn man meine Anmerkung näher ausführen möchte, dann sind Vorteile von Composer
- man kann Abhängigkeiten zwischen Shop-Version und Modulversionen in der
composer.jsonDatei definieren, wird leider zu wenig genutzt - PHP Versionsabhängigkeiten können auch definiert werden
- man kann über einen Blick in die
composer.jsonerkennen was alles im Shop genutzt wird - die Aktualisierung des Shop Core Framework und der Module hat sich vereinfacht mit Composer, indem copy & paste fast gänzlich entfallen und das meiste ins
vendorVerzeichnis ausgelagert wird
Die Symfony Vorteile sind,
- die Symfony Konsole wird verwendet, es können weitere Konsolen Befehle für die Shop Wartung hinterlegt werden
- das Framework ab der Serie 7 lässt sich komplett über die Konsole installieren ohne Browser Setup
- über Symfony YAML Datei lässt sich update-sicher in den Framework Core eingreifen
- der Admin und Template Engine ist austauschbar geworden, lässt sich auf Twig umstellen und der Admin kann durch eigenen Admin ersetzt werden
- neben Modullösungen können eigene Composer Packages definiert werden, auf die im Shop Framework zurück gegriffen werden kann
Das ist der erste Schritt gewesen. Mit der 7er Serie wird das module Verzeichnis endlich abgeschafft. Zumindest habe ich mich mittlerweile an den Umstieg auf Composer gewöhnt und finde dies für Shop Updates angenehmer als vorher.
Wenn ich z.B. an den Umstieg von 4.6 auf 4.7 denke, ist mit Composer eine klare Verbesserung eingetreten.
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.
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.
Aus meiner Sicht wäre ein logischer Schritt sich von der EE zu verabschieden und diesen Zusatznutzen der Subshops auch in ein Modul auszulagern.
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.
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.
Im Prinzip sollte man den EE Lizenzinhabern eine Perspektive aufzeigen, indem mehr die Rolle des Dienstleisters eingenommen wird und im Sinne des Handels entschieden wird.
Dies heißt stärkerer Fokus auf die Basis des Handel treibens in Blick nehmen und Schrittweise Dinge wie Suche/Filter im Core verbessern über Andockstellen oder eigene Lösungen über Module/Components.
Im Prinzip kannst aus dem aktuellen Core so viel Positives machen. Es Bedarf nur einer Aufbruchstimmung und vorallem schnellere, kleinere Release Zyklen.
Es darf einfach nie mehr ein Release mehr als 1 Jahr auf sich warten lassen… Das nun fast ein Jahr vergangen ist als die 7er Serie in Ihren ersten Release Candidate erschienen und bis heute noch nicht Stable ist - die eigentliche Katastrophe für mich.
Davon würde ich abraten, dieses Handling fliegt Shopware aktuell bei Updates um die Ohren. Dazu genügt ein Blick ins Shopware Forum.
Dies kannst bei einem System wie WordPress machen, aber nicht bei einem professionellen Shop-System. Selbst bei WordPress fliegt Dir das Plugin Handling ab einer bestimmten Anzahl von Plugins um die Ohren.
An die Performance Nachteile und schlechte Code-Qualität von manch einem Plugin möchte ich gar nicht denken.
Guten Morgen
Das war ja immer so.
Du unterschätzt die Masse an PE und EE, mit denen OXID Geld verdient (hat).
Das Geplänkel darüber, was toll an OXID ist, lenkt vom Hauptproblem ab, nämlich, dass es zu kompliziert für die meisten ist. Und niemand wird verleugnen können, dass hier nichts mehr los ist.
1 Like
Moin 
Ja, dies aus meiner Sicht aber ein Kommunikationsproblem was sich OXID eSales selbst eingeborgt hat. Es ist sehr ruhig geworden um das Kernprodukt des OXID Frameworks.
Mittlerweile hast seit fast 2 Jahren Stille in der Außenwirkung bezüglich Releases des OXID Frameworks.
Man wartet förmlich darauf, wann endlich OXID eSales Farbe nach Außen bekennt und aufzeigt in welche Richtung es sich entwickeln möchte.
Vieles findet im Verborgenen statt. Es wird zwar mittlerweile viel mit Partner und Co kommuniziert. Aber der/die Händler*in gefühlt Außen vor, statt mit ins Boot zu holen.
Professional Services existiert nicht mehr. Wir verkaufen unsere Services in Zukunft nur noch an die Partner. Und außerdem nutzen wir die OXID Solution Catalysts neben dem Empowerment der Partner auch dazu, Informationen über die Projekte zurück ins Produkt fließen zu lassen. (Anforderungen und Herausforderungen)