Um mal wieder auf ein Forenniveau zurückzukehren…
a-i-r-b, wie kann man dir helfen? Wo hakt es? 
[QUOTE=AlexS;56487]… Wenn ich die Modulentwicklung mit der von, zum Beispiel, Wordpress vergleiche ist Oxid ein Segen.[/QUOTE]
Ich finde es anders herum viel einfacher. Einer der Gründe ist IMHO die sehr guten Doku von WP (Codex). Auch hab ich bei WP nicht so ‘die Befürchtung’ etwas zu zerschiessen.
[QUOTE=michele;56536]Liegt es vielleicht daran, dass sehr Viele mit OXID (Einrichten, Anpassen, Erweitern, Verändern, …) Geld verdienen und deshalb alles für Nicht-Experten/Anwender sehr kompliziert erscheint?..[/QUOTE]
Würde ich zustimmen.
[QUOTE=Hebsacker;56539]Oder wie ist das bei Typo3? Das kann auch kein 08/15-User aufsetzen und einrichten, auch hier bbenötigt es kompetente Leute / Agenturen etc. die das erledigen. Trotzdem ist es quasi Standard der CMSse geworden.[/QUOTE]
[I]Typo3 [/I]mit [I]TemplaVoilá[/I] … ist die [I]Hölle[/I]. Ist aber richtig gut. Wenn man genau weiss an welchen Hebeln man drehen muss. Persönlich neige ich immer mehr zu WordPress und Drupal.
[QUOTE=stefanwesop;56548]Ich hab mal in einem Forum einen meiner Meinung nach sehr treffenden Vergleich der CMS Joomla und Drupal gelesen:
Joomla = Playmobil
Drupal = Lego
Oxid gehört für mich auch eindeutig zur Kategorie “Lego”. Man hat die Ritterburg zwar nicht in 5 Minuten zusammengesteckt, dafür kann man die Türme und Mauern aber genauso bauen wie man es möchte.
Playmobil macht auch Spaß, aber wenn man einmal mit Lego gespielt hat kommt einem Playmobil doch irgendwie limitiert vor …[/QUOTE]
lol Sehr geiler Vergleich.
[QUOTE=a-i-r-b;56608]Die Fehler: sehr schlechte Gestaltung, schlechte Usability, überladene Startseite[/QUOTE]
Man geht nicht mit dem Basis-Template live.
[QUOTE=a-i-r-b;56608]schlechte Checkout-Seiten[/QUOTE]
Zwei Seiten der Medaille. Optimierungswürdig, dennoch gut. Viell. zu viele Schritte.
[QUOTE=a-i-r-b;56608]fehlende Schnittstellen zu den Standard-Payment-Dienstleistern, die man heut einfach braucht[/QUOTE]
FULL ACK. Diese sollten direkt ALLE integriert sein.
[QUOTE=a-i-r-b;56608]fehlendes vernünftiges Monitoring.[/QUOTE]
IMHO Sache des Shopbetreibers. Google Analytics, etracker. Wenn Affiliate dann über eFire.
[QUOTE=seifert.eduard;58902]Ich finde es anders herum viel einfacher. Einer der Gründe ist IMHO die sehr guten Doku von WP (Codex). Auch hab ich bei WP nicht so ‘die Befürchtung’ etwas zu zerschiessen.[/QUOTE]
Das kommt immer drauf an was man in Wordpress machen will. Wenn du mal etwas machen möchtest was tiefer ins System eingreift, wird Wordpress echt übel. Da gibt es für ein und die selbe Funktionalität ein paar verschiedene Getter und ab und zu noch direkte Datenbankzugriffe und jedes mal dazu einen neuen Hook, der meist auch nicht Dokumentiert ist. Das ist bei Oxid eben, durch das Konzept der Module, nicht so.
Aber genug OT. 
[QUOTE=seifert.eduard;58907]
FULL ACK. Diese sollten direkt ALLE integriert sein.[/QUOTE]
Für das könntest du dann wohl eine eigene Entwicklungsabteilung aufbauen. Aus meiner Sicht nicht Aufgabe des Herstellers…
[QUOTE=seifert.eduard;58907]
FULL ACK. Diese sollten direkt ALLE integriert sein.
[/QUOTE]
Habe ich schon erwähnt, dass es toll wäre wenn das efire Paypal Modul irgend wann mal auch mit Giropay funktionieren würde?
(Diesen Bug zu beseitigen ist Aufgabe des Herstellers)
[QUOTE=Firefax;58963]Habe ich schon erwähnt, dass es toll wäre wenn das efire Paypal Modul irgend wann mal auch mit Giropay funktionieren würde?
(Diesen Bug zu beseitigen ist Aufgabe des Herstellers)[/QUOTE]
Die OXID eShop AG sieht das ja als Feature, nicht als Bug…
Das zu implementieren ist ja nun nicht soooo schwierig…
Um mal zum Topic zurückzukommen: Das Modulsystem von Oxid ist sehr flexibel, keine Frage. Die Installation von Modulen ist aber zu aufwendig. Die üblichen Schritte wurden ja schon genannt: Dateien kopieren, Templates anpassen, SQL ausführen, Modul eintragen, tmp leeren. Schon beim Dateien kopieren kann man nicht einfach copy/paste im Explorer machen, sondern muss den Pfad zum Template beachten. Beim Templates anpassen ebenso. Man kann zwar die Änderungen in einem “Custom Theme” getrennt vom aktuellen Theme pflegen, allerdings muss man erstmal wissen wie das geht, und bei Updates müssen die Dateien manuell nachgepflegt werden. Für einen “Normalanwender” ist das so nicht machbar.
In der Version 4.5 gibt es für Azure das neue Block-System, damit kann über SQL in die Templates eingegriffen werden, ohne die Templates zu verändern und unabhängig vom Theme (solange es auf Azure basiert). Leider ist das noch nicht benutzbar, weil es kaum Blöcke gibt und man nicht weiß was sich an Azure noch ändert, ist ja noch Beta. Wenn das allerdings funktioniert, kann ein Modul seine Ressourcen im Modulordner unterbringen, und über das Blocksystem per SQL die Templates ändern. Damit hätte man dann alle Änderungen des Moduls im Modulordner und Einträgen des Moduls in der DB. Wenn dann noch für die Einträge in System/Modules ein ähnlicher Mechanismus vorhanden wäre, könnte das alles mit einem relativ einfachen Installer erledigt werden, und so wäre auch eine Deinstallation ohne Rückstände möglich.
Zumindest für das Standardtheme und Themes nahe am Standard könnte so eine One-Click Installation und Deinstallation im Backend realisiert werden, ohne auf eine Funktionalität zu verzichten, und ohne größere Änderungen am bestehenden System. Ich finde dieses Ziel sollte man unbedingt im Auge behalten.
[QUOTE=avenger;58974]Die OXID eShop AG sieht das ja als Feature, nicht als Bug…
Das zu implementieren ist ja nun nicht soooo schwierig…[/QUOTE]
wenn der Bäcker beim Brot backen das Mehl vergißt ist das dann auch ein Feature wenn der Kunde ein echt gutes Brot kaufen will ??
Wenn ich was verspreche und das tut man indem man eine Leistungsbeschreibung abliefert oder wie hier sogar per Logo klar zu sehen für jedermann/frau … klar ist es einfacher aus jedem Bug eine Featureabwälzung zu machen, Freunde bei seinen Kunden erhascht man damit aber nicht.
Zurück zu dem Bäcker, würde dieser sich für einen schlechten Tag entschuldigen, an dem er schlicht das Mehl vergessen hat, käme der Kunde auch morgen noch und erhält dann auch ein echt tolles luftiges gut gebackenes Brot.
[QUOTE=leofonic;58976]Das Modulsystem von Oxid ist sehr flexibel, keine Frage.[/QUOTE]
So ist es, und man sollte es auch nicht so abwerten…
Andere Shopbetreiber aus der xtCommerce-/osCommerce- und Gambio-Welt wären froh, wenn sie so etwas hätten…
Zumindest in der Gambio GX2-Welt wird es das demnächst aber geben.
Da es da jetzt endlich auch eine Klassen-Factory gibt, habe ich die mal um diese Möglichkeit der Modul-Überladung erweitert (35 Zeilen PHP), wobei ich mich ganz eindeutig vom OXID-Konzept habe inspirieren lassen…
Denn das kann eigentlich jeder verstehen, und die Module sind auch leicht zu definieren… (“Jeder” meint (leider) natürlich nicht Joe Normalo Shopbetreiber…)
Sicher wird man da auch die geschilderten Umstände haben (Templateänderungen und so…), aber das wird um mindestens 10.000% besser sein, als alles, was man dort bisher machen konnte: da muss man nämlich alles direkt im Core-Code ändern, ein Albtraum…
Es ist eben alles relativ.
Klar ist es toll, wenn man Module vollautomatisch installieren könnte, sollte man unbedingt weiter treiben.
Zumindest der Template-Teil wird aber IMO, trotz Block-System, immer dann Handarbeit erfordern, wenn man sich vom Standard-Template etwas löst…
(Von Dingen wie YAML-Templates gar nicht mal zu reden…)
Aber wenn der Rest funktioniert ist das ja auch schon mal ein Riesenfortschritt und Erleichterung.
Ich denke mal, das ist auch so ein wenig die Crux von Open Source-Shops.
Viele fühlen sich halt bemüßigt, da selbst Hand anzulegen, ohne die notwendigen Voraussetzungen mitzubringen.
(Niemand kommt auf die Idee, an seinem Auto 'rumzuschrauben, außer er hat Ahnung davon. Aber einem komplexen Stück Software fühlen sich viele, ohne jeglichen Plan, gewachsen.)
Agenturkunden lassen das machen, für die ist das also völlig egal, wie einfach oder kompliziert das ist…
salut,
[QUOTE=seifert.eduard;58907]FULL ACK. Diese sollten direkt ALLE integriert sein.
[/QUOTE]
kann ich nicht zustimmen! Wo fängst du an zu definieren welche Bezahlmethode schon im Shop drin sein soll und welche nicht?
In jedem Land gibt es diverse übliche und weniger übliche Online-Zahlmethoden. Einige kannst du fast weltweit verwenden(wie Paypal/Kreditkarte) und nur auf ein Land bezogen.
Und Kreditkarte ist auch nicht gleich Kreditkarte, jeder Händler hat einen Vertrag mit einem anderen Zahlungsanbieter und jeder von diesen verwendet eine andere Schnittstelle.
Prinzipiell ist das Thema Bezahlmodule nicht bei Oxid zu suchen, dafür ist das Thema zu vielschichtig und zu umfangreich.
Ein anderer Punkt ist jedoch die Integration / Einbau eines Moduls(egal ob eFire-Modul oder eines Partner). In dieser Richtung könnte durchaus noch etwas getan werden.
ceau
[QUOTE=avenger;58974]Die OXID eShop AG sieht das ja als Feature, nicht als Bug…[/QUOTE]
Sehr interessante Ansicht!
lol
[QUOTE=Hebsacker;56479]
…
Ich finds gut zu hören, wie OXID von “extern” gesehen wird und wo die Stolpersteine sind.
Mit Kritik kann und muss man umgehen…
[/QUOTE]
Mir steht auch gerade der Sinn nach einem Posting wie ihn a-i-r-b gebracht hat.
Ich habe es mir aber verkniffen und habe nur aus Neugierde geschaut, ob bzw. wie oft sich anderen zu einem solchen Rant haben hinreißen lassen.
Meine Wahl fiel nur deshalb auf OXID weil mir die Lösung mit eFire am charmantesten erschien. Als der Shop eingerichtet war und es darum ging die ersten Produkte ein zu pflegen kamen bereits die ersten Kopfschmerzen. Multidimensionale Varianten waren in der zu dem Zeitpunkt erhältlichen Version nicht standardmäßig dabei. Ich war überrascht und habe hier erst einmal im Forum ohne Erfolg nach einer Lösung gesucht.
Das Bild das sich dabei abzeichnete war, dass die gleichen User sich bei dem Thema zu Wort melden und entweder die selbe wenig hilfreiche Antwort parat haben, oder schlicht auf einen anderen Thread verweisen, in dem die wenig hilfreiche Antworten bereits gegeben wurden.
Jetzt ist endlich die Version 4.5 verfügbar und der Eindruck, den ich von OXID habe verschlechtert sich weiter. Die Startseite ist leer, weil die gewählten Aktionen nicht zu sehen sind. Warum ist das so? Ich befrage Google und lande wieder in diesem Forum. Ich sehe, dass ich nicht der einzige bin, der sich mit dem Problem plagt und auch dass die meisten Threads ohne Lösung enden.
Zwischen diesen wenig hilfreichen findet man aber auch welche, die sich in den Unzulänglichkeiten der Software ergehen und dass die abweichende Bezeichnung identischer Punkte in den Varianten PE/CC/CE und was weiß ich noch abweicht. Dann stellt man fest, dass mögliche Problemlösungen sich auf das eine oder andere Theme beziehen etc. Natürlich will ich mich nicht über die Qualität der Userbeiträge beschweren. Das Problem steckt im System!
Sucht man hier nach azure aktionen zeichnet sich ein schönes Bild der Situation ab.
Die Aufgabenstellung war es einen einfachen Shop für Textilien online zu bringen, bei dem Farbe und Größe gewählt werden kann. Von ein paar Farbänderungen im Template abgesehen sollte nichts Großartiges geändert werden, und selbst diesen Anforderungen wird OXID nicht gerecht – zumindest sieht es aus meiner frustrierten Sicht einmal mehr danach aus.
Warum bleibt die Startseite einfach leer? Warum gibt es keine Fehlermeldung oder wenigstens einen Hinweis darauf dass noch etwas fehlt?
Ich bin von OXID gerade extrem genervt, weil jede aufkommende Frage – wenn überhaupt - nur mit enormem zeitlichem Aufwand zu beantworten ist.
Wenn eFire nicht wäre …
Nur ganz kurz, da wenig Zeit:
Klamottenshop mit Farben und Größen ist sogar in der aktuellen Version noch einfacher umzusetzen, da man die Dropdowns zur Variantenauswahl nicht mehr nach oben ziehen muss…
Warum bleibt die Startseite einfach leer? Warum gibt es keine Fehlermeldung oder wenigstens einen Hinweis darauf dass noch etwas fehlt?
In der config.inc.php kannst Du das Error Reporting aktivieren, dann werde auch alle möglichen Fehler und Informationen ausgegeben. Im Template selbst kannst Du über die Variable [{debug}] an sämtliche Objekte und eben Variablen im Template kommen.
Ansonsten warte doch die 4.6 er Version ab, dort wird sich mit Sicherheit noch einiges an den Templates ändern, so dass auch ohne viel Änderungen und ein paar Farbanpassungen Dein Shop direkt an den Start gehen kann.
So habe mir den ganzen Thread mal durchgelesen, und mag mal meine Sicht der Dinge (Senf) dazugegeben :
@avenger
Aber mal hallo, das geht ja man gar nicht :
[QUOTE=avenger;56477]
Du nervst, geh’ sterben.[/QUOTE]
@aggrosoft
ähnlich, aber nun da es ja ein bekanntes Zitat ist von Nuhr
[QUOTE=aggrosoft;56546]wenn man keine ahnung hat einfach mal die fresse halten ;-)[/QUOTE]
und man die Sache ja gerne mit Humor betrachten darf, geht das schon OK 
Grundsätzlich finde ich es gut, das der Threadersteller sich äußert, und aus seiner Sicht ist es wohl auch so, warum es jedoch inhaltlich am Thema vorbei geht muss nicht dem Enduser klar sein.
Gut Anfangspost war mit reichlich Wut im Bauch gestartet, aber das kam auch rüber und war dafür schon fast wieder ok, letztlich hat er sich dafür entschuldigt und die Punkte aufgenommen ohne beleidigt von dannen zu ziehen, dafür erstmal Hut ab!
Playmobil, Lego Vergleich finde ich gut, ebenso Linux, Windows, die passen wohl beide …
Grundsätzlich mal muss man natürlich selbst betreibbare Software und SaaS klar trennen, bei letzterem ist man auf Gedeih und Verderben (auch und v.a. der Preisgestaltung) vom Anbieter abhängig, und ausserdem nicht so flexibel.
Das Modulsystem ist schon sehr gut gemacht, die Template Integration per SQL Blocks ist eine gute Idee, birgt aber wieder viele Gefahren, ist halt wieder Linux mässig, man muss bei der Fehlersuche nun auch die DB berücksichtigen, das aber eh schon auch länger.
Bringt mich auf die Idee mal sowas anzuregen wie ein TPL aus DB Dumper, damit man damit dann mal einen Syntaxcheck machen kann mit einem smarten Editor (Codefärbung/Syntaxcheck), aber auch da ist halt wieder Disziplin beim Enduser gefragt.
Was php.ini IONCube und andere Encoder angeht, da ist es müßig, mir persönlich ist es ein absolutes Ausschlusskriterium, wozu ein Open Source System, das man herrlich debuggen und Codequalität beurteilen kann, um es dann aushebeln zu müssen.
Da würde ich jedoch dringend OXID Exchange verbessert sehen, solche Einschränkungen, sollten sofort und bei jeder Modulerwähnung sofort schreiend ROT markiert werden (ok also wenigstens erwähnt und nicht im kleingedrucktem :D) und nicht erst (wie es jetzt ist) erst nach Kauf / Download dann versteckt im Readme stehen !
Interessant finde ich das der Ursprungsposter von eFire so begeistert ist, das ist ja quasi eine Art SaaS, was im Umkehrschluss für mich genau das Problem darstellt, aber nun ich gehe halt da ganz anders ran, was für Modulentwickler sicherlich der richtige Ansatz ist.
Abschließend gesagt fand ich den Thread informativ und auch unterhaltsam, und möchte dem Ursprungsposter dafür danken und ihn bitten doch auch die durchaus vorhandene Hilfsbereitschaft hier im Forum zu probieren, also mal konkret fragen …
Ich finde es auch äußerst interessant dass Grabthar von eFire hellauf begeistert ist. Für mich ist es umgekehrt so, dass Oxid für mich an Wert verliert je mehr es sich auf eFire konzentriert. eFire widerspricht dem open Source Grundgedanken. (Ja ich weiß, dass Oxid sich auch irgendwie finanzieren muss;) )
Wenn man Klicki-Bunti möchte ist man bei Oxid sicherlich nicht richtig aufgehoben. Dann sollte man ein entsprechendes anderes Produkt auswählen und sich wie holgt sagt einem Anbieter auf Gedeih und Verderb ausliefern. Das kann sicherlich auch aufgehen. Mein Fall wäre es nicht.
Spitz formuliert könnte als Richtlinie für den Oxid-Einsatz vielleicht gelten: Wenn man dem System (zur Not auch dem Webserver) keine Fehlermeldungen/Logfiles entlocken kann, sollte man die Finger von oxid lassen oder jemand fragen der sich damit auskennt.