Neu Template Snackys - verdammt schnell, inkl. Endless Scrolling, Checkout Funneling & Co.

css-umsetzung

Offizieller Servicepartner
SPBanner
6. Juli 2011
7.285
1.989
Berlin
Ich als Plugin Entwickler muss ganz ehrlich sagen:

Wenn ich in meinem Template alle Ressourcen raus werfe, die jeder Plugin Entwickler in einem JTL Shop erwartet (JavaScript, CSS, Bootstrap Ressourcen, Font Awesome usw.) dann kann ich auch der schnellste sein.

Ich denke aber das es nicht zielführend ist, denn wenn ich mir jetzt meine Plugins anschaue, wie die in diesem Template aussehen und dann schaue was ich alles tun müsste damit diese dann wieder vernünftig aussehen bzw. wie gewohnt funktionieren, dann muss ich ehrlich sagen, das ich mir das anpassen dann von jedem einzelnem bezahlen lassen werde.

Es kann doch nicht sein das nun jeder Plugin Entwickler sein eigens Font Awesome und Bootstrap oder jQuery mitbringen muss damit sichergestellt ist das die eigenen Plugins laufen?
Bisher haben sich alle Template Hersteller an die grundlegenden Möglichkeiten eines Evo Templates gehalten und es waren minimale Anpassungen erforderlich um mit den Templates kompatibel zu sein.

Mein Posting soll als Denkanstoß gesehen werden ob das wirklich der richtige Weg ist so eine Strategie zu fahren.
 
  • Gefällt mir
Reaktionen: Roddi und salepix.de

eRock Marketing

Offizieller Servicepartner
SPBanner
9. Januar 2018
503
204
Hallo @css-umsetzung

Vielen Dank für den Hinweis, daran sind wir schon ein paar mal gestoßen.
Aber alles wie JTL zu verankern kann nicht die Lösung sein. Auch wenn du z.B. 1 Funktion vermisst sind noch zick tausend überflüssig.
Klar macht es das seitens des EVOs einfach, das komplette Bootstrap ist da drin, die komplette Font Awesome, ... usw usw.
Aber wenn 30% der Icons genutzt werden, ist es dann wirklich richtig, die anderen 70% immer mit zu laden, weil ein Plugin das ggf. nutzen könnte?

Bin ich absolut dagegen ja.

Was wir aktuell jedoch planen ist: Einen Konfigurator für z.B. Bootstrap. Die Snackys Basics sind vorausgewählt und man kann eigenständig weitere hinzufügen.
Ggf. auch mit Scan der Plugins um das automatisch zu erkennen.

Dennoch finde ich muss der Weg ein anderer sein.
Auch Bootstrap hat starke Schwächen: z.B. Die Tabs in Bootstrap: Die sind schön einfach zu erstellen, aber: Die sorgen für ein Repainting beim Seitenladen.
Etwas das man zwingend vermeiden sollte. Und dabei ist das sehr einfach in der Basis - 2 Zeilen CSS und 4 Zeilen JS (in etwa) um Tabs zu realisieren.

Kurzum: Ich finde schon dass sich Plugins darum kümmern müssen dass die notwendigen Funktionen vorhanden sind, aber es wäre deutlich hilfreicher wenn man so etwas zentral steuern kann.
z.B. Welche Bootstrap Funktionen, wenn dann 2 Plugins sagen "Tabs" dann baut JTL die nur einmal ein... aber das ist wieder etwas ganz anderes.

Fazit: Wir haben das auf dem Schirm, wir werden aber definitiv NICHT den Weg gehen alles reinzuklatschen, dann nur 20% der Daten zu nutzen um zu sagen "wenn man will ist es da...". Das Ergebnis seitens Standard sieht man ja - einfach mal schauen wieviel von den Daten nicht genutzt wird. Das ist für mich unfassbar.
 

hula1499

Sehr aktives Mitglied
22. Juni 2011
5.284
1.218
Wenn ihr euch da schon unterhaltet, möchte ich das mal aus der Sicht des Anwenders sprechen.

Beide von euch kennen ja meine Meinung zu dem Thema, aber wenn wir schon public darüber reden...
Es ist einfach total bescheuert, dass ihr alle einfach "irgendwas" macht. Jeder meint, sein Weg ist der Richtige, jeder setzt Dinge voraus, ohne Weitblick zu haben (ihr wisst, dass ist nicht negativ gemeint).

