Moin, Moin! Sitze gerade dabei ein Modul möglichst updatesicher für die 2.1 Preview 3 anzupassen. Dabei möchte ich gerne eigene Warnmeldungen implementieren. Möglichst natürlich direkt beim Aufruf des Admin-Bereichs, also in der admin/start.php. In der Version 2.1 sind die Möglichkeiten der Extender im Adminbereich ja ausgeweitet worden. Warum wird dieses nicht auch in der start.php eingebaut? Mein Lösungsansatz das stattdessen über die application_top zu machen führt leider zu unschönen Nebeneffekten auf der Startseite. Dann wird die Warnmeldung nämlich auch in die Statistiken und den URL-Aufruf mit den News+Partnerprogrammen eingebunden. EDIT: Okay, habe mir das gerade nochmal nach einer Mütze voll Schlaf in Ruhe angesehen. Das Problem besteht ja darin, dass die application_top.php sowohl in der start.php wie auch unter anderem in der gm_counter_action.php mit require eingebunden wird. Daher die wiederholte Ausgabe der Warnmeldung. Mit diesem Hilfskonstrukt in meiner Overload-Klasse für den AdminApplicationTopExtender habe ich das unerwünschte Verhalten unterbunden: Code: $pathinfo = pathinfo($_SERVER['PHP_SELF']); $requesting_file=basename($pathinfo['basename']); if ($requesting_file=='start.php') { require(DIR_FS_ADMIN.'includes/modules/meine_warnungen.php'); } Damit wird geprüft, welche Datei gerade versucht die application_top.php einzubinden. Immer wenn es nicht die start.php ist, wird somit die Datei für die Erzeugung der Warnmeldungen nicht eingebunden. Nun macht es das was es soll und ich kann auf einen Extender innerhalb der start.php getrost verzichten. So ist die Lösung sogar noch schöner, da ich ganz einfach meine Warnmeldungen bei Bedarf auch auf jeder anderen Seite im Admin-Bereich ausgeben lassen kann.
Guten Morgen, die Beta 1 vom Master Update ist erschienen und kann im Portal heruntergeladen werden: https://www.gambio-support.de/downlo...3-53bd5c2b6afd Die Vollversion der Beta 1 folgt in wenigen Tagen.
Habe mir natürlich gleich mal meine "Lieblingsstellen" angesehen: die guten Nachrichten zuerst: In "checkout_process" + verwendeten Klassen kann man jetzt (wie von mir vorgeschlagen) updatesicher eigene Daten den Order-Daten hinzufügen. Ebenfalls scheint es jetzt auch im "create_account" möglich zu sein, eigene Felder zu selektieren, speichern und validieren..... Eine wirkliche Erleichterung! Thumbs up! Die schlechten Nachrichten: Im payment und shipping kann ich immer noch nicht eigene Kriterien zum Anbieten/Verstecken von Zahlungs-/Versandarten updatesicher lösen, wie in http://www.gambio-forum.de/threads/...ta-1)-Download?p=106107&viewfull=1#post106107 beschrieben. (Dabei wäre das soooo einfach!) Die Konsistenz und Erweiterbarkeit der diversen Artikellisten ist immer noch nicht gewährleistet. Es ist jetzt zwar ein bisschen besser geworden, aber noch nicht so wie man es braucht.. Insbesondere die Möglichkeit, eigene Produktfelder einfach zu integrieren, fehlt. Das Problem ist, dass die Aufbereitung der Artikeldaten immer noch auf vorher spezifisch selektierten Feldern basiert. PHP: while($t_products_new = xtc_db_fetch_array($t_result)) { $this->content_array['module_content'][] = $coo_product->buildDataArray($t_products_new); wobei eine "Query" z.B. so aussieht: PHP: $t_products_new_query = "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' " . $t_group_check . " " . $t_fsk_lock . " " . $t_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->languages_id . "' ORDER BY RAND() LIMIT " . $this->new_products_count Immer wieder nachgefragte Felder wie "Artikel-Nummer", "Hersteller" usw. fehlen dort einfach. Besser wäre es m.E., in den "SELECTS" nur noch die "products_id" zu selektieren, und die Aufbereitung wie folgt zu machen: PHP: while($t_products_new = xtc_db_fetch_array($t_result)) { $products_id=$t_products_new['products_id']; $product=new products($products_id); $this->content_array['module_content'][] = $coo_product->buildDataArray($product->['data']); } Das Select sieht dann so aus: PHP: $t_products_new_query = "SELECT p.products_id FROM (SELECT p.products_id FROM " . TABLE_PRODUCTS . " p WHERE p.products_status = '1' " . $t_group_check . " " . $t_fsk_lock . " " . $t_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->languages_id . "' ORDER BY RAND() LIMIT " . $this->new_products_count Warum ist das besser? Weil ich damit für alle Listen alle Artikel-Felder (auch eigene!) zur Verfügung habe, und nicht nur die, die Gambio vorausgewählt hat. Und durch überladen der "buildDataArray"-Methode kann ich diese auch sehr einfach an das Template übergeben. (Dieses Beispiel-Select sieht mir sowieso sehr merkwürdig aus, könnte man sicher vereinfachen....) Fazit: Gegenüber dem Preview haben sich noch eine ganze Menge Dinge zum positiven gewandelt. Und wenn man jetzt noch die letzten unschönen Dinge beseitigt (shipping, payment, alle Artikellisten), denn wäre ich rundum zufrieden......
Man kann includes/classes/payment.php und includes/classes/shipping.php für solche Zwecke überladen. Das funktioniert ganz passabel, ich hab das neulich mal ausprobiert.
In den /includes/modules/ hat sich ja auch was getan! Finde ich ja richtig gut!!! default.php, product_listing.php usw. ist alles schön ausklassifiziert! Was mir noch fehlt wäre in /includes/center_modules.php einen Extender um für die Startseite eigene Bereiche per Overload hinzuzufügen.(z.B. Blogsystem)
Genauso fehlt mir die Andockstelle(Extender) in der /templates/EyeCandy/source/boxes.php Das ist auch ein Bereich in dem man stehtig eingreift, gerade bei Modul-Entwicklungen mit eingenen Boxen!!! Inwieweit ist die Klassenüberladung nun im Adminbereich möglich???
Hallo, danke schonmal für die Rückmeldung. @ Steffen center_modules.php wird innerhalb der prepare_data Methode im IndexContentView geladen. Du kannst also einfach die Methode überladen und mittels $this->content_array['MODULE_XXX'] auf die bisher zugewiesenen Blöcke zugreifen oder mittels $this->set_content_data() (besser aber noch direkt mit $this->content_array['mein_modul'] = "Test" neue Blöcke hinzufügen... MfG, Timo Nachtrag: Wir werden die Stelle nochmal anfassen und die ganzen Modul-Blöcke aus der center_modules.php in der Klasse verlagern. Es macht ja überhaupt keinen Sinn, die Inhalte per include aus einer eigenständigen Datei zu laden. Somit wäre die Datei überflüssig und könnte gelöscht werden.
Das wäre ein i-Tüpfelchen! Wie sieht es mit der boxes.php aus??? Ich finde diese Stelle etwas vorbelastet was Änderungen angeht! Und die letzte Frage war, wie stehts mit der Überladbarkeit im Admnibereich? Ich habe das Updates noch nicht im Netbeans, sonst wären sicherlich einige Fragen schon beantwortet.
Die boxes.php verhält sich genauso. Wobei ich da anscheinend gerade noch ein Strukturproblem festgestellt habe. Ich werde das nochmal weiter untersuchen... Die Überladbarkeit im Adminbereich ist noch nicht weiterentwickelt worden. Wir haben es aber auf unserer ToDo Liste... MfG, Timo
Ich will ja nicht nerven aber das sind eben die Punkte die ich selbst immer wieder angreifen muss. Deswegen wünscht man sich da Andockmöglichkeiten.
Ab jetzt brauchst du ja nicht mehr nerven. Andockstellen sind ja gegeben (auch schon mit der Beta 1)... MfG, Timo
Ich habe versucht die Beta 1 in unseren Testshop einzuspielen und bekomme die folgende Fehlermeldung beim ausführen des SQL Updaters: Es ist ein Fehler aufgetreten. Bitte spielen Sie Ihre Sicherung wieder ein. Maximale Ausführungszeit des Servers erreicht: Update konnte nicht vollständig ausgeführt werden.
Hi Chris, bitte einmal ein Ticket mit Zugangsdaten und den Details erstellen. Wir schauen uns das dann auf deinem Server direkt einmal an. MfG, Timo
Kann man machen, hat aber m.E. 2 wesentliche Nachteile: man muss immer die komplette "selection"-Methode überladen (Update Probleme) PHP: function selection() { $selection_array = array(); if (is_array($this->modules)) { reset($this->modules); while (list(, $value) = each($this->modules)) { $class = substr($value, 0, strrpos($value, '.')); if ($GLOBALS[$class]->enabled) { $selection = $GLOBALS[$class]->selection(); if (is_array($selection)) $selection_array[] = $selection; } } } return $selection_array; } Man kann damit auch keine mehrfache Überladung durch mehr als ein Modul realisieren! (Chaining). All das lässt sich bei der von mir vorgeschlagenen Lösung umgehen. Außerdem möchte ich nicht eine Basisklasse wie shipping und payment überladen müssen, um in einer View-Klasse Änderungen durch zuführen.
Die jetzige Lösung nutzt auch das Potential der Klassen-Technik noch nicht voll aus: Alle Productlisting-Klassen machen die im Grunde identische Verarbeitung immer noch selbst. "NewProductsMainContentView.inc.php", "SpecialsMainContentView.inc.php", "TopProductsContentView.inc.php" und "UpcomingProductsContentView.inc.php" haben bis auf wenige Ausnahmen denselben Code! Das schreit geradezu danach, diese Code-Teile in eine "ProductListing"-Klasse auszulagern, die von den zuvor genannten Klassen geerbt wird. Individuell in diesen Klassen müssen eigentlich nur sein: PHP: public function __construct() { parent::__construct(); $this->set_content_template('module/specials_main.html'); } PHP: protected function build_sql_query() Alles Andere wandert in die "Productlisting"-Klasse. Was gar nicht geht, ist, dass die Anzahl der zu selektierenden Datensätze in den List-Modulen fest verdrahtet ist! Beispiel: PHP: protected $specials_count = 6; Diese Klassen müssen von außen konfigurierbar sein, was die Anzahl der gewünschten Elemente betrifft!
Das ist schade. Weil es im Grunde einfach zu realisieren ist. Ich habe bei mir die Klassenüberladung im Admin prinzipiell gelöst. Was einer produktiven Nutzung im Weg steht, ist im Grunde nur die Tatsache, dass die Admin-Klassen nicht als "....._ORIGIN"-Klassen definiert sind, und sich somit nach dem "include/require" einer Überladung entziehen.....
Ich bin immer wieder erstaunt was Avenger für Lösungen findet und zur Verfügung stellt - und wie standhaft sich Gambio weigert diese umzusetzen. Dies hier ist wieder so ein Beispiel, ebenso wie die ganze Angelegenheit aus diesem Thread. Wie erklärt sich das?
Nanana Im ersten Beitrag zur 2.1er Beta haben wir zu Anfang ein kleines Lob von Avenger bekommen, das war schon ziemlich gut