Nachdenkliches zum 4.4.-Update

Hi,

wenn ich mir aktuell die Detail-Seite des EE-Demoshops http://demoshop.oxid-esales.com/enterprise-edition/Eco-Fashion/Men/Kuyichi-Jeans-Mick.html anschaue, komme ich doch ins Grübeln.

Nach einem Monitor voll Produkt kommen [B]2 Monitore voll Facebook[/B] und erst danach sieht man die Varianten etc. Mal unter uns: ist das nicht etwas übers Ziel hinausgeschossen? Welcher normale Kunde sollte da noch durchsteigen?

Meine Frage an Oxid ist nun: könnte man Integrationen zu externen Services nicht modular anbieten? Muss nun jeder Shopbetreiber bis zum Ende den Facebook-Code in seinen Templates (und mit Sicherheit auch im Core) mitführen, selbst wenn er davon keine einzige Funktion nutzen möchte?

Ebenso verhält es sich mit Trusted Shops. Bei jedem Seitenaufruf des Shops wird (bei Standard-Templates) [{if $oView->getTrustedShopId()}] aufgerufen - auch wenn der Shopbetreiber Trusted Shop gar nicht kennt, geschweige denn da Kunde ist. Bei jedem Update sind 'zig Template-Dateien geändert - nur weil TS die eine oder andere Änderung benötigt.

Irgendwie werden die Templates immer größer und mehr (mit 4.4. sind wieder 23 Dateien dazugekommen!). Irgendwann platzt wieder alles aus den Nähten und mit dem 5er Oxid gibts dann das 3. neue Template-Konzept.

Aus meiner Sicht wäre es wirklich ein echtes Feature, wenn man sich die ganzen Fremd-Integrationen separat laden könnte und diese dann bei Bedarf in die (Kern-)Templates integrieren könnte.

Ich hab nix dagegen wenn jemand seinen Shop ans Facebook-Design anlehnen möchte, weil er privat dieses Netzwerk cool findet. Aber was ist, wenn nächste Woche Yigg in ist und Ende September alle Welt auf StumbleUpon fliegt? Nochmal 30 Templatedateien in den basic-Ordner und wieder 50 Dateien manuell nachbearbeiten?

Konzentriert Euch doch lieber auf einen sauberen, stabilen Kern, eine perfekte Produktpräsentation und gute Anbindungen an Zahlungsdienste. Kümmert Euch um Onpage-Suchmaschinenoptimierung. Und haltet bitte die Templates übersichtlich und schlank.

Ich bin fest davon überzeugt, dass diese Strategie uns und Euch eine Menge Fehler und Zeit sparen würde.

Alex

Wer sagt, dass du die Facebook-Optionen in deinem Template lassen musst? Schmeiss die doch raus und beim nächsten Update musst du die Facebook-Anpassungen auch nicht nachziehen. Auch die Trusted-Shops-Abfragen, kannst du rausnehmen.
Und für die Produktepräsentation ist aus meiner Sicht nicht Oxid zuständig, sondern du. Nämlich indem du dein Template so weit anpasst, dass du gegenüber deinen Kunden die Produkte möglichst optimal veranschaulichst. Das muss von mir aus im Standard-Template gar nicht der Fall sein. Ich habe lieber, wenn mir Oxid die Funktionen zur Verfügung stellt, um die Produktepräsentation möglichst gut einrichten zu können. Für das Design bin dann ich oder unser Grafiker zuständig.

roland76
ich habe das so verstanden, das das alles schön und gut ist, es aber viele gibt, die sagen - lass mal brauch ich nicht. Dein Vorschlag “Alles in Standard rein” und jeder soll selber raus hauen die vielen Codes und Abfragen, ist nicht der richtige Weg. Da denkt Ihr an Eure Kunden vorbei und beschert denen umsonst Arbeit und Kosten.
Der Königsweg wäre schon, wie Hupi sagte: Oxid macht sauberen Grundshop und bietet dann solche Gimmicks als Modul an. Und [U]nur der - der es auch will[/U] klickt es an und es erscheint aktiv im Shop.
War nicht irgendwann mal das als Revolution von Oxid gefeiert, wie gut und sauber man Module/ Erweiterungen integrieren kann?

Und bitte nie vergessen, Oxid, der Shop muss verkaufen. (meine Kunden sind 40+)
Dort ist Nix mit Facebook, Twitter, oder IPhone. Ihr vergesst manchmal die normalen Internetuser!!! Unbedarft, normal, die einfach was kaufen wollen.
Und mit diesem Facebook ist in der Detailseite zu viel drin!
Stichwort Usability