Für mich war vermutlich der Shop 4 das allereletzte Custom Template, dasss nicht Evo/Nova/WieAuchImmer ist.
Es ist grottig, den Templatebauer fragen zu müssen, ob jetzt Ama Pay geht, das Zahlungsplugin funktioniert, warum da der Step nicht geht - und dafür dann im Endeffekt noch weitere Stunden zahlen zu müssen, nur weil einfach die Kompatibilität nicht vorhanden ist.

@css-umsetzung
Wir haben uns schon oft darüber unterhalten, ich versteh dich, mir gehts auch auf die Nerven, dass wir als Endkunden solche Hürden auferlegt bekommen. Dann müssen wir noch extra SP Stunden dafür zahlen und sind abhängig von den Zeiten, wann der Templateentwickler es machen kann...und/oder es überhaupt machen will.
Ich krieg jedesmal schon die Panik, wenn Ama / Mollie Update draussen ist und ich wieder XX Sachen beachten muss, gehts jetzt, brauch ich wieder irgendwelche Template Anpassungen - testen etc. Das ist Geld/Zeitverschwendung.

@KnoellMarketing
Auch wir hatten das Thema schon mehrmals - konstruktiv - besprochen.
Du hast im Grunde ja recht, dass gerade Bootstrap und Font Awesome einfach tonnenweise Müll mitbringt, die "keiner" braucht, alles aufbläht und vollkommen sinnlos ist, wenn man es GERADE nicht braucht.
Sollte man es jedoch brauchen (dies gilt auch für alle Funktionen, Hooks ... die Evo mitbringt) dann muss es irgendwie einfach für alle möglich sein, es zu aktivieren.
Aber, hier möchte ich auch Kritik loswerden (die du ja auch schon kennst), welche uns ja dann im Endeffekt davon abgehalten hat/abhalten wird, Snackys einzusetzen: mit deinem Shop 4/5 Zwitter-Template ladest auch wieder massenhaft Funktionen aus Shop 4, die du dann im 5er nicht brauchst (ausser ihr macht jetzt, anders wie letztens vermittelt, wirklich ein autarkes 5er Template).

Jeder schiebt es auf den anderen, wir (Template/Pluginkäufer) sind aber die einzig Leittragenden davon. Ihr müsst irgendeinen Weg finden, JTL muss irgendeinen Weg finden, hier klare Vorgaben zu machen die einzuhalten sind und nicht, dass jeder einfach "irgendwas" machen kann.


Ich mag Snackys, ich bin speed-fanatiker ihr geht den richtigen Weg, aber es muss "100%"ige Kompatibilität vorhanden sein!
 
  • Gefällt mir
Reaktionen: Deeloop

eRock Marketing

Offizieller Servicepartner
SPBanner
9. Januar 2018
503
204
Hallo @hula1499

vielen Dank auch für das Feedback.
Das haben wir stets gerne aufgenommen, unser Ziel ist ja nicht eine "neue Welt" zu schaffen und alle richten sich danach, sondern eben die passende Komponente zu bieten.
Auch da muss man sich etwas rantasten. So haben wir inzwischen z.B. alle JTL JS Funktionalitäten drin, wir haben Wege gefunden z.B. die Bildergallerie von JTL zu nutzen (für Detailseiten) ohne das Repainting usw. Aber: Jede Funktionsansprache klappt, Plugins die hier eingreifen genauso.
Wie @css-umsetzung richtig erwähnte haben wir das Bootstrap und JQuery minimiert - hier suchen wir Lösungen wie oben besprochen (mit JTL Shop 5 und dem OnPage Composer zwingt es auch in "mehr" Standardfunktionen). Aber wir sind einfach nicht vom Typ: Oh zu kompliziert, ich klatsche alles rein. Daher sind uns die Rückmeldungen auch recht um stets weiter zu optimieren.
Die Implementierung aller JTL Standards (Gallerie, IO, EVO Basic Class, ... - also jetzt mal aus JS Sicht) haben wir letztendlich auch realisieren können ohne Performance Verluste, aber das ging halt nicht mittels "Copy+Paste" wie es leider zu oft der Fall ist.

Zu Shop4/Shop5 Template - das ist vom Tisch, wir erarbeiten gerade eine letzte finale Shop 4 Version da wir denken dieser wird noch eine Weile genutzt werden.
Die Folgeversion wird dann jedoch nicht mehr Shop 4 kompatibel sein (sollten Bugs auftreten wird es natürlich Fixs/Patches geben).

