Hallo, zur späten Stunde hier das Master Update 2.1.0.0 als Preview 1. Das bedeutet, dass es sich um einen Zwischenstand unserer Arbeiten handelt und diese Version noch nicht den 100%igen Umfang der finalen 2.1.0.0 Version wiederspiegelt. Uns geht es um Euer Feedback. Wir würden uns also freuen, wenn ihr in euren Testshops das Master Update installiert und fleißig testet. Es ist zu allen Shopversionen ab 2.0.7c kompatibel. Beachtet, dass die nächste Preview- oder Beta-Version wieder einen 2.0-Shop voraussetzen wird und es wahrscheinlich kein Einzelupdate für die Änderungen zur neuen Preview/Beta geben wird. Erstellt also eine Kopie eures bisherigen Testshops. Später gibts sicherlich mehr Infos von uns. Jetzt ist Feierabend angesagt. UPDATE: Hier die Vollversion der Preview 1: http://www.gambio-shop.de/downloads/file.php?id=gx2-2_1_0_0_preview1-20131219 UPDATE 29.01.2014: Die Preview 2 vom Master Update ist erschienen und kann im Portal heruntergeladen werden: https://www.gambio-support.de/downloads/index/520a484c-5584-4725-8923-53bd5c2b6afd Die Vollversion der Preview 2 folgt in wenigen Tagen. Folgende Neuerungen und Änderungen gibt es gegenüber Gambio GX 2.0: - Standardzeichenkodierung ist UTF-8. Entsprechend können nun Zeichen anderer Sprachen und Sonderzeichen gespeichert werden - Überarbeitung der Bestellnachbearbeitung - Staffelpreise können komfortabler verwaltet werden - Abbrechen-, Aktualisieren- und Speichern-Button werden in der Artikelbearbeitung zusätzlich oben angezeigt - Anzahl der angezeigten Bestellungen auf der Bestellungen-Seite ist konfigurierbar - Neues CSV-Import/-Export-Modul mit dem Exportvorlagen frei konfiguriert werden können - Neues PayPal-Modul - SEPA-Lastschrift-Modul - AmazonPayments-Zahlungsmodul - E-Mail-Vorlagen sind nicht mehr Template-abhängig - Vereinheitlichung des Sprachsystems (Texte alle in der Datenbank) - Filtersystem weiterentwickelt (Filterverlinkungen sind möglich) - Eigenschaftensystem weiterentwickelt - "Google Rich Snippets"-Unterstützung - Sprachen können im Adminbereich inaktiv geschaltet werden, so dass sie im Frontend nicht ausgewählt werden können - Sprachen können auf Basis einer vorhanden Sprache kopiert werden - Texte, die in einer Sprache nicht vorhanden sind, haben als Fallback den entsprechenden Text der Standardsprache - Refactoring des Frontends (Auslagern von Code in Klassen) - Einführung von neuen Extendern im Adminbereich, um z. B. auf der Bestellung-Detail-Seite, Kategorien/Artikel-Übersicht oder Kategorie/Artikel-Bearbeitung Informationen oder Zusatzfunktionen eines Moduls anzeigen zu lassen - Neuer Updater, für die Installation von Master-Updates, Service Packs und sonstiger Einzelupdates - Fehlerkorrekturen UPDATE 25.03.2014: Die Beta 1 vom Master Update ist erschienen und kann im Portal heruntergeladen werden: https://www.gambio-support.de/downloads/index/520a484c-5584-4725-8923-53bd5c2b6afd Die Vollversion der Beta 1 folgt in wenigen Tagen.
Nach dem Update erkennt er die installierten Zahlungsweisen nicht! Zeigt immer die Meldung: Installieren Sie eine Zahlungsweise. Nach Deinstallation und Neuinstallation gehts.
Erste Eindrücke bezüglich des "Refactoring" der Checkouts.... Wird "checkout_process" auch noch als Klasse neu implementiert? Das ist eigentlich die wichtigste von allen! "checkout_payment", "checkout_shipping".... Ich habe (auch durch Überladung von "get_html") keine Möglichkeit, eigene Selektions-Kriterien für Zahl- und Versandarten anzuwenden, außer "get_html" in einem Overload komplett zu ersetzen... Ich würde mir folgendes wünschen: PHP: for($i = 0, $n = sizeof($selection); $i < $n; $i++) { if ($this->offer_payment($order,$selection[$i],????) { } } damit ich (updatesicher) entscheiden kann, ob ich eine Zahlart anbieten will.... Weiterhin: PHP: $this->add_selection_data($order,$selection,$i,????); $this->set_content_data('module_content', $selection); damit ich noch eigene weitere "selection"-Infos setzen kann. (Analog für die Versandarten) Damit kann ich diese Klassen überladen, und sehr selektiv in das Angebot von Zahlungs-/Versandarten eingreifen, und zusätzliche Informationen einbinden. Bei der "checkout_process" muss das ebenfalls so werden! Überall dort, wo Datenstrukturen aufgebaut werden, die in die DB geschrieben werden sollen, muss vor dem Schreiben der Daten in die DB die Möglichkeit existieren, zusätzliche Daten in die Struktur einzubringen. Für jede Datenart muss es eine eigene Methode geben.. $this->add_order_data($order,$sql_array)... $this->add_orders_products_data($order,$sql_array)... $this->add_attributes_data($order,$sql_array)... usw..... In der jetzigen Form des "Refactorings" kann ich nur die komplette "get_html" überladen, was zwar auch schon eine Verbesserung darstellt, aber m.E. nicht ausreicht... Vor allem erlaubt das keine sinnvollen Mehrfachüberladungen durch verschiedene Module.... Die Klassen sollten auch nicht mehr direkten HTML-Code erzeugen, wie z.B. die "CheckoutConfirmationContentView.inc.php": PHP: $data_products .= '</tr><tr><td class="table_products_space"></td></tr>' . "\n"; Das muss durch eine Template-Lösung ersetzt werden.
AUGENKREBS-ALARM!!!!! In "NewProductsMainContentView.inc.php" gibt es immer noch diesen Code... PHP: if(MAX_DISPLAY_NEW_PRODUCTS_DAYS != '0') { $date_new_products = date("Y.m.d", mktime(1, 1, 1, date(m), date(d) - MAX_DISPLAY_NEW_PRODUCTS_DAYS, date(Y))); $days = " AND p.products_date_added > '".$date_new_products."' "; } $products_new_query_raw = "SELECT p.products_id, p.products_fsk18, p.products_image, p.products_image_w, p.products_image_h, p.products_price, p.products_vpe, p.products_vpe_status, p.products_vpe_value, p.products_tax_class_id, p.products_date_added, p.gm_price_status, pd.products_name, pd.products_meta_description, pd.gm_alt_text FROM (SELECT p.products_id, p.products_fsk18, p.products_image, p.products_image_w, p.products_image_h, p.products_price, p.products_vpe, p.products_vpe_status, p.products_vpe_value, p.products_tax_class_id, p.products_date_added, p.gm_price_status FROM " . TABLE_PRODUCTS . " p WHERE p.products_status = '1' " . $group_check . " " . $fsk_lock . " " . $days . " LIMIT " . (int)MAX_RANDOM_SELECT_NEW . ") AS p, " . TABLE_PRODUCTS_DESCRIPTION . " pd WHERE p.products_id = pd.products_id AND pd.language_id = '" . $this->v_languages_id . "' ORDER BY RAND() LIMIT " . (int)gm_get_conf('GM_NEW_PRODUCTS_STARTPAGE'); if(version_compare(gm_get_env_info('MYSQL_VERSION'), '4.1') < 0) { $products_new_query_raw = "SELECT DISTINCT p.products_id, p.products_fsk18, p.products_image, p.products_image_w, p.products_image_h, p.products_price, p.products_vpe, p.products_vpe_status, p.products_vpe_value, p.products_tax_class_id, p.products_date_added, p.gm_price_status, pd.products_name, pd.products_meta_description, pd.gm_alt_text FROM " . TABLE_PRODUCTS . " p, " . TABLE_PRODUCTS_DESCRIPTION . " pd WHERE p.products_status = '1' AND p.products_id = pd.products_id AND pd.language_id = '" . $this->v_languages_id . "' " . $group_check . " " . $fsk_lock . " " . $days . " ORDER BY RAND() LIMIT " . (int)gm_get_conf('GM_NEW_PRODUCTS_STARTPAGE'); } $t_result = xtc_db_query($products_new_query_raw); MySQL < '4.1' ist wohl nirgendwo mehr im Einsatz.... Warum wird hier immer noch die Artikelliste "zu Fuß" aufgebaut???? Es reicht, die "products_id" zu selektieren, in einem Loop dann das "Product" zu erzeugen, und dann die Listen über "buildDataArray()" (oder wie immer das Ding heißt) konsistent(!) aufzubauen. Damit man man endlich überall konsistente Listen hat, die auch Überladungen von "buildDataArray()" berücksichtigen.... Mit Überladungen von "buildDataArray()" kann ich dann auch noch meine eigenen Daten dazu geben. Am Ende jedes Produkt-Loop-Durchlaufs dennoch auch eine Möglichkeit vorsehen, weitere eigene Daten in die Struktur einzubauen. $module_content=$this->add_user_content($product,$module_content,????); Die anderen Listen habe ich noch nicht angesehen..... Noch besser wäre allerdings eine "products_list"-Basisklasse, die die einzelnen Listen-Klassen beerben. Dieser Basisklasse muss man im Grunde ja nur jeweils eine anderes Listing-SQL übergeben, der Rest ist ja überall gleich...
"SpecialsMainContentView.inc.php" ist das gleiche Problem. "UpcomingProductsContentView.inc.php" ist das gleiche Problem. "TopProductsContentView.inc.php" ist etwa so, wie ich vorgeschlagen habe... Bis auf PHP: $module_content=$this->add_user_content($product,$module_content,????) ;
"application_top".... Alle "requires" und "includes" sollten über "get_usermod" aufgerufen werden, damit man eigene Versionen davon bereit stellen kann Also statt z.B. PHP: require_once (DIR_FS_INC.'xtc_db_connect.inc.php'); sollte das so sein: PHP: require_once (get_usermod(DIR_FS_INC.'xtc_db_connect.inc.php'));
Hallo, so ich habe da mal etwas getestet. Neuinstallation Problemlos! Update von 2.0.14.1 fehlgeschlagen Update von 2.0.9c fehlgeschlagen, das war eine funktionierende Neuinstallation. Bei beiden Updates hat der Updater bei „Bitte haben Sie ein wenig Geduld. Folgendes Update wird gerade installiert: v2.1.0.0 Preview1 „ nicht weiter gemacht. Daraufhin, kam dann auf der Startseite folgende Fehlermeldung. Code: WARNING(512): "SQL Error" in /var/www/webxxx/html/gx_209/inc/xtc_db_error.inc.php:33 (Details) Backtrace: #0 trigger_error called at [/var/www/webxxx/html/gx_209/inc/xtc_db_error.inc.php:33] #1 xtc_db_error called at [/var/www/webxxx/html/gx_209/inc/xtc_db_query.inc.php:68] #2 xtc_db_query called at [/var/www/webxxx/html/gx_209/includes/classes/language.php:70] #3 (#language_ORIGIN) language_ORIGIN called at [/var/www/webxxx/html/gx_209/includes/application_top.php:519] #4 include called at [/var/www/webxxx/html/gx_209/index.php:27] Datenlöschung erfolgte mittels Updater.
"CreateAccountContentView.inc.php" Auch hier fehlt eine Möglichkeit, eigene Daten in das Template einzusteuern. Vor PHP: $this->set_content_data('FORM_END', '</form>'); sollte etwa folgendes eingefügt werden: PHP: $t_form_data_array=$this->add_user_data($t_form_data_array,$p_guest_account,????); "CreateAccountContentControl.inc.php" Hier fehlt die Möglichkeit, eigene Daten zu prüfen und abzuspeichern Vor PHP: if ($error == false) { einfügen: PHP: if ($this->check_user_errors($this->v_data_array['POST'],$t_data_array,$p_guest_account,????)){ $error = true; } Vor PHP: xtc_db_perform(TABLE_CUSTOMERS, $sql_data_array); einfügen: PHP: $sql_data_array=$this->add_customer_user_data($sql_data_array,$p_guest_account,????); Vor PHP: xtc_db_perform(TABLE_ADDRESS_BOOK, $sql_data_array); einfügen: PHP: $sql_data_array=$this->add_address_book_user_data($sql_data_array,$p_guest_account,????); Grundsätzlich müssen solche Mechanismen in allen refactorierten Klassen vorgesehen werden, sonst ist das eigentlich sinnlos. Weil es ziemlich egal ist, ob ich direkt in einem Modul ändern, oder die komplette "get_html"-Methode überladen muss... Mit Änderungen wie vorgeschlagen kann ich aber selektiv die Dinge berücksichtigen, die mein Modul neu dazu gebracht/geändert hat. Und das funktioniert auch in einer Überladungs-Chain mehrerer Module (Plugins)! Was mit der Überladung der kompletten "get_html"-Methode nicht funktioniert, da ich ja dann keine "parent::get_html()" ausführen darf, weil ich sonst wieder die komplette Originalmethode ausführen würde! Und wenn man sich dann noch des Themas "Template Blöcke" annimmt ( http://www.gambio-forum.de/threads/9505-Template-Blöcke-für-Gambio-GX2 ), dann kann man Plugins bauen, die (bis hin zu Template-Erweiterungen) komplett automatisierbar installiert und deinstalliert werden können. P.S.: Auch das möchte ich, mal wieder, in die Diskussion einbringen. http://www.gambio-forum.de/threads/...der-VIEW-Klassen?p=89566&viewfull=1#post89566 Mit kleinen Anpassungen kann ich mir sehr viel mehr Flexibilität verschaffen.
Mal eine naive Frage zum 4.Advent: Werden Avenger´s Vorschläge Bestandteil des Masterupdates sein oder erst mit einem Update zum Update kommen?
Ich sach' mal so: ohne solche Möglichkeiten, gezielt eingreifen zu können, ist das "Refactoring" zwar ganz schön, aber dennoch ziemlich sinnfrei. Weil es keine wesentliche Verbesserung bei der Möglichkeit des updatesicheren Eingreifens in die Shop-Funktionen bietet. Und da das ja alles ein sehr überschaubarer Aufwand ist, muss das eigenlich in das Master-Update hinein, wenn es sich den Namen "Master-Update" verdienen will.
Wir bekommen die gleiche Fehlermeldung wie im Post #11. Update erfolgte von Ver. 2.0.14.0 PHP: WARNING(512): "SQL Error" in domain/inc/xtc_db_error.inc.php:33 (Details)Backtrace: #0 trigger_error called at [domain/inc/xtc_db_error.inc.php:33] #1 xtc_db_error called at [domain/inc/xtc_db_query.inc.php:68] #2 xtc_db_query called at [domain/includes/classes/language.php:70] #3 (#language_ORIGIN) language_ORIGIN called at [domain/includes/application_top.php:519] #4 include called at [domain/index.php:27]
Ich wünsche mir bei dieser Gelegenheit auch gleich eine ordentliche Dokumentation dieser "Andockstellen" für eigenen Code. Am besten so eine Art zweites Handbuch für Entwickler, wo drin steht, wo solche Stellen für eigene Anpassungen vorgesehen sind. Grüße Johannes
Das Preview lässt sich nicht komplett neu installieren..... In der Vollversion sind in "includes" nicht die "configure.php" und "configure.org.php" enthalten, so dass nicht automatisch auf den Installer verzweigt, sondern ein Fehler angezeigt wird. Es gibt auch nicht das Verzeichnis "gambio_installer", sondern nur "gambio_updater". "GambioUpdateControl.inc.php" setzt eine bestehende Installation voraus....
PHP: Query: INSERT INTO gm_configuration SET gm_key = 'PAYPAL_SIGNATURE', configm_valueguration_value = 'AFcWxV21C7fd0v3bYYYRCpSSRl31A1yx6d35D2diRGRPJmfoKlU76V61'Error message: Unknown column 'configm_valueguration_value' in 'field list' PHP: configm_valueguration_value sieht nicht nach einem sinnvollen Feldnamen aus....