Ich schließe mich der Hupi Meinung voll an.

[QUOTE=Pille;35570]
Da denkt Ihr an Eure Kunden vorbei und beschert denen umsonst Arbeit und Kosten.[/QUOTE]
Ich bin nicht von Oxid. Ich habe weder Aktien dieser Firma, noch bekomme ich monatlich mein Gehalt aus Freiburg. Ich passe hier im Forum neben anderen Leuten einfach auf, dass die Diskussionen in einem würdigen Ton geführt werden.

[QUOTE=Pille;35570]
Der Königsweg wäre schon, wie Hupi sagte: Oxid macht sauberen Grundshop und bietet dann solche Gimmicks als Modul an. Und [U]nur der - der es auch will[/U] klickt es an und es erscheint aktiv im Shop.[/QUOTE]
Bin ich nicht der Meinung. Aus meiner Sicht soll Oxid ein Beispieltemplate zur Verfügung stellen, in welchem die Möglichkeiten aufgezeigt werden. Dieses kann dann nach den eigenen Wünschen angepasst werden. So wie es jetzt ist. Unser Template hat nicht mehr so viel zu tun mit dem Standardtemplate. Wir haben es unseren Wünschen und Bedürfnissen angepasst.

[QUOTE=Pille;35570]
War nicht irgendwann mal das als Revolution von Oxid gefeiert, wie gut und sauber man Module/ Erweiterungen integrieren kann?[/QUOTE]
Tut es doch auch. Aber warum soll Oxid alle Funktionen in Module auslagern, damit du dann bei den Updates jedes Modul updaten kannst?

[QUOTE=Pille;35570]
Und mit diesem Facebook ist in der Detailseite zu viel drin!
[/QUOTE]
Dann nimm es doch einfach raus. Sehe das Problem nicht.

Also ich muss Alex da voll zustimmen. Bei dem stetig größer werdenden Wust von Templates - da blickt bald keiner mehr durch - und der kurzen Taktung bei neuen Releases nimmt die Shoppflege immer mehr Zeit in Anspruch.
Die wirklich Erfolgreichen - siehe Amazon - machen es vor: simpler, übersichtlicher Aufbau und Konzentration auf das Wesentliche, nicht auf die Gimmicks.

Hi,

schön, dass hier jemand aufpasst, dass ich in einem würdigen Ton diskutiere :wink: Ich bin Oxid-Kunde der (fast) ersten Stunde (Seit Version 1.1.2) und denke mal, dass ich eher zur ruhigen, sachlichen Abteilung gehöre, aber egal.

Ich will mal ein Beispiel nennen: mit der Version 1.2 oder 1.3. wurde Points24 tief im System verdrahtet. Seit dem hab ich mindestens 20 Einträge in der oxconfig-Tabelle für diesen Dienst den ich nun bis zur 4.4 mit rumschleppe. Ich war in meinem ganzen Leben noch nicht bei Points24 angemeldet und mittlerweile spricht auch kein Mensch mehr von diesem Bonussystem. Genauso kamen und gingen viele andere Dienste im Oxid-Backend. Was bleibt ist eine Menge Müll in den Tabellen und vollgeklarte Templates (wer kennt noch Preishammer :wink: ).

Ich bin nach wie vor von Oxid überzeugt, es ist einfach das beste Shopsystem auf dem Markt. Trotzdem wollte ich mal zum Nachdenken anregen wohin in Zukunft die Reise geht.

Könnte man nicht z.B. ein Social-Media-Pack anbieten? Oder ein Trusted-Shop-Pack?

Vielleicht könnte man ja in die Standard-Grund-Templates Hooks einbauen die genau zwischen irgendwelche Boxen dann spezielle Zusatzcontainer includen?

Ich wäre wirklich für schlankere, aufgeräumtere Templates mit Zusatzerweiterungsmöglichkeit bei Bedarf.

Gruß
Alex

[QUOTE=roland76;35559]Wer sagt, dass du die Facebook-Optionen in deinem Template lassen musst? Schmeiss die doch raus und beim nächsten Update musst du die Facebook-Anpassungen auch nicht nachziehen. Auch die Trusted-Shops-Abfragen, kannst du rausnehmen.
Und für die Produktepräsentation ist aus meiner Sicht nicht Oxid zuständig, sondern du. Nämlich indem du dein Template so weit anpasst, dass du gegenüber deinen Kunden die Produkte möglichst optimal veranschaulichst. Das muss von mir aus im Standard-Template gar nicht der Fall sein. Ich habe lieber, wenn mir Oxid die Funktionen zur Verfügung stellt, um die Produktepräsentation möglichst gut einrichten zu können. Für das Design bin dann ich oder unser Grafiker zuständig.[/QUOTE]