Aber worauf ich stehen bleiben muss: Es geht nicht das ganze Bootstrap + Font Awesome in ein Template zu klatschen.
Aktuelles (4.5.0) Bootstrap: 157KB - dass ist NUR Bootstrap. Unser Template braucht pro Seite zwischen 60 und 80KB an CSS -und da ist schon ALLES an CSS drin (inkl. Bootstrap wie wir es kompiliert haben).
So etwas ist doch einfach kein Verhältnis. Aber: Wir haben das im Hinterkopf und werden eine Lösung finden - versprochen.
 
  • Gefällt mir
Reaktionen: hula1499

hula1499

Sehr aktives Mitglied
22. Juni 2011
5.284
1.218

css-umsetzung

Offizieller Servicepartner
SPBanner
6. Juli 2011
7.285
1.989
Berlin
Das Problem ist, das ich und auch andere Programmierer 4Jahre lang, nur Evo ableger oder Templates hatten, die gewisse Ressourcen mitgebracht haben die immer vorhanden waren. Wenn dann jemand, alles aus seinem Template entfernt und selbst img-responsive keine wirkung mehr hat, dann fasse ich mir an den Kopf und denke mir meinen Teil (nur als Beispiel zu sehen)

Das Problem ist aber, ich bekomme hier Anrufe, was für ein dummer programmierer ich doch bin weil alles so grottig aussieht und das ich gefälligst dafür zu sorgen habe das es aussieht wie beschrieben. Und das dann noch kostenlos.

Es kann nicht sein, das 5 Pluginentwickler ein modales Fenster oder die Tooltip Funktion benötigen und diese dann 5mal geladen wird.

Stell dir vor php entfernt jetzt den echo Befehl weil es ohne ja viel schneller lädt.... Spitze, nichts geht mehr und die php Entwickler sagen, na und dafür sind wir die schnellsten auf dem Markt, lade dir doch ne eigene library......

Sollen jetzt echt fünf Plugins, ein speziell konfiguriertes Bootstrap nachladen um die tooltip Funktion nutzen zu können?
Oder font-awesome Warenkorb Icons nachladen?

Ja, ich zicke gerade etwas rum, dass liegt unter anderem an den Sprüchen die ich momentan bekomme und wegen dem enormen Aufwand der dahinter steckt, diese Dinge in deinem Template Gerade zu biegen.

Und bringe ich und andere nur noch eigene Ressourcen mit, dann werden alle Shops automatisch langsamer.
 

eRock Marketing

Offizieller Servicepartner
SPBanner
9. Januar 2018
503
204
@css-umsetzung Ich kann deinen Unmut verstehen, aber bin definitiv anderer Meinung.

Meine (nicht zu genau nehmen) überspitze Gesamtmeinung ist: Ein überfülltes System wie es das EVO Template ist kann heute nicht mehr Bestand haben. Plugins die davon ausgehen dass all das vorhanden ist haben sich um das Thema Performance (zumindest im Frontend) bisher auch nicht gekümmert und dürfen das gerne mal tun :) Und: Ich freue mich nur aus diesem Grund im Shop 5 auf das Nova Template - damit fängt JTL selbst mal an nicht "zu eingleisig" zu fahren - wenn auch bisher weiterhin volle Frameworks einfach reingeklatsch sind. Wenn man sich ein System anschaut dass individualisierbar sein soll und dann davon ausgeht dass das Standardtemplate notwendig ist damit das System funktioniert...puh finde ich absolut und komplett den falschen Ansatz.
Es spricht aber freilich nichts dagegen zu sagen "na gut, es muss aber wenigstens Jquery mit Tabs und XY sein". Aber selbst die Sliderfunktion setzt eine ganze bestimmte JQuery Erweiterung voraus um diese vollständig nutzen zu können. Es geht doch auch anders bei vergleichbaren System: Es gibt nunmal gewisse Grundfunktionen die sein müssen - alles weitere ist Template/Pluginsache - und dann kann man auch vernünftige Lösungen erarbeiten.
Schaut man sich das aktuelle Nova an: Und wieder: Es wird der Nivo Slider geladen und der Slick Slider. Warum? Auch hier kann ich mich nur vergraben.
Thema Font Awesome:Hier sind Icons für Krankenhaus,einen "Fighter" und CO drin - für einen Webshop. Man sieht einfach dass sich hier keinerlei Gedanken gemacht wurde.
Und diesen Standard sind alle gewöhnt, weil bisher kein Hahn danach gekräht hat.

