Es soll ja jetzt eine Klassenüberladung auch im Admin möglich sein..... Es gibt da aber ein Problem: eine Diskrepanz der auf Klassen zu untersuchenden Verzeichnisse zwischen "MainFactory.inc.php" und "CachedDirectory.inc.php": "MainFactory.inc.php": PHP: $t_scan_dirs_array = array( DIR_FS_CATALOG . 'admin/includes/classes', DIR_FS_CATALOG . 'admin/gm/classes', DIR_FS_CATALOG . 'gm/classes', DIR_FS_CATALOG . 'gm/properties', DIR_FS_CATALOG . 'templates/' . CURRENT_TEMPLATE . '/source/classes', DIR_FS_CATALOG . 'system/controls', DIR_FS_CATALOG . 'system/data', DIR_FS_CATALOG . 'system/views', DIR_FS_CATALOG . 'system/request_port', DIR_FS_CATALOG . 'system/overloads', DIR_FS_CATALOG . 'system/extender', DIR_FS_CATALOG . 'system/classes', DIR_FS_CATALOG . 'system/core', DIR_FS_CATALOG . 'user_classes' ); D.h., die admin-Klassen sind hier in den Klassen-Scan einbezogen... "CachedDirectory.inc.php": PHP: $t_cache_paths_array = array( //DIR_FS_CATALOG.'admin/includes/classes', //DIR_FS_CATALOG.'admin/gm/classes', DIR_FS_CATALOG . 'gm/classes', DIR_FS_CATALOG . 'gm/javascript', DIR_FS_CATALOG . 'gm/properties', DIR_FS_CATALOG . 'system/controls', DIR_FS_CATALOG . 'system/data', DIR_FS_CATALOG . 'system/views', DIR_FS_CATALOG . 'system/request_port', DIR_FS_CATALOG . 'system/extender', DIR_FS_CATALOG . 'system/overloads', DIR_FS_CATALOG . 'system/classes', DIR_FS_CATALOG . 'system/core', DIR_FS_CATALOG . 'user_classes' ); D.h., hier werden die admin-Verzeichnisse ausgeschlossen, so dass insgesamt die Admin-Klassen nicht erfasst werden.... (Warum diese Verzeichnis-Definition 2 Mal??? Macht, wie man sieht, nur Probleme.) Ich konnten in der Klassen-Factory auch keinerlei Code finden, der gleichnamige Klassen in Front- und Backend unterscheidet (z.B. order.php, split_page_results.php,....). Was aufgrund der Programmlogik dazu führt, dass sowieso nur die Frontend-Klassen in die Registry aufgenommen würden (da ja der Klassenname der Index in einen assoziativen Klassen-Array ist)! Das mit der Admin-Klassenüberladung kann so aus mehreren Gründen nicht funktionieren..... Insgesamt werden auch alle Klassen im Frontend-"includes"-Verzeichnis nicht erfasst!!????
Deswegen mault er im Admin über eine nichtregistrierte Klasse aus dem Frontend.... Das ist mehr als unschön....
Immerhin sind jetzt die Admin-Klassen als "ORIGIN"-Klassen definiert, so dass ich endlich mein (funktionierendes) Admin-Overloading verwenden kann
Bei Eigenschaften: trotz eingestelleter Option "Kombinations-Festpreis" wird der Kombinationspreis zum Artikelpreis aufaddiert.
Die Sprachdateien sind einfach gelöscht worden, was meines Erachtens wirklich kontraproduktiv ist. Wenn man ein Versandmodul clonen will, wie clont man dann die dazu notwendigen Sprachvariablen?
Noch schlimmer: Wie bekommt man Sprachdateien integriert, die aus Nicht-Gambio-Modulen stammen??? Gambio entwickelt sich zum geschlossenen System.... Nicht gut! m:E. muss hier neben der DB auch geprüft werden, ob es noch eine entsprechende konventionelle Sprachdatei gibt. Das ist auch nicht schwierig, da in der Sprach-DB der "section_name" der Schlüssel zum Laden der Texte ist, und der entspricht zufällig dem alten Sprachdatei-Namen... z.B. "lang/german/modules/payment/banktransfer.php".... Das Gleiche gilt übrigens auch für alte "Smarty" Sprachdateien.
2.1 Beta 2: "Fehler: Das Verzeichnis \'images/slider_images/thumbails\' im Katalogverzeichnis ist schreibgeschützt:" Beim Aufruf von "Teaser-Slider" Villeicht dem "Installer" noch beibringen.
Das kann man leider nicht.... Weil die Server der "PHP-User" nicht immer erlauben, solche Einstellungen vorzunehmen.
Super, dass Ihr soviel testet. Macht bitte weiter so. Wir werden bestimmt nicht alles umsetzen können, werden aber jeden einzelnen Punkt checken. Dinge die sinnvoll aber zu umfangreich sind, werden wir evtl. nicht sofort machen, um möglichst schnell "final" gehen zu können, dann aber schnellstmöglich per SP nachziehen. @Aveneger Die von Dir genannten Punkte werden wir im Detail durchgehen und dazu dann auch jeweils noch etwas schreiben.
2.1 Beta2 Auch bei Artikelbezogene Versandarten sind keine Änderungen gemacht! Die Datei "checkout_shipping.php" ist zu der Massen geändert worden, dass man auch seine bishierige Versandsperr-Module nicht mehr verwenden kann. Da wir zwei Typen Artikel führen die teilweise gekühlt und teilweise ungekühlt versendet werden können, gibt es hier keine Möglichkeit, wenn der Kunde waren in seinem Einkaufskorb hat, die gekühlt versendet werden müssen, die nicht geeignete Versandarten auszuschalten! Das finde ich persönlich überhaupt nicht gelöst!
Das ist eine individuelle Anpassung in deinem Shop. Die kann nicht im Standard berücksichtigt sein. Wobei ich auch meine, daß das eine Funktion ist, die unbedingt im Standard enthalten sein muss. Jeder der Artikel verkauft, die nicht in ein Standard-Postpaket passen, benötigt diese Funktion!
Es geht aber nicht um individuelle Anpassungen. Es gibt bestimmt viele Fälle wozu man eine Versandsperre brauchen könnte. Deswegen gibt aus auch Module für dieses Bedürfnis. Es stört mich auch nicht, dass meine alte Modul damit nicht funktioniert, sondern dass es bei Gambio nicht standardmässig so ein funktion drin ist? Es gibt viele Funktionen, die selten oder gar nicht gebraucht werden.Aber Fünktionen, die selbstverständlich sind, aber nicht vorhanden sind!
Versandkostenberechnung in Warenkorb: Wählt man hier eine Versandart aus, muss man die Versandart im nächsten Schritt wieder auswählen, da die Auswahl hier wird überhaupt nicht berucksichtigt!?
Ich werde nachher oder spätestens morgen noch ausführlich etwas zu den einzelnen hier genannten Punkten und zum Master Update generell schreiben - bitte habt noch ein wenig Geduld @Cyrus Es gibt sehr viele Funktionen, die für sehr viele Shopbetreiber selbstverständlich erscheinen, die aber nicht zum Standard gehören. Diese Diskussion ist so alt wie Gambio. Ein Feature welches für Euch und vielleicht noch 500 andere Shopbetreiber wichtig ist, ist vielleicht für alle anderen uninteressant. Die wünschen sich stattdessen neue Sprachen für Gambio usw. Wie bereits angekündigt wird es in den nächsten Tagen ein Feature-Voting geben. Ihr könnt dann selbst entscheiden welche Features Ihr Euch wünscht und dann wird abgestimmt. Auch in der Vergangenheit haben wir aber bereits viele Eurer Vorschläge mit in die Entwicklung einfließen lassen. Wir werden aber niemals alles umsetzen können. In deinem Fall geht es um eine Versandkostensperre. Es ist gut möglich, dass diese für viele Shopbetreiber interessant ist. Ich kann das nicht so gut einschätzen wie Ihr, viele Anfragen dazu gab es aber bislang nicht, denn dann wäre das intern bereits besprochen worden. Wir werden dieses Feature aber mit zur Abstimmung stellen und dann werden wir einfach abwarten, was das Voting ergibt und uns danach richten.
ich denke, dass es nicht so viele Anfragen dazu gab, weil ein mehr oder weniger funktioniereder (anpassbarer) XTC-Modul gab (den verwenden wir auch). Jetzt werdet ihr mit Anfragen bombardiert, weil alte XTC Module eventuell nicht mehr funktionieren. Und bei Versand. bzw. Zahlart Sperre Modul ist es schon der Fall.
Wenn es da tatsächlich einen großen Bedarf gibt, wollen wir das unbedingt umsetzen. Ich habe das bereits für das Feature-Voting notiert. Ob das Modul jetzt nicht mehr funktioniert müssten wir mal prüfen, evtl. ist das ja auch mit ein Paar Anpassungen erledigt.
Cyrus: Die Versandkosteninformation im Warenkorb dient ja nur der ersten Information bevor der Kunde sich angemeldet hat. Eine verbindliche Auswahl erfolgt erst im nächsten Schritt nach der Anmeldung. Vielleicht lässt es sich ja umsetzen daß diese Auswahl nach der Anmeldung übernommen wird und der nächste Schritt dann übersprungen wird, weil er dadurch ja überflüssig wird. Noch besser: Den kompletten Checkout auf eine Seite packen...
Oh je, Leute, das geht gar nicht. Gerade die Versandoptionen müssen anpassbar sein, wenn der Shop nicht von selber flexibel genug ist. Das sind Sachen, die von der Natur der Waren vorgegeben sind, da sind wir Shopbetreiber nämlich z.T. überhaupt nicht flexibel - d.h. in dem Punkt muss der Shop flexibel sein. Solche Anfragen gibt's hier im Forum aber andauernd. Ich vermute mal, dass Module, die mit den Versand-Arten zu tun haben, eine der beliebtesten externen Anpassungen sind, oder nicht? Ich denke auch, dass der Mangel an Anfragen bei euch daran liegt, dass es bisher etwas einfach umzusetzendes gut funktionierendes dafür gibt. Grüße Johannes
Ja, ich habe Steffens OPC auch installiert. Der ist aber zumindest in 2.0.15.x noch inkompatibel zum Mediafinanz-Modul, weshalb ich das derzeit deaktiviert habe.