Das sehe ich genauso! So muss man nicht suchen, wie man was integriert, sondern alle Smarty-Tags sind vorhanden.

Zu mehr ist doch das OXID-Standard-Template gar nicht gedacht; oder sehe ich das falsch?

Mir ist auch bewusst, dass viele Betreiber mit diesem Template starten. Aber es ist doch einfach die Frage, ob das ein “Bastler-Shop” oder ein “Profi-System” sein soll.

[QUOTE=Hupi;35585] (wer kennt noch Preishammer :wink: ).

[/QUOTE]

japp, teuer bezahlt, nie funktioniert :o

[QUOTE=Hupi;35585]Könnte man nicht z.B. ein Social-Media-Pack anbieten? Oder ein Trusted-Shop-Pack?[/QUOTE]
Das wäre sicher die beste Lösung, um das System nicht zu überfrachten…

Allerdings habe ich die Befürchtung, dass die OXID AG heftig an der “Featureritis” erkrankt ist, und genau den anderen Weg gehen will: “Out-of-theBox” die eierlegende Wollmichsau zu liefern.

IMO wird das allerdings niemals alle zufrieden stellen können, überfrachtet aber das System mit unnötigem Code.

Und überfordert den Anwender, der das ja auch immer alles in seinen Template-Code integrieren muss, ob er es nun braucht oder nicht.

Die wenigsten Anwender werden beurteilen können, ob eine Template-Änderung in einem Update für Sie notwendig ist oder nicht.

Wenn man schon so ein komfortables und leistungsfähiges Modulsystem hat, sollte man es auch für einen modularen Shop-Aufbau verwenden.

Das der Demoshop bzw. die Standardversion, die von Oxid geliefert wird, alle Features hat, die das Sytem kann, ist ja okay, aber die Art und Weise, wie z.B. so was wie Facebook implementiert wurde ist ziemlich für die Füße.

Warum wird das nicht in ein eigenes tpl gepackt und includiert (oder wie das heißt) - so, wie es mit der product.tpl gemacht wird.

Das würde die tpls übersichtlicher machen.

Grundsätzlich würde ich es begrüßen, weniger Updates zu bekommen, die dafür aber keine neuen Baustellen aufmachen. Ich hab das Gefühl, es wird momentan einfach nur noch zusammen geklascht, ohne groß darüber nachzudenken.

na frank ist doch ganz einfach, jedenfalls aus oxid sicht - ratzfatz immer wieder alles quartal neue features, die ja von UNS gewünscht wurden reinklatschen, ein paar bugs, die wieder von UNS gefunden wurden, ausmetzeln, ob richtig ausgemetzelt wurde, finden ja auch wieder WIR raus und wir blöden deppen kunden, die für all das unsere PARTNER beauftragen zahlen den ganzen käse doppelt, dreifach und noch mehr.

WER bitte hat eine funktionierende 4.4. laufen wo ALLE bugs aus den alten versionen wirklich raus sind OHNE neue bugs gefunden zu haben - dat geht nie nimmer und gibts nie nicht.
irgendwas ist immer wieder buggy ach nee sind ja features und keine bugs mehr …

Dito, ich stelle es mir folgendermaßen vor.
Beispiel details.tpl -> facebook Modul.

In der details.tpl wird eine Funktion aufgerufen, welche

  • die aktiven Module kennt
  • im Template-Ordner nach ein Verzeichnis sucht, welches so heißt wie das jewailige Modul (./out/basic/facebook)
  • in diesen Ordner wird dann wiederum nach einer details.tpl gesucht (./out/basic/facebook/details.tpl)
  • wenn diese Datei vorhanden ist, wird diese eingebunden. - Fertig

Ich finde sowieso, je mehr einzelne Dateien es für das Template gibt, desto einfacher sind die Updates.

Weil, wenn ich ein Template angepasst habe, sehe ich das ja (Anhand des Datums bzw. Dank Subtemplating).

