Das Problem ist eher, dass man sich neu orientieren muss... Was sich früher in der checkout_shipping befand, findet man jetzt in der Klasse in "system/classes/checkout/CheckoutShippingModulesContentView.inc.php"... Leider aber hat sich Gambio auch hier meines Vorschlags nicht angenommen, eine (überladbare) Methode einzuführen, mit der man beim Aufbau des Versandarten updatesicher prüfen kann, ob eine Zahlart angeboten werden soll, oder nicht. (Ebenso bei Payment.) http://www.gambio-forum.de/threads/...ta-1)-Download?p=106107&viewfull=1#post106107 Es ist zutiefst traurig, dass solche Dinge, die 2 Minuten Implementierung kosten, und sehr viel Flexibilität bewirken, kein Gehör finden,
Ein weiteres sinnvolles Feature wäre, nur die günstigste Versandart anzuzeigen. Die Kunden sind regelmässig damit überfordert eine Versandart auszuwählen und bestellen eine einzelne Schraube per Spedition für 180,- EUR in die Schweiz... (und bezahlen das auch noch!!!)
Das stimmt schon und ich bin auch Dankbar für deine Arbeit. Aber ich hatte es gehofft, dass Gambio diesen Punkt standardmässig mit einbaut. Es ist auch kein Beinbruch. War nur eine Hoffnung, dass sinnvolle Verbesserungsvorschläge auch ausgeführt werden. Allerdings es kann noch einiges kommen. Was der Daniel sagt, hört sich gut an und bis jetzt haben die Gambianer viel gemacht was in unserem Sinne gewesen ist.
Wo wir doch gerade bei den Versandarten sind: Das maximale Paketgewicht muss pro Versandart konfigurierbar sein. Derzeit ist das noch zentral definiert für alle Versandarten. Es gelten aber durchaus unterschiedliche maximale Paketgewichte bei den Paketdiensten. Wenn ein einzelner Artikel im Warenkorb schwerer ist als das in der Versandart hinterlegte Paketgewicht, dann darf diese Versandart nicht auswählbar sein! Derzeit wird der Artikel dann in mehrere Pakete aufgeteilt. DAS GEHT NICHT!
Ja, das Ding ist einfach auch, dass wir irgendwann einfach einen Cut machen mussten. Ihr wisst ja selbst wie lange wir schon an diesem Master Update sitzen und wir müssen nun einfach einmal eine finale Version herausgeben die vor allem einige Grundlagen schafft für die künftige Entwicklung. Es werden laufend gute neue Sachen umgesetzt, aber wenn wir jedes mal "nur diese coole Sache noch" mit aufnehmen würden, würden wir nie fertig werden. Es sollen ja zukünftig master Updates in deutlich kürzeren Zyklen erscheinen. Alles was hier also nun besprochen wird und es nicht mehr in 2.1 schaffst, muss nicht zwangsläufig wieder ein Jahr warten.> Wir sind gerade bereits dabei zu den einzelnen hier angemerkten Punkten etwas zu schreiben...
So ich habe jetzt zwei Versandmodule kopiert, umbenannt und die entsprechende Tabellen in der DB eingefügt. Es funktioniert, aber mit viel mehr Aufwand als bis jetzt. Eine Frage an Gambio. Gibt es auch eine einfache Methode eine Versandart zu kopieren und die entsprechende Datenfelder in der beide betroffene Tabellen in der Datenbank zu hochladen? Wird es irgendwann auch eine Beschreibung dazu geben?
Frische Beta2 auf leeren Webspace, fehlerfreier Installation, Zahlart "Vorkasse", Versandart "dhl" .... was fehlt? Ähm ... und sollte was fehlen, dürfe m.E. gar kein Bestellvorgang möglich sein! Soviel sollte man von einer nigelnagelneuen Software erwarten - oder?
So, habe ich jetzt, Danke dem Avenger für seinen Tipp, meine Versandsperre mit eingebaut. Es zeigt jetzt die folgende Fehler-Meldung, da er die Sprachdateien für die Versandmodule nicht findet!? Hat jemand einen Tipp?
Wenn Du die Sprachdateien aus Deiner alten Installation dorthinkopierst wo sie sein sollten, müsste das eigentlich funktionieren.
Dann bekomme ich die folgende Fehler-Meldung Ich meine ich muss hier eine Änderung machen: PHP: echo '<td>'.xtc_draw_pull_down_menu('gm_options_template', $files, $default_value, 'style="width: 220px"'); ?> </td> </tr> Füge danach ein: <tr> <td colspan="2" class="main"> <br />Welche Versandart/-en soll für dieses Produkt gesperrt werden? </td> </tr> <?php $forbidden_shipping_value = xtc_db_fetch_array(xtc_db_query("select configuration_value FROM configuration WHERE configuration_key = 'MODULE_SHIPPING_INSTALLED'")); $forbidden_shipping_value = explode(';',$forbidden_shipping_value['configuration_value']); $i = '1'; foreach($forbidden_shipping_value AS $forbidden_shipping) { $file = $forbidden_shipping; include(DIR_FS_CATALOG_MODULES.'shipping/'.$file); include(DIR_FS_LANGUAGES.$_SESSION['language'].'/modules/shipping/'.$file); $forbidden_shipping = str_replace('.php', '', $forbidden_shipping); $class = $forbidden_shipping; $module = new $class(); ?> <tr> <td align="right"><?php echo $module->title;?> sperren:</td> <td><?php echo xtc_draw_selection_field('forbidden_shipping'.$i, 'checkbox', $forbidden_shipping, ereg ( $forbidden_shipping, $pInfo->forbidden_shipping ) ? true : false); ?></td> </tr> <?php $i++; } echo '<tr><td colspan="2"> </td></tr>'; ?> <tr> Diese Änderung ist in der Datei "admin/includes/modules/new_product.php
Es ist auch eigentlich im Moment egal. Die Sache ist, wenn man die neue Umgebung testen sollte, dann sollte man auch eigentlich in der Lage sein diese Umgebung nach seinen Bedürfnissen einzustellen.
Mit dem Master Update 2.1 gibt es eine Reihe größerer Änderungen. Das kann zur Folge haben, dass ältere Module angepasst werden müssen und ansonsten nicht mehr ohne Weiteres lauffähig sind. Wir sind uns darüber im Klaren und wissen auch, dass es für jeden einzelnen, den es betrifft, ärgerlich sein wird. Dieser Schritt ist aus unserer Sicht jedoch eigentlich bereits lange überfällig. In vielen Bereichen haben wir uns inzwischen so sehr an die alten xtc-Gebilde gewöhnt, dass wir auf den ersten Blick gar nicht erkennen, dass diese Umsetzungen eigentlich grausam und nicht mehr zeitgemäß sind. Bislang haben wir mehr oder weniger mit Workarounds gearbeitet, die es uns ermöglicht haben, neue Funktionen und Verbesserungen umzusetzen, ohne dabei die grundlegende Struktur zu verändern, damit z. B. alte Module lauffähig bleiben. Uns ist aber bereits seit Langem klar, dass dieser Weg nicht ewig weiter beschritten werden kann, denn wir wollen, dass Gambio auch in einigen Jahren noch ein modernes Shopsystem ist. Wir haben nun also begonnen, neue Konzepte einzuführen. Bei jedem neuen Konzept haben wir uns sehr ausführlich Gedanken gemacht, vieles verworfen und uns am Ende dann für das Konzept entschieden, welches unserer Ansicht nach den besten Nutzen verspricht. Das bedeutet nicht, dass diese Konzepte keine Schwächen haben. Sicher werden wir Fälle übersehen haben und es wird auch Fälle geben, in denen ihrberechtigterweise sagen werdet, dass dieser oder jener konkrete Fall mitdem alten System besser zu lösen war. Wir werden jeden einzelnen Fall im Detail prüfen müssen und dann entscheiden, ob und wie man unser neues Konzept sinnvoll erweitern und anpassen kann und sollte, oder ob es im Einzelfall sogar tatsächlich Sinn macht, das gesamte Konzept noch einmal in Frage zu stellen. Um das gesamte Konzept zu beurteilen, muss man sich einfach die Zeit nehmen und alle Vorteile und alle Nachteile auf den Tisch legen und dann abwägen, welche Seite überwiegt. Es wird sicher Nachteile geben, aber wenn die Vorteile überwiegen, ist es eine Verbesserung zu vorher und das Konzept damit grundsätzlich bestätigt - was nicht heißt, dass es nicht nochverbessert und ausgebaut werden kann. Die Abwägung der Vor- und Nachteile müssen wir alle gemeinsam machen. Wir brauchen euch, denn ihr seid die Shopbetreiber, die mit unseren Konzepten in der Praxis arbeiten müssen. Wir hingegen betrachten nicht nur unseren eigenen Shop, so wie ihr es natürlich tut, sondern haben alle verschiedenen Arten von Shopbetreibern im Blick: die ganz kleinen, die ganz großen, die mit und die ohne Dienstleister, die mit individuellen Anpassungen und die Standardshops usw. All diese unterschiedlichen Interessen müssen wir unter einen Hut bekommen - und das werden wir auch. Ich bitte euch, nicht vorschnell Dinge zu verteufeln, nur weil Sie euch im ersten Moment nicht logisch erscheinen mögen oder Arbeit verursachen. Ich verspreche euch, dass wir an keinem unserer Konzepte hängen werden, wenn es sich als unpraktisch erweist. Ich bitte euch aber auch zu akzeptieren, wenn wir uns nach Abwägung aller Meinungen und Interessen dazu entschließen, bei einem bestimmten Konzept zu bleiben, auch wenn dies nicht euren Vorstellungen entspricht. Ich erinnere mich in diesem Zusammenhang noch gut an das Überladungskonzept. Auch das hat zu Anfang für viel Unmut gesorgt. Inzwischen sind wir uns, glaube ich, aber alle einig, dass es damalswichtig war, den Weg zu gehen, auch wenn das Konzept über die Zeit an vielen Stellen angepasst werden musste. Irgendwann muss aber der erste Schritt gemacht werden. Nun zu den einzelnen angesprochenen Punkten: Wir prüfen das gerade noch, es sieht aber nach einem Bug aus. Das sind keine Bugs, aber Unschönheiten. Wir haben das alsFeaturewünsche mitaufgenommen. Ungefähr seit es Gambio gibt, wünschen sich hunderte, wenn nicht tausende Shopbetreiber mehr Sprachpakete, um ihren Shop auf weiteren Sprachen anbieten zu können. Es gab dazu bereits mehrere Anläufe, die jedoch alle mehr oder weniger kläglich gescheitert sind. Zwar ließen sich auch bisher die einzelnen Sprachdateien übersetzen, das war jedoch sehr mühsam, fehleranfällig und für reine Übersetzer, die keine Ahnung vom Shop hatten, gab es keine Möglichkeit, einen einfachen Export aller vom Shop verwendeten Texte anzufertigen. Wenn wir aber Sprachpakete anbieten wollen, dann soll auch sichergestellt werden, dass bei Shopupdates auch die entsprechenden neuen oder geänderten Sprachvariablen von den Übersetzern berücksichtigt werden können. Danun alle Texte ausnahmslos in der Datenbank gespeichert werden, ist dies zukünftig kein Problem mehr. Zwar hatte man sich inzwischen schon an die alte Struktur mit mehreren unterschiedlichen Dateien, in denen Sprachvariablen zu finden waren, gewöhnt und irgendwie hat es auch funktioniert, aber von einer zeitgemäßen Sprachverwaltung konnte hier nicht die Rede sein. Mit dem neuen System haben wir nun die Grundvoraussetzung dafür geschaffen, das Sprachsystem in Gambio modern umzusetzen. Als nächstes wird ein neuer Spracheditor folgen, mit dem es dann z. B. auch möglich sein soll, bei der Kopie von Modulen auch entsprechende Sprachvariablen in der Datenbank zu kopieren u.v.m. Auch das sieht nach einem Bug aus, wir prüfen das. Wie gesagt, ist ein Bug. Das Überladen von Klassen soll natürlich nicht verhindert werden. Da hat sich eigentlich nichts geändert und es sollte auch alles noch vorhanden sein. Sieht ebenfalls nach einem Bug aus, den wir prüfen. Du hast leider Recht, an dem Punkt hat sich noch nichts gebessert und das tut uns genauso weh wie dir. Dieser Punkt steht ganz oben auf unserer Liste, wir haben aber schweren Herzens für die 2.1 aus Zeitgründen darauf verzichten müssten. Wir wollen das aber nun kurzfristig umsetzen, denn so wie es derzeit ist, nervt uns das selbst ständig. Stimmt, steht bei uns auch noch auf der Liste, aber eher als Unschönheit, von daher nicht mit ganz soviel Priorität. Doch, das sollte funktionieren, ich gebe aber zu, ohne vernünftige Doku machen wir es euch momentan nicht ganz einfachass da in CachedDirectory die Verzeichnisse noch nicht korrigiert wurden, ist richtig und ein Paradebeispiel dafür, warum man Code-Redundanz eigentlich vermeiden sollte! In diesem speziellen Fall haben wir uns allerdings dazu entschieden, die beiden Listen getrennt zu führen, da wir die CacheDirectory-Klasse mittelfristig auch für ganz andere Zwecke nutzen möchten als die Klassenerzeugung. Denkbar wäre im Extremfall, dass wir die CachedDirectory-Klasse auf das gesamte Dateisystem des Shops richten und dadurch Performance-Vorteile gewinnen. Das wäre dann aber ein ganz anderes Array, als wir es für dieMainFactory bräuchten. Darum haben wir diese beiden Dinge bereits jetzt voneinander getrennt.Das Handling gleichnamiger Klassen haben wir in der ClassOverloadRegistry untergebracht. Der Verzeichnisname eines Overloads einer Klasse mit doppelt vergebenem Namen braucht ein Präfix "Admin-", z. B. "Admin-order". Ein Beispiel hierfür haben wir mitausgeliefert und ist zu finden unter "user_classes/overloads/_samples/Admin-order". Das Verzeichnis "Admin-order" einfach mal eine Verzeichnisebene höher ziehen und einmal sämtlichen Cache leeren. Die Preise für Eigenschaften-Kombinationen können mit dem Master-Update 2.1.0.0 automatisch aus den Eigenschaften berechnet werden. Zum Teil ist es jedoch erforderlich, von dem "berechneten" Preis abzuweichen. Damit dies möglich ist, wurde der Kombinations-Festpreis eingeführt. Dieser repräsentiert einen festen Preis für die Kombination und steht nicht mehr in Verbindung mit den einzelnen Eigenschaftenpreisen. Der Festpreis bezieht sich also nur auf die Kombination und wird weiterhin dem Artikelpreis aufaddiert. Ein Modus, um den Artikelpreis komplett zu überschreiben, gibt es bislang nicht. Ein Lösungsansatz wäre, den Artikelpreis auf 0 zu setzen und die Endsumme für den Artikel direkt in der Kombination zu hinterlegen. Durch die Unterstützung der "ab"-Anzeige wird der Artikel nirgends mit 0 Euro ausgewiesen. Zu den Gründen, weshalb wir alle Sprachvariablen nun einheitlich in die DB verlegt haben, habe ich oben ja bereits etwas geschrieben. Es muss aber natürlich auch weiterhin möglich sein, mit externen Modulen zu arbeiten, die dieses Konzept bislang nicht unterstützen. Aus diesem Grund könnt ihr auch weiterhin mit Sprachdateien arbeiten. Es werden also beide Konzepte parallel unterstützt. Wollt Ihr also ein Versandmodul kopieren, könnt ihr für dieses Modul auch weiterhin mit Sprachdateien arbeiten. Unsererseits werden dafür auch Samples als Beispiel-Sprachdateien für die einzelnen Module bereitgestellt, welche z. B. bei den Versandmodulen in der Beta jedoch leider nicht mit vorhanden sind. Das holen wir aber noch nach. Dadurch, dass beide Konzepte funktionieren, sollte es eigentlich keine Nachteile geben. Das Ziel des Ganzen ist nämlich eben gerade nicht, zu einem geschlossenen System zu werden, sondern durch zeitgemäße Konzepte sich möglichst weit für externe Entwickler zu öffnen und Ihnen verschiedene Möglichkeiten und Freiheiten zu geben, Ihre Entwicklungen in Gambio zu integrieren. Ja, da ist viel geändert worden, aber das ist leider der Preis für das aufwändige Refactoring, das wir betreiben. Alles, was vorher möglichwar, ist aber auch weiterhin machbar, teilweise funktioniert es nur anders. Keine Frage, das ist ärgerlich für jeden, den es direkt betrifft, das Refactoring ist aber einfach notwendig und aus unserer Sicht alternativlos (eigentlich hasse ich dieses Wort). Darüber hinaus haben wir die artikelbezogenen Versandarten nun als Featurewunsch mitaufgenommen. Auch das haben wir mit aufgenommen. Ist eigentlich eine Kleinigkeit und sollte aus Usability-Gründen gemacht werden, aber auch aus den vielen kleine Dingen entsteht in der Summe ein großer Berg Aufgaben, den wir leider für die 2.1 nicht vollständig abarbeiten konnten. Der Shop ist da jetzt sogar flexibler als vorher, durch das Refactoring finden einige Dinge nun jedoch an anderen Stellen statt, als ihr das bislang gewohnt wart. Ich hoffe, dass wir euch dazu bald auch eine Doku bereitstellen können. Bis dahin beantworten wir eure Fragen gern für den konkreten Einzelfall. Das kann ich dir gar nicht genau sagen, es kommt aber sicher vor. Wenn es aber bereits gut funktionierende Module gibt, werden diese auch bald in 2.1 funktionieren. Es sind dann zwar Anpassungen seites der Entwickler nötig, für beliebte Module werden diese aber sicher gemacht werden. Wir haben das umgesetzt, jedoch etwas anders, als vorgeschlagen. In http://www.gambio-forum.de/threads/...ta-1)-Download?p=116407&viewfull=1#post116407hat Moritz das bereits für das Überladen von Payment/Shipping erläutert. Deine Lösung ist zwar etwas selbsterklärender, als unsere, wir wollten aber keine zwei Lösungen schaffen, um dasselbe zu erreichen und haben uns deshalb entschieden, bei unserer bereits vorhandenen Lösung zubleiben. Da kann ich nicht widersprechen Ist als Wunsch notiert. Sieht nach einem Bug aus, wir prüfen das, konnten es aber bislang noch nicht reproduzieren. Glaub mir, wir haben getestet und natürlich auch in den simpelsten Konfigurationen. Momentan können wir den Fehler noch nicht genau reproduzieren, aber irgendwo scheint es da einen Bug zu geben, der bei uns so jedoch nicht aufgetreten ist.
Ok, dann bin ich beruhigt. Möchte aber nochmal darauf hinweisen, dass ich das für ganz ganz wichtig halte. Mit "sehr einfach umzusetzen" habe ich auch gemeint, dass man da z.T. nicht mal einen externen Entwickler braucht, wenn man sich nur ein ganz kleines bisschen auskennt (Versandmodul klonen z.B.). Es wäre echt toll, wenn das so einfach bleibt und die oben erwähnte Doku so gestaltet ist, dass das auch normale Shopbetreiber verstehen. Weil solche Funktionen sind mMn schon eher ein unverzichtbares Muss und keine außergewöhnliche individuelle Anpassung mehr. Grüße Johannes
1. Der Umbau wie er jetzt im GX2 begonnen hat ist einfach notwendig!!! 2. Wird sich das mit Sicherheit noch einige Zeit hinziehen 3. Nach ersten kurzen kleineren Herzatacken, wegen -> ach du Sch... alles woanders.... Boar.... Nö... nicht da... Was ist das... usw. kann ich schon mal kleine Erfolge als Bilanz ziehen! Blog 3.1 wir auch für die 2.1 verfügbar sein! UND!!!! Es ist alles gar nicht so bescheiden gemacht. Ist eben neu und man fuchst sich durch. Sicherlich hier und da Verbesserungswürdig aber der Ansatz und die Richtung stimmen.... PS: Bin mal wieder im 2.1 Dschungel....
Und auf jeder Seite diese Warning:Warning: mysql_query(): 163 is not a valid MySQL-Link resource in /var/www/vhosts/gx21.indiv-style.de/httpdocs/inc/xtc_db_query.inc.php on line 68Warning: mysql_close(): 163 is not a valid MySQL-Link resource in /var/www/vhosts/gx21.indiv-style.de/httpdocs/inc/xtc_db_close.inc.php on line 30 das hat sich erledigt! War Serverseitig!!!! Allerdings besteht das Problem immer noch: PHP: So, Fehlermeldung beim überladen der GMSEOBoost:USER ERROR(256): "check_data_type validation failed. Dump: Indiv_GMSEOBoost Object ( [boost_products] => 1 [boost_categories] => 1 [boost_content] => 1 [boost_blog] => [boost_item] => [v_binary_string] => ) , GMSEOBoost-object expected, but Indiv_GMSEOBoost-object detected"Wenn ich den Ordner /user_classes/overloads/GMSEOBoost/ umbenenne in /user_classes/overloads/GMSEOBoost_ORIGIN/ gehts!Nur dann findet er duie Class nicht im Adminbereich!!!Class not Found in Registrtry.....
Kann es sein das Javascript-Dateien aus dem Templatesordner usermod/javascript/Global/ nicht eingebunden werden???? Hab dort meinen Slider drin und da tut sich gar nix....