Und mit der Lösung Plugin A sagt ich brauche Tabs und Plugin B sagt ich brauche Tabs war nicht gemeint dass das 2x geladen wird, sondern das sowas im Core gemappt wird und ausgeführt a la "aha min. 1 Plugin braucht Tabs, also laden wir die Erweiterung". Wenn ein Template wie das EVO dann weiterhin sagt "mir schnurz ich brauche einfach ALLES" dann von mir aus, aber sinnvoll sehe ich es einfach nicht.

Mir ist jedoch bewusst dass sich viele an diesen "einfachen" Weg gewöhnt haben. Und sehe immer wieder wie overpowered Lösungen sind die so simpel sind. Da kann ich mir nur wirklich an den Kopf fassen. Beispiel: Ein Akkordeon zu nutzen mit nur 1 Eintrag um eine Info auf Klick auszufahren. Puh... wie wäre es mit .onclick => .show() ?
Ja das würde JQuery voraussetzen - so Grundbibliotheken lasse ich mir ja gerne gefallen. Die sind zwar prinzipiell nicht notwendig, aber machen vieles einfacher - vor allem Fehlertoleranter (wie viele Skripte würden abbrechen wenn die nach getElementById suchen und die ID gibt es nicht....)

Wie angesprochen: Wir werden hier eine Lösung integrieren dass man den ganzen Mist bis zum Umfallen dazu schalten kann. Und als Easteregg gar noch einen Megaklotz extra ;)
Auch lasse ich mir gerne gefallen manche Grundfunktionen von Haus aus dazu zu schalten, auch wenn das Snackys selbst das nicht braucht.
Dies aktuell zu umgehen ist jedoch auch sehr einfach: per Childtemplate lassen sich die Funktionen dazu laden - wir haben bewusst darauf geachtet z.B. Bootstrap Funktionen nicht zu ersetzen/zu doppeln damit man sich diese dazu schalten kann. In dem Fall wäre es also notwendig einfach die notwendigen Komponenten einzubinden und gut ist.
Das geht ja aktuell recht gut via dem Bootstrap Customizer.

Der Vergleich mit dem echo Befehl hinkt etwas - JQuery und Basic Bootstrap sind drin ;)

Insgesamt kann ich aber nur appellieren zukünftig sich darüber Gedanken zu machen ob es wirklich die ganzen Frameworks für wirklich banale Sachen sein müssen - so bequem das auch ist und bisher so funktionierte weil das einfach keinen juckt(e!) - Plugins sollten meiner Meinung nach Templateunabhäng sein, das Template ist letztendlich eine Komponente im System wie auch ein Plugin (nur eben für das visuelle). Die Gewohnheit hat es bisher im JTL System so wachsen lassen, was im globalen (siehe Konkurrenz) gar keinen Bestand hat.

Btw. wir haben es genau andersherum: Nicht jeder nutzt das Snackys (besonders bei Individualentwicklungen) und wir sollen den Shop dann schneller machen, wie soll das vernünftig gehen wenn wir wissen über die Hälfte wird nicht gebraucht, auch von keinem Plugin....


Kurzum: Ich verstehe dich - wirklich "Besonderes" setzen deine Plugins auch nicht ein, aktuell geht es leider nur via Childtemplate. Hat aber auch den Vorteil: Du schaltest nur dazu was wirklich gebraucht wird.
 

hula1499

Sehr aktives Mitglied
22. Juni 2011
5.284
1.218
Irgendwie muss es doch möglich sein, dass Template- und Pluginersteller "gemeinsam" zusammenarbeiten und da irgendeinen consens generell finden über/mit/für JTL.

Mit den jeweiligen Bedürfnissen des MARKTES und mal im Jahr 2020 ankommen (und keiner uralten wir machen noch immer alles wie in den 90ern, lade jeden Dreck, den "keiner" braucht).

Ich bin auch der Meinung, ein Plugin hat Templateunabhängig zu sein! Aber das Template muss es bewerkstelligen können, die komplette NOVA/EVO Standartfunktionalität zur Verfügung zu stellen, mit Option/per Knopdruck/per Scan/per Wünschelrute oder wie auch immer.

Findet sich ein Weg, ist es eine tripple-win situation (template, plugin, händler)....
 

hula1499

Sehr aktives Mitglied
22. Juni 2011
5.284
1.218
Nicht dass ich so ein Vorgehen verteidigen würde/möchte, aber andere Template Hersteller machen das doch genauso.... ich denk da auch nicht mehr drüber nach.
 

AN-DI