Wenn ich aber so etwas wie die details.tpl anpasse, habe ich bei jeden Update richtig Spaß. :mad:
Wenn es aber Untertemplates in der details.tpl gibt - zB. für die Attribute - dann passe ich nur das Attributtemplate an und die eigentliche details.tpl bleibt unverändert.
So muss ich bei einen update nur auf das Template schauen, welches die Attribute darstellt.

Andersherum kann ich auch die details.tpl anpassen, welche nur noch die HTML-Struktur besitzt und den Details dementsprechend eine komplett neue Struktur geben ohne mich bei einen Update um die Attribute oder Bilder oder was auch immer kümmern zu müssen.

[QUOTE=simply because;35601]Das der Demoshop bzw. die Standardversion, die von Oxid geliefert wird, alle Features hat, die das Sytem kann, ist ja okay, aber die Art und Weise, wie z.B. so was wie Facebook implementiert wurde ist ziemlich für die Füße.

Warum wird das nicht in ein eigenes tpl gepackt und includiert (oder wie das heißt) - so, wie es mit der product.tpl gemacht wird.

Das würde die tpls übersichtlicher machen.

Grundsätzlich würde ich es begrüßen, weniger Updates zu bekommen, die dafür aber keine neuen Baustellen aufmachen. Ich hab das Gefühl, es wird momentan einfach nur noch zusammen geklascht, ohne groß darüber nachzudenken.[/QUOTE]

Hm, also ich plädiere auch dafür, dass Bug-Beseitigung Vorrang haben sollte. Allerings muss das System ja auch von den Features up to date bleiben. Das wird sicher immer ein Spagat sein.

Aber was ich einfach nicht verstehe: Warum verwenden hier alle, die die neuen Features nicht haben möchten, nicht einfach die bestehenden Templates weiter? Wer zwingt euch die weiteren Funktionen zu nutzen? Das verstehe ich einfach nicht?

[QUOTE=laramarco;35606]OHNE neue bugs gefunden zu haben - dat geht nie nimmer und gibts nie nicht.[/QUOTE]
Ja, da hast du recht. Software ohne Bugs gibts nicht. Ob diese nun von Oxid, Apple, Microsoft oder irgendeiner Wald-und-Wissen-Firma kommt, Software wird immer Fehler haben. Das die vergangenen Releases zu viele Käfer hatten, ist wohl unbestritten. Das schreit irgendwie nach einer Betatest-Phase.

Aber was ich einfach nicth verstehe: Warum verwenden hier alle, die die neuen Features nicht haben möchten, nicht einfach die bestehenden Templates weiter?

Mach ich ja, trotzdem muss ich 38 geänderte Templates durchsehen ob sich nicht doch etwas wesentliches verändert hat. Z.B. wurde im Review-Form in der details.tpl ein hidden-input entfernt - vielleicht aus Sicherheitsgründen? Ich bin quasi gezwungen, jedesmal 1,2 Stunden das alles durchzuackern obwohl ich das wenigste davon brauche.

Übrigens find ich die Idee von Mba total super - das wäre ein schöner modularer Aufbau. Müsste man echt mal etwas drauf rumdenken.

Gruß
Alex

[QUOTE=roland76;35613]Das schreit irgendwie nach einer Betatest-Phase.[/QUOTE]

und DAS obwohl es die Version 4 schon 2 Jahre gibt, und das obwohl WIR von unseren Umsätzen leben müssen, und das obwohl es massenweise Shops gibt, die ne horrende Angst vor einem Umzug haben - ja warum wohl ??

ich kann all diese EE2.7er Shops durchaus verstehen, und hätte ich mein eigenes Chaos vorher vorhersagen können, ich gebe zu 200% zu, ich wäre NICHT auf einer 4.

ICH WILL endlich einen Shop der mir Umsatz bringt, einen womit ich im kommenden Saisongeschäft punkten kann, einen wo nicht zig hunderte Kundenmails kommen “eia das geht nicht, ich würd so gern” und ich bekomme viele Mails gar nicht erst gemeldet, weil der Kunde schwups WEG ZUR KONKURRENZ ist.

hey ja das ist PECH, einfach nur PECH. neeee das mein Geld, mein Verlust, mein Ärger und verdammt noch mal meine ZEIT, die ich sinnvoller auch mit was anderem nutzen könnte - z.b. mit URLAUB oder einfach mal FREIZEIT.

[QUOTE=Hupi;35615]
Übrigens find ich die Idee von Mba total super - das wäre ein schöner modularer Aufbau. Müsste man echt mal etwas drauf rumdenken.[/QUOTE]

