Der Bug wurde behoben: https://tracker.gambio-server.net/issues/39651 Um das Problem vorerst zu umgehen, hilft es den neuen PDFCreator einzuspielen, den wir mit dem 2.1-BETA2-Paket ausgeliefert haben. Der von euch beschriebene Fehler tritt nämlich nur auf, wenn dieser nicht vorhanden ist. Schöne Grüße, Daniel Wu
Adminbereich -> Sitemap Da gibts bei Sitemap-Konfigurieren als Sprache nur Englisch und ein Leerfeld. Beim Benutzen des Leerfeldes ist die sitemap1.xml leer! Getestet auf 2 Systemen!
Hier ein Beispiel für die Versandarten. Es handelt sich um einen Overload der CheckoutShippingModulesContentView-Klasse: PHP: class SampleShippingOverload extends SampleShippingOverload_parent{ /** * * @param type $p_versandarten_array * * array(2) { [0] => array(4) { 'id' => string(4) "item" 'module' => string(24) "Versandkosten pro Stück" 'methods' => array(1) { [0] => array(7) { 'id' => string(4) "item" 'title' => string(8) "Standard" 'cost' => double(2) 'radio_buttons' => int(0) 'checked' => int(1) 'price' => string(9) " 2,38 EUR" 'radio_field' => string(74) "<input type="radio" name="shipping" value="item_item" checked="checked" />" } } 'tax' => double(19) } [1] => array(4) { 'id' => string(4) "flat" 'module' => string(23) "Pauschale Versandkosten" 'methods' => array(1) { [0] => array(6) { 'id' => string(4) "flat" 'title' => string(8) "Standard" 'cost' => string(1) "5" 'radio_buttons' => int(1) 'price' => string(9) " 5,95 EUR" 'radio_field' => string(56) "<input type="radio" name="shipping" value="flat_flat" />" } } 'tax' => double(19) } } * */ public function set_quotes_array($p_versandarten_array) { // ... Logik, um Versandarten-Auswahl nach Belieben zu verändern ... $this->quotes_array = $p_versandarten_array; }}
Der Commit ist nur für die fehlerhafte Darstellung der Länderauswahl. Das Problem mit der Sitemap Generierung ist etwas umfangreicher und wird gerade von Daniel Wu bearbeitet. MfG
Dass deine Lösung die selbsterklärendere ist, bestreitet ja niemand und das haben wir ja auch so hier kommuniziert. Es gibt noch mehr solcher Stellen, von denen wir wissen und wo wir weiter Refactoring betreiben werden. Das ist ein Dauerprojekt, das wir stetig vorantreiben werden. Wie Daniel Schnadt schon schrieb, mussten wir irgendwann mal einen Cut machen, damit 2.1 nicht ein internes Dauerprojekt bleibt. Davon hat nämlich niemand was. Dazu gehören dann auch mal Entscheidungen sich gegen eine schöne neue Lösung zu entscheiden, wenn bereits eine funktionierende existiert. Glaub mir, das fällt einem als Entwickler echt schwer, da man dazu neigt "mal eben schnell" was zu verbessern. Dabei vergisst man aber, dass das auf Kosten anderer, höher priorisierten Verbesserungen geht. Man darf aber auch nicht vergessen, dass es ganz viele tolle Verbesserungen bzgl. des Refactorings gegenüber 2.0 gibt, die viele Eurer Wünsche berücksichtigen. Es gibt immer mehr Verbesserungswünsche, als umgesetzt werden können und wir können nicht alle gleich glücklich machen, da jeder ganz unterschiedliche Prioritäten hat. Das liegt nun mal in der Natur der Sache. Wir versuchen hier den besten Kompromiss zu finden. Das ist nicht einfach und wird uns auch nie perfekt gelingen. Daher freuen wir uns weiterhin über Feedback zu unserer Entwicklung und beziehen Euch in Zukunft z. B. mit dem Feature-Voting für das nächste Master-Update noch mehr in die Entwicklung ein.
Ich will das jetzt nicht zu Tode reiten, aber eine Bemerkung noch: Meine Lösung, die eigentlich jeder versteht, erfordert max. 5 Minuten Implementierungsaufwand.... Da muss man doch keine Grundsatzentscheidung fällen, die das Projekt evtl. verzögern. Genau so bei den einheitlichen Artikellisten. Da habe ich ja den kompletten Code mitgeliefert... Dank des Overloadings kann ich mir ja updatesicher meinen Weg implementieren, deshalb stört mich das auch nicht weiter. Ich verstehe nur nicht, warum solche Kleinigkeiten, die den Nutzen m.E. zweifellos erhöhen würden, nicht den Weg in die SW finden.
Es ist nicht so, dass uns bisher 5 Minuten gefehlt haben, sondern dass wir mehrere Hundert solcher "5-Minuten-Verbesserungen" haben, die noch nicht abgearbeitet wurden, weil sie anderen Aufgaben vorgezogen wurden. Es wünschen sich nicht nur die Avengers Verbesserungen, sondern auch die anderen Forenuser, die Support-Kunden über Mail und Telefon, die Supporter-Kollegen, die Customizer-Kollegen, die Partnermodul-Entwickler, die Partner selbst und schlussendlich die Core-Entwickler. Und jeder will zuerst mit höchster Priorität berücksichtigt werden. Wenn es mehr Arbeit als Zeit gibt, muss man priorisieren. Dazu gehört dann auch, dass niedrig priorisierte Aufgaben nicht erledigt werden, auch wenn sie seit Monaten oder Jahren bekannt sind. Die Prioritäten werden fortlaufend aktualisiert. Sollte eine lange bekannte, bisher niedrig priorisierte Aufgabe dringlicher werden, wird sie höher priorisiert und zwar immer auf Kosten einer anderen Aufgabe, es sei denn man schiebt das Projektziel zeitlich nach hinten. Ich kann sehr gut nachvollziehen, dass man das nicht wahrhaben will. Diese Diskussion kommt auch regelmäßig intern zwischen den Abteilungen auf. Man muss sich dann immer wieder den Stand der Dinge vor Augen führen, um zu verstehen, dass es in den allermeisten Fällen gute, nachvollziehbare Gründe für den aktuellen Fortschritt der Entwicklungen gibt und dass eben nicht Aufgaben grundlos außer Acht gelassen werden. Übrigens gibt es nur sehr, sehr wenige 5-Minuten-Aufgaben. Solch eine muss nämlich erst erfasst, dann umgesetzt und getestet und anschließend mit dem Einreichen der Lösung abgeschlossen werden. In konkreten Fall müsste deine Lösung gesichtet werden, anschließend im Trackingsystem erfasst, dann umgesetzt, darauf ein Test mit neuen Test-Overloadklassen und einer passen Shopkonfiguration durchgeführt werden, bevor das ganze eingereicht wird und damit wirklich erledigt ist. Das ist unmöglich in max. 5 Minuten zu schaffen. Wer aufmerksam war, stellt fest, dass ich die Dokumentation noch nicht einmal einkalkuliert habe. Im Kopf ist so manches "mal eben schnell", in der Realität leider nicht.
Bin gerade bei der Installation. Wiso ist denn der TCPdfCreator nicht im Paket? bedeutet es dass das VRRL 1.0.9 nicht enthalten ist?
Noch eine unwichtige Frage Gibt es einen Grund, warum im Template die YOOCHOOSE - Blöcke mit EOF anfangen und mit BOF enden?
Wie ist denn der gedachte Ablauf für DPD mit Delisprint jetzt nach dem Wegfall der Schnittstelle? Muss man dafür das "MyDPD Business / iloxx" Modul verwenden? Gibts dafür Testdaten? Wo bekommt man die UserID / Token her? Ist es inzwischen möglich mehrere Pakete mit der Schnittstelle für denselben Kunden / Bestellung zu erstellen (siehe (Link nur für registrierte Nutzer sichtbar.) Das ist für uns extrem wichtig, da wir oft mehrere Pakete machen müssen. Kein Versicherungsschutz in dem Fall ist ein absoluter Blocker. Sieht auch so aus, als ob die Schnittstelle keine Kleinpakete unterstützt. Auch das wäre wichtig, dafür gilt bei uns z.B. ein günstigerer Preis und DPD zickt wenn wir das auf dem Label als Normalpaket deklarieren. Ich kann nicht wirklich nachvollziehen, warum die Delisprint Schnittstelle wegfallen soll. Funktioniert bisher gut und unkompliziert.
Das Problem wurde gefunden und behoben: https://tracker.gambio-server.net/issues/39714 Schöne Grüße, Daniel
Wir haben tatsächlich gedacht die Schnittstelle braucht niemand mehr, wurden aber inzwischen von mehreren Seiten eines besseren belehrt. Kurzum: Die Schnittstelle kommt kurzfristig wieder rein.
Wilken: DelisPrint ist DAS Labeldrucksystem von DPD. Das benutzen alle DPD-Kunden die regelmäßig Pakete verschicken. Warum fragt ihr nicht einfach mal nach bevor ihr etwas rauswerft? Das ist, als wenn die Mineralölkonzerne mal eben Diesel von der Karte streichen und sagen, "Och... wir dachten das braucht keiner mehr."
Hallo, ich hatte Heute ein Telefonat mit Gambio. Dort sagte man mir, das das Master Update nicht nur ein paar Wochen länger dauert, sondern auch dieses Jahr nicht mehr fertig wird. Also weiter warten. Gruß Andreas