Sehr aktives Mitglied
22. Juli 2019
196
30
@hula1499 da muss ich leider widersprechen, ich kenne mittlerweile einen der vom Service richtig gut ist und nicht wegen jeder Kleinigkeit Rechnungen schickt sondern Meldungen von kleinen Bugs dankend annimmt.
 

ChrisTS

Sehr aktives Mitglied
15. Oktober 2010
530
156
Nicht dass ich so ein Vorgehen verteidigen würde/möchte, aber andere Template Hersteller machen das doch genauso.... ich denk da auch nicht mehr drüber nach.
Das geht definitiv nicht. Ist ja wie, wenn du ein Auto kaufst und es bereits vorab absichtlich Fehler eingebaut hat, um dann in der Werkstatt zusätzlich Umsatz zu erzielen.
Das Ganze sind versteckte Mängel und können so auf keinen Fall abgerechnet werden. Das ist Vorsatz und kann so nicht toleriert werden.

Stell dir mal vor, das bleibt so.
Jetzt hast du ein relativ günstiges Template gekauft, hast dann im Nachgang zusätzliche und nicht vorher kalkulierbare Kosten, die absichtlich generiert wurden.
Was ist dann beim nächsten Update oder beim Wechsel auf den 5er Shop. Soll ich dann auch für KnoellMarketing testen und die rechnen es wieder ab?

Bislang warte ich noch auf die Antwort. Eventuell ist da ja nur ein kleiner Fehler passiert und es wurde versehentlich abgerechnet.
Ist dem nicht so, muss ich aber natürlich sowohl meine eigene Leistung wie auch die weitere Leistung meiner zur Fehlersuche beauftragten ServicePartner in Rechnung stellen.
 
  • Gefällt mir
Reaktionen: AN-DI

eRock Marketing

Offizieller Servicepartner
SPBanner
9. Januar 2018
503
204
Vielen Dank für die Rückmeldung - wenn auch ich persönlich das nicht als den richtigen Weg sehe.

Bei @Truckstyler wurden Sonderanpassungen gemacht, abgerechnet wurden insgesamt nur 1,5Std.
Ein Beispiel: Der Slider - das Auslesen von Bildgrößen über den von uns implementierten Weg klappt auf dem Server nicht, da es die Bildbibliothek nicht unterstützt.
Wir haben dazu per Mail die Anpassung als CSS Angabe gesendet, auch wo und wie diese zu implementieren ist. Bis dato sind keinerlei Kosten entstanden - ich bin der Auffassung dass dies kein Bug ist, keine Inklusivleistung sondern ein Service von uns ist.
Darauf kam die Bitte dies von uns aus zu implementieren - nur das wurde dann auch zu dem Thema abgerechnet was auch zuvor klar kommuniziert wurde, dennoch war der Wunsch das durch uns im Childtemplate zu integrieren.

Auch haben wir die Anfrage zur Rechnung die an gleiche mehrere Empfänger ging bereits beantwortet.

Ich verstehe das Ziel dieses Postings ehrlich gesagt nicht.

Ich bitte die Aussage grundlegend zu überdenken. Gegen konstruktive Kritik ist nichts einzuwenden und berechtigte Rügen (natürlich ungern, aber das gehört dazu) lassen wir uns auch gefallen.

Ich werde mich dazu nicht weiter äußern, da es nach meiner Auffassung gar nicht hierher gehört.
 

Baby_Natur

Aktives Mitglied
17. Januar 2015
59
12
Also ich verfolge die Diskussion ja hier schon länger und finde es ehrlich gesagt schade, dass die Diskussion um die Sache (was kann das Template, wo sind die Probleme und was muss dringend verändert werden) jetzt so in den Hintergrund gerät.

Diskussionen um Abrechnungen und was sind Bugs oder nicht sollten an anderer Stelle geführt werden bzw. am besten DIREKT miteinander besprochen werden.
Und wenn ihr so euch nicht einigt dann lasst das die Rechtsverdreher machen. Mir wäre die Zeit zu Schade dafür.
 
  • Gefällt mir
Reaktionen: AN-DI

salepix.de