Ja, der Ansatz ist auch nicht schlecht. Wobei ich evtl. noch darüber nachdenken würde, ob man nicht alles, was zu einem Modul gehört auch in ein Modul-Verzeichnis packen könnte. Also

 -> modules/modul_name_123/views
 -> modules/modul_name_123/out
 -> modules/modul_name_123/core

Aus meiner Sicht wäre es wirklich ein echtes Feature, wenn man sich die ganzen Fremd-Integrationen separat laden könnte und diese dann bei Bedarf in die (Kern-)Templates integrieren könnte.
Das sehe ich auch so, den Shop zu Pflegen wird von mal zu mal aufwendiger und nimmt immer mehr Zeit in anspruch, das eigentliche Kerngeschäft ( Verkaufen ) sollte doch im Vordergrund stehen. Die Idee mit den Modulen für die Features finde ich eigentlich gut, weiss aber nicht ob das so einfach gehen würde.

gruß Sven

[QUOTE=jkrug;35625]Ja, der Ansatz ist auch nicht schlecht. Wobei ich evtl. noch darüber nachdenken würde, ob man nicht alles, was zu einem Modul gehört auch in ein Modul-Verzeichnis packen könnte. Also

 -> modules/modul_name_123/views
 -> modules/modul_name_123/out
 -> modules/modul_name_123/core

[/QUOTE]

Ich sitze drann. :wink:
[B][QUOTE=MBa;31003]
[ul]
[li]Jedes Modulverzeichenis (/modules/moduleName) soll die gleiche Verzeichnisstruktur haben wie Oxid selber (admin, core, views, out, modules).
[/li][li]Dementsprechend sollen die Klassen auch hier autom. geladen werden. Dank spl_autoload_register kein Problem.
[/li][li]Auch die Templates sollen automatisch geladen werden. Folgende Reihenfolge: Subtemplate, Maintemplate (basic), Moduletemplate.
[/li]Dies geht, bei den Modulen leider nur mit relativen Pfaden.
[li]Auch i18n ist kein Problem.
[/li][li]Das definieren des Adminmenus geht dank der menu.xml schon sehr gut… Könnte aber auch durch Konvention im Bezug auf Klassen und deren Methoden automatisiert werden.
[/li][/ul][/QUOTE]
[/B]

[QUOTE=jkrug;35608]Hm, also ich plädiere auch dafür, dass Bug-Beseitigung Vorrang haben sollte. Allerings muss das System ja auch von den Features up to date bleiben. Das wird sicher immer ein Spagat sein.
[/QUOTE]
Bugbeseitigung schön und gut, aber dann bitte so, dass keine neuen Bugs einbaut werden.
Ich erinnere mich noch an ein Gespräch mit Eric als wir zurück auf den Oxid gewechselt sind. Er hat so von dem neuen System zum Testen geschwärmt und was dadurch alles einfacher wird. Hörte sich echt einleuchtend an. Weniger Bugs, schnellere Buglösung usw…
Alles ganz toll. Nur als Kunde habe ich momentan das Gefühl, das dieses System zum Testen gar nicht genutzt wird. Da wird links was geschraubt und rechts neue Löcher aufgemacht. Das kann doch nicht Sinn der Sache sein.

[QUOTE=jkrug;35608]
Aber was ich einfach nicht verstehe: Warum verwenden hier alle, die die neuen Features nicht haben möchten, nicht einfach die bestehenden Templates weiter? Wer zwingt euch die weiteren Funktionen zu nutzen? Das verstehe ich einfach nicht?[/QUOTE]
Das geht ja nicht so einfach.
Die tpls muss ich so oder so anfassen, denn, egal wie die neuen Features implementiert werden, in dem tpl ändert sich etwas und ich muss nachsehen, was sich geändert hat. Und wenn es nur das auskommentieren von 'ner Kleinigkeit ist. Aber darum geht es ja nicht. Es geht um die Art und Weise, wie neuen Features in die tpls geklascht werden - siehe Facebook. Da hat sich doch keiner Gedanken drüber gemacht oder wie kann es sein, dass die Liste der Varianten ganz am Ende der Detailansicht erscheint? Mir ist’s egal, weil ich mich mit den tpls einigermaßen auskenne und weiß, was ich zu tun habe. Aber es gibt hier zig User, die das nicht können und völlig aufgeschmissen sind bzw. unnötig Geld ausgeben müssen, um sich das tpl einigermaßen nutzbar machen zu lassen.