Mega Statement, @vanilla_thunder
Gruss
Marcel
Ich habe konkret nach seiner Erfahrung gefragt, da mir diese Information in seinem Post gefehlt hat 
Vorher kamen die aus dem Nichts aus einem zip, die du irgendwo im Web suchen musstest. Jetzt hat man eine Übersicht, was, woher und in welcher Version, mit zusätzlicher Prüfung, ob Server Systemvoraussetzungen erfüllt sind.
Klar könnte man sich die Befehle einfach in ein Shell Skript speichern. Allerdings hat es auch seine Vorteile zunächst in die Doku zu schauen, da man dann erfährt, was beim Update zu beachten ist. Systemvoraussetzungen zum Beispiel, damit man keine Überraschung erlebt.
RAM Limits klingen nach Billighoster. Hatte ich zumindest noch nie. Ansonsten kann man mit composer lokal installiert sein eigenes zip erstellen und auf den Server laden. Gibt auch eine Anleitung dazu:
War früher auch nicht anders. Da hat PHP nur weniger häufig Updates erfahren. Klar könnte man wie früher die Prüfung weglassen, hat man dann halt ein potenziell instabiles System.
Im Zweifel alles.
Warum sollte er die Datenbank bei einem Update leeren?
Unerwartet, dass ein Shop Payment Module mitliefert. Ein Problem sehe ich da erst, wenn diese auch alle automatisch aktiviert würden.
Darauf kann ich mir keinen Reim machen. Ich schätze, du meinst Bezahlmodule, die nicht jeder frei herunterladen können soll. Wenn dies über composer erfolgt, kann dieser die Zugangsdaten automatisch für dich speichern. Dann wirst du das nächste Mal nicht mal mehr gefragt. Dann kannst die auth.json, wo composer das speichert, auch einfach sichern und auf andere Server mitnehmen. Super praktisch.
Von all deinen Kritiken ist das für mich der einzig nachvollziehbare.
Ok, dass das alles nicht mit einem Klick geht, kann man auch kritisieren. Den Wunsch kann ich schon nachvollziehen. Dann hat man aber auch weniger Einfluss darauf, was passiert und kann es schlechter automatisieren. Sind unterschiedliche Anforderungen. Ansonsten gab es ja scheinbar grafische Lösungen, wie oben genannt wurde.
Ich halte Deine Antwort(en) für nicht plausibel. Wir schreiben hier nicht als Entwickler. Für Leute, die ständig damit zutun haben, dazu zähle ich auch mich und Moderatoren wie @vanilla_thunder, gibt es natürlich Lösungen.
Für alle Neuen ist es einfach nur murx, die Befehlszeile nutzen zu müssen. Deswegen ist OXID bei Hostern (als Shop-Installationspaket) rausgeflogen und bei Neueinsteigern und vielen Nutzern , die Updates selbst machen müssen, uninteressant.
Somit gibt es Wechselanfragen ohne Ende.
Moin 
Die Antworten sind im Detail nicht korrekt oder wirken sehr oberflächlich, aber beinhalten auch Kernaussagen die sich daraus ableiten lassen die korrekt sind.
Hmm… ein Perspektivwechsel lohnt sich immer und in die Rolle eines Händler*in sich hineinzuversetzen. Aber wieviele von uns Entwicklern betreiben erfolgreich einen Online-Shop?
Lösungen für technische Probleme zu finden sollte die Kernkompetenz von Entwicklern sein wenn ich nicht irre.
Es gibt keine Neuen. Dies ggfs. das wahre Problem weil die Entwicklungskosten eines individuellen Shops im letzten Jahrzehnt extrem gestiegen, gleichzeitig die Konkurrenz stark zugenommen und damit der Wettbewerbsdruck.
Heutige Neue starten mit Shopify weil die Einstiegshürde geringer und vorallem die Kostenseite gering zum Start (erhöht sich spätestens nach 1 Jahr sprunghaft, Stichwort immaterielle Kosten der Abhängigkeit).
Ja, aber dies begrüße ich persönlich. Mit der heutigen Abhängigkeitsstruktur sollte ein individueller Shop wie OXID eShop vom Fachmann installiert werden und nicht vom Laien oder Nutzer mit Halb-Wissen.
Mir die Lösung von Shopware gestern angeguckt wie man dort den selbst-gehosteten Shop installieren sollst. Da wird noch mit einem ZIP-Verzeichnis gearbeitet was man herunterladen soll und per FTP auf den Server laden.
Das ZIP-Verzeichnis beinhaltet das vendor Verzeichnis. Darin sehe ich die Gefahr wenn in einer Software Bibliothek eine Sicherheitslücke enthalten ist die/der Händler*in dort auf eigene Gefahr zurück gelassen dies zu fixen und muss warten bis der Fix über ein Versions-Update seitens Shopware eingespielt wird. Dies halte ich nicht mehr für zeitgemäß.
Wobei man Shopware loben muss, dass die sehr viele Ressourcen in UI/UX Design gesteckt haben und es sich sehr angenehm aus Nutzersicht anfühlt seinen Shop einzurichten, wenn man erstmal den Download und FTP Datentransfer hinter sich gebracht hat.
Dies kann ich persönlich nicht bestätigen. Meist wird bei einer Anfrage bezüglich eines Updates des OXID eShops auf Shopware als Alternative verwiesen und damit gedroht dann dorthin zu wechseln.
Manch einer wird dies dann tatsächlich in die Tat umsetzen, aber dies mehr ein Preiskampf weil der Neustart mit Shopware zu Beginn kostengünstiger.
Die Kosten für den Betrieb eines Online-Shops werden dort meist Außen vorgelassen. Dies aus meiner Sicht das Kernproblem.
Ein/e Händler*in sollte mehr die Kosten für den Betrieb im Auge haben als ein Update und heutzutage sollte es einen wiederkehrenden Prozess geben um Updates zeitnah einzuspielen.
Fehlt es an dem wiederkehrenden Prozess hat der Online-Shop aus meiner Sicht keine Zukunft.
Genau. Es gibt seit der Einführung des Composers ein “Nachwuchsproblem” für CE Nutzer, weil andere Systeme einfacher zu bedienen und zu installieren sind.
Composer wird das Problem nur verschärft haben. Das Problem gab es bereits vor der 6er Serie und den Einsatz von Composer.
Shopify und Shopware haben seit 2015 stark zu gelegt bei den Marktanteilen.
Es ist normal, dass man Marktanteile verliert, wenn Systeme hinzukommen. 2013 - 2018 war das Forum sehr gut frequentiert. Hier geht es mir um die Qualität des Shops sowie die Installation und die Updates aus Sicht des Anwenders. Und sorry, ich höre nur Gemecker, wie bereits geschrieben…
Wie ich sage. Und um diesen Werdegang aufzuhalten (wenn das überhaupt gewollt ist), müsste sich was ändern.
Ich gucke immer bei German eCommerce Websites Lists weil ich die Daten für aktueller und zuverlässiger halte.
Mich interessiert auch mehr wie viele Shops da Draußen unterwegs und nicht ob nach dem System gegoogelt wird.
Wenn man Google Trends betrachtet kann die Häufigkeit auch in einem negativen Kontext stehen, dass man besonders häufig Hilfe benötigt wegen Bugs etc.
Der Vollständigkeit halber die Aufteilung für Deutschland
Stand von Freitag, den 13. Mai 2022
Gibts da auch Trends?
Ja, musst z.B. nach “OXID eshop” suchen Search results for oxid eshop
BuiltWith untergliedert nach
- OXID eShop Community OXID EShop Community Usage Statistics
- OXID eShop Enterprise OXID Eshop Enterprise Usage Statistics
- OXID eShop Gesamt OXID EShop Usage Statistics
Dies wäre z.B. OXID eShop Community
Stand vom Freitag, den 13. Mai 2022
wenn man nur nach dem Begriff “OXID” auswertet (nicht oxid esales software) muss man einen Offset von ~ 10% abziehen da auch nach zB Kupferoxid gesucht wird - erkennbar daran dass es 2004 noch gar keine OXID-Software gab
aber egal welche Statistik man sich anschaut: vor +/- 10 Jahren hat OXID noch in der ersten Liga gespielt - heute nur noch unter “ferner liefen” …
*bei kleinen oder mittleren Shopbetreibern
möchte ich eventuell ergänzen, denn für große Kunden ist OXID attraktiver als Magneto, der ab einer bestimmten Größe so viel Rechenlast erzeugt, dass man auch im tiefsten Winter nicht mehr heizen müsste, wenn man den Server zuhause hätte.
Im Bereich B2B gibt es, mMn, bis auf Intellishop keine nennenswerten Alternativen.
Aber diese Shopbetreiber bauen ihren Shop nicht selbst auf, da gitbs ganze eigene IT-Abteiungen oder Verträge mit Agenturen.
Und meinen Kunden musste ich bisher nur extrem selten sagen “Sorry, das geht mit OXID nicht”, wobei mir gerade nichts konkretes einfällt, wann ich es das letzte mal gesagt hätte.
Das ist ja nicht Ursprung der Diskussion. Dass mit OXID alles machbar ist, steht außer Frage. Der Einstieg muss wieder einfacher werden, d.h. ohne Fachliteratur möglich sein.
Ja, bin ganz bei Dir.
Ich hatte Dich so verstanden, dass Du das Composer Handling als Hauptschuldigen ausgemacht hast warum im Forum so wenig los ist.
Selber würde ich mir einen Kompromiss wünschen, dass man an Composer festhält für die Installation und Updates.
Aber die Installation des Shops oder von Modulen versucht zu vereinfachen, damit man die Konsolen Befehle freundlicher gestaltet mehr mit dem Hintergedanken, dass die überwiegende Module in einem OXID eShop einzigartig für den jeweiligen Shop sind und dies muss stärker berücksichtigt werden seitens der OXID eSales Entwicklungsabteilung.
Was spricht aus Deiner Sicht dagegen die Installation/Update über OXID kundigen Entwickler vornehmen zu lassen?
Weil die Installation für einen OXID kundigen Entwickler sehe ich als Lösung an, aber es muss wie ein Erste-Hilfe Kurs sich die OXID Kundigkeit innerhalb eines 1-2 Tage Workshops aneignen lassen. Egal ob Online oder in Präsent.
Neben den Aspekt über die Installation, Update und Pflege über Composer. Muss die Kostenseite stärker berücksichtigt werden. Die Kostenseite muss attraktiver sein.
Aktuell passt die Erwartungshaltung von einem modernen Self-Hosted Shop-System nicht mit dem Angebot was OXID eShop an einen Shop Gründer*in darstellt nicht überein.
Um ein paar Beispiele aufzählen
-
Admin lässt sich durch Frameset Technik aus Kostensicht nur sehr umständlich erweitern, dies muss zwingend nach HTML5 Standard migriert werden
-
Theme lässt sich nicht wirklich effektiv aktualisieren bei Updates wünschenswert wäre die Nutzung von
packages.jsongepflegt mityarnund Skripte optimiert mit Webpack -
UI/UX Design muss bei kommenden Releases einen größere Rolle spielen, dabei darf es nicht sein, dass ein Unternehmen dort den Stempel aufdrückt
Um Shop Gründer*innen besser anzusprechen mit der Community Edition bedarf es einer Vielzahl von Themes geben. Punkt 2. muss gut durchdacht sein plus Anleitung wie Themes zukünftig gepflegt werden mit der Zielsetzung, dass sich HTML Vorlagen kaufen lassen und einfacher in ein OXID Theme verwandeln lassen.
Zusätzlich sollte es möglich sein eine eigene Hauptnavigation aus Anwendersicht über den Admin definieren zu können ohne komplett auf die Kategorie-Struktur angewiesen zu sein.
Die Community Edition sollte gezielt auf eine geringe Produktanzahl ausgelegt sein um z.B. Händler*innen anzusprechen welche Ihren Shop nur als Nebenerwerb oder parallel zu Ihren Ladengeschäft betreiben attraktiv zu halten.
Selber habe ich immer eine Floristin im Kopf welche saisonale Angebote für Ihr Ladengeschäft Online bewerben möchte wenn Muttertag oder Valentinstag ist. Alle Sträuße werden z.B. Einzelstücke sein, aber heutzutage wäre die Erwartungshaltung bereits einen individuellen bunten Strauß Online vorzubestellen für Selbst-Abholung.
Anderes Beispiel ist die Lebensmittel und Agrarprodukte. Im Handwerk betreiben z.B. sehr viele Fleischer einen Online-Shop oder wenn wir an Produkte wie Eier, Milch, Wurst und Käse Lokal denken.
Bei Wurst aus Eigenhaltung stehen viele Landwirte die Ihre eigene Tiere verarbeiten lassen wollen und in den Direktvertrieb einsteigen wollen vor der Herausforderung, dass sie keinen Schlachter mehr finden. Wo Sie auch Ihre Tiere verarbeitet zurück erhalten.
Zusätzlich großes Problem ist die Vermarktung wenn man einen Schlachter gefunden hat. Da könnte man einen Beitrag leisten solche Angebote sichtbarer zu machen.
Solchen kleinen Fällen muss mehr Rechnung getragen werden.
Der OXID Weg wie man das OXID Framework individualisiert ist zu teuer geworden, indem es eine zu hohe Vorbildung benötigt. Tutorials wie man das Framework erweitert müssen verstärkt verfasst werden und bereit gestellt werden.
Man könnte z.B. Entwicklern kostenfreie Schulungen anbieten wenn diese hilfreiche Tutorials rund um OXID eShop verfassen oder wenn ein Händler*in seine individuelle Modullösung für seinen Shop der Allgemeinheit kostenfrei zur Verfügung stellt ein kostenfreises Upgrade für die PE erhält.
In der Weiterentwicklung dauern die Release Zyklen viel zu lange… OXID eSales macht irgendwas im stillen Kämmerlein. Kommt nach einer Ewigkeit dann mit deren Weiterentwicklungen raus um dann verwundert festzustellen, dass es die Markterfordernis nicht mehr abdeckt. Diese Art der Kommunikation muss sich ändern. Die Kommunikation muss verstärkt werden.
Ein Weekly Bericht von diversen OXID eShop Abteilungen wären wünschenswert, jede Woche könnte eine andere Abteilung öffentlich schildern woran Sie gerade sitzen und sich Gedanken machen.
Die Abhängigkeiten die zu Dritt-Bibliotheken wie Composer, Bootstrap, Symfony geschaffen werden müssen besser durchdacht werden seitens OXID eSales. Aktuelle Community Serien 6.3 und 6.4 sind mit Ihren Abhängkeiten zu Symfony Components bereits veraltet.
Es kann einfach nicht sein, dass die Abhängigkeiten nicht zeitnah gepflegt werden. Das muss in Zukunft besser abgewogen werden. Wünschenswert wäre dort Abhängigkeiten zu Dritt-Bibliotheken zu reduzieren.
Aktuell läuft es mit der 7er Serie darauf hinaus, dass wenn diese nicht bis Ende 2022 Stable, dann kannst dieses Forum schließen.
Neben der wachsenden Konkurrenz ist das sicher mit ein Grund für die Ruhe, um nicht zu sagen “Totenstille”. Dann…
Leider ja, wenn nichts passiert.