Offizieller Servicepartner
SPBanner
17. Januar 2013
496
50
Monheim / Köln
Firma
SALEPIX GmbH
Und wenn du auf einen Wartungs-Fix nicht warten kannst, sondern die Korrektur sofort haben willst, dann ist es doch völlig normal, dass dir diese Kosten verrechnet werden.
Wenn ich so was lese, dann weigert sich alles in mir als Entwickler diese Vorgehensweise zu akzeptieren... Sollte es einen Fehler geben, durch welchen der Betrieb des Shop beeinträchtigt ist, so hat der Entwickler diesen auf eigene Kosten und schnell zu korrigieren. (kundenorientiert ist) Ein absolutes No-Go, wenn für die eigenen Bug-Fixes die Rechnung gestellt wird. Was schreibt man denn bei den Positionen rein? "Korrektur der von uns verursachten Bugs?" ))))

Eine vernünftige Herangehensweise erkennt man daran, dass ALLE Kostenfragen VORHER durch den SP angesprochen werden. Sonst hat man am Ende eine Rechnung, mit der man nicht gerechnet hat. Der SP weiß immer im Voraus, dass er dafür Geld verlangen wird - also hat er das auch vorher dem Kunden mitzuteilen. Man darf sich also immer wundern, wenn Kosten anfallen, denn über diese Kosten hat der SP nicht informiert, somit konnte der Kunde nicht nein sagen. (Ich möchte KEINESFALLS etwas hier jemandem unterstellen)

Somit vermeidet man immer Probleme, wenn man ALLES was kostet VORHER bespricht.
 

ChrisTS

Sehr aktives Mitglied
15. Oktober 2010
530
156
@salepix.com > Da bin ich schonmal froh, dass ich nicht der Einzige mit der Einstellung bin.

Bevor ich nun aber für die Antworten im Forum auch noch eine Rechnung bekomme (Spaß) möchte ich zurück zum Thema und das Ganze hier abschließen.



Zum Template

In der aktuellen Version hat das Template bei mir die folgenden Fehler, welche zwingend behoben werden mussten:

  • Die template.xml bei Erstellung des Child-Templates ist fehlerhaft
  • Der Slider auf der Startseite ist fehlerhaft
  • Die Position des Trusted Shops Badge lässt sich in den Einstellungen nicht wie vorgesehen einstellen
  • Die News-Seiten lassen sich nicht in voller Breite anzeigen
  • Probleme mit der Formular-Validierung bei der Registrierung
  • Das Knoell-Suchplugin funktioniert nicht zusammen mit dem eigenen Template
Zum KM-SuchPlugin

  • Stößt man den Index manuell an, hängt sich die Suche völlig auf und zeigt nur noch den index der Startseite
  • Mobil muss man 2x in die Suche klicken, damit es nicht die alte Version (Suche) nimmt
  • Das Mapping geht nicht
  • Die Zurück-Buttons des Browsers sind ohne Funktion
Generelle Plugins

  • Plugins von Fremdherstellern funktionieren nur bedingt (gerade im Frontend-Bereich)
  • Die Zusammenarbeit mit weiteren SP’s in Bezug auf die Plugins scheint erschwert
  • Bei mir gab es so Probleme mit der BM-Suche, und CSS Zubehörartikel wie auch SD Bonuspunkte
Das Ganze verursacht in dem Fall nicht vorhersehbare Extrakosten und Aufwand, welcher vorab verhindert werden könnte. Nachdem ich mich nun beschwere, teilt man mir mit, dass ich nun nicht weiter betreut werde.

Evtl sollte in die Templates der abzusehende Mehraufwand gleich in den Endpreis eingerechnet werden oder die Kunden sollten deutlich auf die bestehenden Kosten und bekannten Fehler hingewiesen werden.

Die Schuld bei weiteren Plugins auf die Hersteller zu schieben, die alle samt, auf das Evo Template aufbauen halte ich auch für falsch.



Das war's, ich bin erstmal wieder raus….
 
  • Wow
  • Gefällt mir
Reaktionen: onit und MichaelH

ChrisTS

Sehr aktives Mitglied
15. Oktober 2010
530
156
@KnoellMarketing
"Die Position des Trusted Shops Badge lässt sich in den Einstellungen nicht wie vorgesehen einstellen "

Mir wurde ja ein Fix eingespielt, für den ich dann bezahlen sollte.
Nun wurde nichts am Shop geändert aber das Badge ist nun schon wieder rechts, wo es insbesondere den Warenkorb bzw. "Zur Kasse" überdeckt.
Die vorgesehenen Einstellungen im Template greifen wieder nicht.
Hat Trusted Shops hier was geändert? Wieso greift der Fix nicht mehr?

Wie machen wir es dieses Mal, dass ich den Fehler der den Kaufprozess behindert, schnellstens gefixt bekomme und nicht nochmals dafür eine Rechnung bekomme?